Network Working Group E. Mannie, Ed.
Request for Comments: 3945 October 2004
Category: Standards Track
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
Future data and transmission networks will consist of elements such as routers, switches, Dense Wavelength Division Multiplexing (DWDM) systems, Add-Drop Multiplexors (ADMs), photonic cross-connects (PXCs), optical cross-connects (OXCs), etc. that will use Generalized Multi-Protocol Label Switching (GMPLS) to dynamically provision resources and to provide network survivability using protection and restoration techniques.
将来のデータと伝送ネットワークは、ルータ、スイッチ、高密度波長分割多重（DWDM）システム、アド・ドロップマルチプレクサ（ADM装置）、光クロスコネクト（PXCs）、光クロスコネクト（のOXC）、等のような要素で構成されますそれは一般マルチプロトコルラベルスイッチング（GMPLS）に動的にプロビジョニングリソースを使用し、保護・修復技術を使用して、ネットワークの存続を提供します。
This document describes the architecture of GMPLS. GMPLS extends MPLS to encompass time-division (e.g., SONET/SDH, PDH, G.709), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The focus of GMPLS is on the control plane of these various layers since each of them can use physically diverse data or forwarding planes. The intention is to cover both the signaling and the routing part of that control plane.
このドキュメントは、GMPLSのアーキテクチャについて説明します。 GMPLSは、時分割（例えば、SONET / SDH、PDH、G.709）、波長（ラムダ）、および空間スイッチング（出力ポートまたはファイバ例えば、着信ポートまたはファイバ）を包含するようにMPLSを拡張します。それらの各々が物理的に多様なデータまたは転送プレーンを使用することができるので、GMPLSの焦点は、これらの様々な層の制御プレーン上にあります。意図は、シグナリングおよびその制御プレーンのルーティング一部の両方をカバーするものです。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms & Abbreviations. . . . . . . . . . . . . . . . 4
1.2. Multiple Types of Switching and Forwarding Hierarchies. 5
1.3. Extension of the MPLS Control Plane . . . . . . . . . . 7
1.4. GMPLS Key Extensions to MPLS-TE . . . . . . . . . . . . 10
2. Routing and Addressing Model. . . . . . . . . . . . . . . . . 11
2.1. Addressing of PSC and non-PSC layers. . . . . . . . . . 13
2.2. GMPLS Scalability Enhancements. . . . . . . . . . . . . 13
2.3. TE Extensions to IP Routing Protocols . . . . . . . . . 14
3. Unnumbered Links. . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Unnumbered Forwarding Adjacencies . . . . . . . . . . . 16
4. Link Bundling . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Restrictions on Bundling. . . . . . . . . . . . . . . . 17
4.2. Routing Considerations for Bundling . . . . . . . . . . 17
4.3. Signaling Considerations. . . . . . . . . . . . . . . . 18
4.3.1. Mechanism 1: Implicit Indication. . . . . . . . 18
4.3.2. Mechanism 2: Explicit Indication by Numbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.3.3. Mechanism 3: Explicit Indication by Unnumbered
Interface ID. . . . . . . . . . . . . . . . . . 19
4.4. Unnumbered Bundled Link . . . . . . . . . . . . . . . . 19
4.5. Forming Bundled Links . . . . . . . . . . . . . . . . . 20
5. Relationship with the UNI . . . . . . . . . . . . . . . . . . 20
5.1. Relationship with the OIF UNI . . . . . . . . . . . . . 21
5.2. Reachability across the UNI . . . . . . . . . . . . . . 21
6. Link Management . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Control Channel and Control Channel Management. . . . . 23
6.2. Link Property Correlation . . . . . . . . . . . . . . . 24
6.3. Link Connectivity Verification. . . . . . . . . . . . . 24
6.4. Fault Management. . . . . . . . . . . . . . . . . . . . 25
6.5. LMP for DWDM Optical Line Systems (OLSs). . . . . . . . 26
7. Generalized Signaling . . . . . . . . . . . . . . . . . . . . 27
7.1. Overview: How to Request an LSP . . . . . . . . . . . . 29
7.2. Generalized Label Request . . . . . . . . . . . . . . . 30
7.3. SONET/SDH Traffic Parameters. . . . . . . . . . . . . . 31
7.4. G.709 Traffic Parameters. . . . . . . . . . . . . . . . 32
7.5. Bandwidth Encoding. . . . . . . . . . . . . . . . . . . 33
7.6. Generalized Label . . . . . . . . . . . . . . . . . . . 34
7.7. Waveband Switching. . . . . . . . . . . . . . . . . . . 34
7.8. Label Suggestion by the Upstream. . . . . . . . . . . . 35
7.9. Label Restriction by the Upstream . . . . . . . . . . . 35
7.10. Bi-directional LSP. . . . . . . . . . . . . . . . . . . 36
7.11. Bi-directional LSP Contention Resolution. . . . . . . . 37
7.12. Rapid Notification of Failure . . . . . . . . . . . . . 37
7.13. Link Protection . . . . . . . . . . . . . . . . . . . . 38
7.14. Explicit Routing and Explicit Label Control . . . . . . 39
7.15. Route Recording . . . . . . . . . . . . . . . . . . . . 40
7.16. LSP Modification and LSP Re-routing . . . . . . . . . . 40
7.17. LSP Administrative Status Handling. . . . . . . . . . . 41
7.18. Control Channel Separation. . . . . . . . . . . . . . . 42
8. Forwarding Adjacencies (FA) . . . . . . . . . . . . . . . . . 43
8.1. Routing and Forwarding Adjacencies. . . . . . . . . . . 43
8.2. Signaling Aspects . . . . . . . . . . . . . . . . . . . 44
8.3. Cascading of Forwarding Adjacencies . . . . . . . . . . 44
9. Routing and Signaling Adjacencies . . . . . . . . . . . . . . 45
10. Control Plane Fault Handling. . . . . . . . . . . . . . . . . 46
11. LSP Protection and Restoration. . . . . . . . . . . . . . . . 47
11.1. Protection Escalation across Domains and Layers . . . . 48
11.2. Mapping of Services to P&R Resources. . . . . . . . . . 49
11.3. Classification of P&R Mechanism Characteristics . . . . 49
11.4. Different Stages in P&R . . . . . . . . . . . . . . . . 50
11.5. Recovery Strategies . . . . . . . . . . . . . . . . . . 50
11.6. Recovery mechanisms: Protection schemes . . . . . . . . 51
11.7. Recovery mechanisms: Restoration schemes. . . . . . . . 52
11.8. Schema Selection Criteria . . . . . . . . . . . . . . . 53
12. Network Management. . . . . . . . . . . . . . . . . . . . . . 54
12.1. Network Management Systems (NMS). . . . . . . . . . . . 55
12.2. Management Information Base (MIB) . . . . . . . . . . . 55
12.3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.4. Fault Correlation Between Multiple Layers . . . . . . . 56
13. Security Considerations . . . . . . . . . . . . . . . . . . . 57
14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 58
15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 58
15.1. Normative References. . . . . . . . . . . . . . . . . . 58
15.2. Informative References. . . . . . . . . . . . . . . . . 59
16. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . 63
17. Author's Address. . . . . . . . . . . . . . . . . . . . . . . 68
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 69
The architecture described in this document covers the main building blocks needed to build a consistent control plane for multiple switching layers. It does not restrict the way that these layers work together. Different models can be applied, e.g., overlay, augmented or integrated. Moreover, each pair of contiguous layers may collaborate in different ways, resulting in a number of possible combinations, at the discretion of manufacturers and operators.
本書では説明のアーキテクチャは、複数のスイッチング層のための一貫性のある制御プレーンを構築するために必要な主要なビルディングブロックをカバーします。これは、これらの層は一緒に仕事のやり方を制限するものではありません。異なるモデルを適用することができ、例えば、オーバーレイ、増補または集積。また、隣接層の各対は、メーカーやオペレータの裁量で、可能な組合せの数で、その結果、様々な方法で協力することができます。
This architecture clearly separates the control plane and the forwarding plane. In addition, it also clearly separates the control plane in two parts, the signaling plane containing the signaling protocols and the routing plane containing the routing protocols.
このアーキテクチャは、明らかに、制御プレーンと転送プレーンを分離します。加えて、それはまた、明確に二つの部分、シグナリングプロトコルとルーティングプロトコルを含むルーティング面を含むシグナリング・プレーンにおける制御プレーンを分離します。
This document is a generalization of the Multi-Protocol Label Switching (MPLS) architecture [RFC3031], and in some cases may differ slightly from that architecture since non packet-based forwarding planes are now considered. It is not the intention of this document to describe concepts already described in the current MPLS architecture. The goal is to describe specific concepts of Generalized MPLS (GMPLS).
この文書は、マルチプロトコルラベルスイッチング（MPLS）アーキテクチャ[RFC3031]の一般化であり、非パケットベースの転送プレーンは、現在考えられているので、いくつかの場合にはそのアーキテクチャ多少異なる場合があります。これは、すでに現在のMPLSアーキテクチャで説明されている概念を説明するために、このドキュメントの意図ではありません。目標は、一般化MPLS（GMPLS）の具体的な概念を説明することです。
However, some of the concepts explained hereafter are not part of the current MPLS architecture and are applicable to both MPLS and GMPLS (i.e., link bundling, unnumbered links, and LSP hierarchy). Since these concepts were introduced together with GMPLS and since they are of paramount importance for an operational GMPLS network, they will be discussed here.
しかし、概念のいくつかを以下に説明し、現在のMPLSアーキテクチャの一部ではなく、MPLSとGMPLS（即ち、リンクのバンドリング、無数のリンク、およびLSP階層）の両方に適用可能です。これらの概念は、GMPLSと一緒に導入されて以来、彼らは運用GMPLSネットワークのための最も重要であるので、ここで議論されます。
The organization of the remainder of this document is as follows. We begin with an introduction of GMPLS. We then present the specific GMPLS building blocks and explain how they can be combined together to build an operational GMPLS network. Specific details of the separate building blocks can be found in the corresponding documents.
次のようにこの文書の残りの組織です。私たちは、GMPLSの導入で始まります。私たちは、その後、特定のGMPLSのビルディングブロックを提供し、彼らが動作GMPLSネットワークを構築するために一緒に組み合わせることができる方法について説明します。別のビルディングブロックの具体的な詳細は、対応する文書に記載されています。
AS Autonomous System BGP Border Gateway Protocol CR-LDP Constraint-based Routing LDP CSPF Constraint-based Shortest Path First DWDM Dense Wavelength Division Multiplexing FA Forwarding Adjacency GMPLS Generalized Multi-Protocol Label Switching IGP Interior Gateway Protocol LDP Label Distribution Protocol LMP Link Management Protocol
IGP内部ゲートウェイプロトコルLDPラベル配布プロトコルLMPリンク管理プロトコルを切り替え自律システムBGPボーダーゲートウェイプロトコルCR-LDP制約ベースのルーティングLDP CSPF制約ベースの最短パスファーストDWDM高密度波長分割多重FA転送隣接GMPLS一般マルチプロトコルラベルAS
LSA Link State Advertisement LSR Label Switching Router LSP Label Switched Path MIB Management Information Base MPLS Multi-Protocol Label Switching NMS Network Management System OXC Optical Cross-Connect PXC Photonic Cross-Connect RSVP ReSource reserVation Protocol SDH Synchronous Digital Hierarchy SONET Synchronous Optical Networks STM(-N) Synchronous Transport Module (-N) STS(-N) Synchronous Transport Signal-Level N (SONET) TDM Time Division Multiplexing TE Traffic Engineering
NMSネットワーク管理システムOXC光クロスコネクトPXCフォトニッククロスコネクトRSVPリソース予約プロトコルSDH同期デジタル階層SONET同期光ネットワークSTMスイッチングLSAリンクステートアドバタイズメントLSRラベルスイッチングルータLSPラベルスイッチパスMIB管理情報ベースMPLSマルチプロトコルラベル（ -N）同期転送モジュール（-N）STS（-N）同期転送信号レベルN（SONET）TDM時分割多重TEトラフィックエンジニアリング
Generalized MPLS (GMPLS) differs from traditional MPLS in that it supports multiple types of switching, i.e., the addition of support for TDM, lambda, and fiber (port) switching. The support for the additional types of switching has driven GMPLS to extend certain base functions of traditional MPLS and, in some cases, to add functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress LSRs.
それはすなわち、スイッチング複数のタイプ、TDM、ラムダ、およびファイバ（ポート）は、スイッチングのためのサポートの追加をサポートしているという点で一般的なMPLS（GMPLS）は、従来のMPLSは異なります。スイッチングの追加タイプのサポートは、従来のMPLSの特定の基底関数を拡張し、いくつかのケースでは、機能を追加するためにGMPLSを駆動しています。これらの変更や追加は、基本的なLSPの性質に影響を与える：ラベルが要求されたと伝え、LSPの一方向の性質上、エラーが伝播される方法、および情報は、入力および出力のLSRを同期させるために提供されていますか。
The MPLS architecture [RFC3031] was defined to support the forwarding of data based on a label. In this architecture, Label Switching Routers (LSRs) were assumed to have a forwarding plane that is capable of (a) recognizing either packet or cell boundaries, and (b) being able to process either packet headers (for LSRs capable of recognizing packet boundaries) or cell headers (for LSRs capable of recognizing cell boundaries).
MPLSアーキテクチャ[RFC3031]は、ラベルに基づいてデータの転送をサポートするために定義されました。このアーキテクチャでは、ラベルスイッチングルータ（LSRの）（a）の認識パケットまたはセルのいずれかの境界の可能な転送プレーンを有するものと、（b）はパケットヘッダのいずれかを処理することができる（パケット境界を認識することができるのLSRのためにしました）又はセル境界を認識することができるのLSRのためのセルヘッダー（）。
The original MPLS architecture is here being extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, cannot forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the switching decision is based on time slots, wavelengths, or physical ports. So, the new set of LSRs, or more precisely interfaces on these LSRs, can be subdivided into the following classes:
元のMPLSアーキテクチャは、ここで、その転送面もパケットを認識し、またセル境界、したがって、パケットまたはセル・ヘッダのいずれかで運ばれた情報に基づいてデータを転送できないのLSRを含むように拡張されています。具体的には、そのようなLSRのスイッチング決定がタイムスロット、波長、または物理ポートに基づいてデバイスを含みます。だから、新しいのLSRのセット、またはより正確にこれらのLSR上のインターフェイスは、以下のクラスに細分化することができます。
Interfaces that recognize packet boundaries and can forward data based on the content of the packet header. Examples include interfaces on routers that forward data based on the content of the IP header and interfaces on routers that switch data based on the content of the MPLS "shim" header.
パケット境界を認識し、パケットヘッダの内容に基づいてデータを転送することができるインターフェイス。例としては、MPLS「シム」ヘッダの内容に基づいてデータをスイッチルータのIPヘッダ及びインタフェースの内容に基づいてデータを転送するルータのインタフェースを含みます。
Interfaces that recognize frame/cell boundaries and can switch data based on the content of the frame/cell header. Examples include interfaces on Ethernet bridges that switch data based on the content of the MAC header and interfaces on ATM-LSRs that forward data based on the ATM VPI/VCI.
フレーム/セル境界を認識し、フレーム/セル・ヘッダの内容に基づいてデータを切り替えることができるインターフェイス。例としては、ATM VPI / VCIに基づいてデータを転送するATM-LSRの上のMACヘッダ及びインタフェースの内容に基づいてデータを切り替えるイーサネットブリッジのインタフェースを含みます。
Interfaces that switch data based on the data's time slot in a repeating cycle. An example of such an interface is that of a SONET/SDH Cross-Connect (XC), Terminal Multiplexer (TM), or Add-Drop Multiplexer (ADM). Other examples include interfaces providing G.709 TDM capabilities (the "digital wrapper") and PDH interfaces.
繰り返し周期内のデータのタイムスロットに基づいてデータを切り替えるインターフェース。そのようなインターフェイスの例は、そのSONET / SDHクロスコネクト（XC）、ターミナルマルチプレクサ（TM）、又はアド・ドロップマルチプレクサ（ADM）。他の例としては、G.709のTDM機能（「デジタルラッパー」）とPDHインタフェースを提供するインタフェースを含みます。
Interfaces that switch data based on the wavelength on which the data is received. An example of such an interface is that of a Photonic Cross-Connect (PXC) or Optical Cross-Connect (OXC) that can operate at the level of an individual wavelength. Additional examples include PXC interfaces that can operate at the level of a group of wavelengths, i.e., a waveband and G.709 interfaces providing optical capabilities.
データが受信された波長に基づいてデータを切り替えるインターフェース。そのようなインターフェイスの例は、個々の波長レベルで動作することができるフォトニッククロスコネクト（PXC）または光クロスコネクト（OXC）です。さらなる例は、波長のグループのレベルで動作することができるPXCインタフェース、すなわち、光学機能を提供する波長帯とG.709インタフェースを含みます。
Interfaces that switch data based on a position of the data in the (real world) physical spaces. An example of such an interface is that of a PXC or OXC that can operate at the level of a single or multiple fibers.
（現実世界）内のデータの位置に基づいてデータを切り替えるインタフェースの物理的なスペース。そのようなインターフェイスの例は、単一又は複数の繊維のレベルで動作することができるPXC又はOXCのことです。
A circuit can be established only between, or through, interfaces of the same type. Depending on the particular technology being used for each interface, different circuit names can be used, e.g., SDH circuit, optical trail, light-path, etc. In the context of GMPLS, all these circuits are referenced by a common name: Label Switched Path (LSP).
回路は、間、または同じタイプの、インターフェースを介して確立することができます。各インターフェイスのために使用される特定の技術に依存して、異なる回路の名前を使用することができ、例えば、SDH回路、光トレイル、光路等GMPLSの文脈では、すべてのこれらの回路は、共通の名前によって参照される：ラベルスイッチパス（LSP）。
The concept of nested LSP (LSP within LSP), already available in the traditional MPLS, facilitates building a forwarding hierarchy, i.e., a hierarchy of LSPs. This hierarchy of LSPs can occur on the same interface, or between different interfaces.
従来のMPLSで既に利用可能なネストされたLSP（LSP内LSP）の概念は、すなわち、LSPの階層を転送階層の構築を容易にします。 LSPのこの階層は、同じインターフェイス上で、または異なるインタフェース間で起こり得ます。
For example, a hierarchy can be built if an interface is capable of multiplexing several LSPs from the same technology (layer), e.g., a lower order SONET/SDH LSP (e.g., VT2/VC-12) nested in a higher order SONET/SDH LSP (e.g., STS-3c/VC-4). Several levels of signal (LSP) nesting are defined in the SONET/SDH multiplexing hierarchy.
例えば、階層は、インタフェースは、例えば同じ技術から多重化のいくつかのLSP（層）が可能である場合に構築することができ、下位SONET / SDH LSP（例えば、VT2 / VC-12）高次SONETにネスト/ SDH LSP（例えば、STS-3C / VC-4）。信号（LSP）入れ子のいくつかのレベルは、SONET / SDH多重階層で定義されています。
The nesting can also occur between interface types. At the top of the hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by L2SC, and followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a L2SC interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. In turn, this LSP can be nested (together with other LSPs) into an LSP that starts and ends on a LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface.
ネストは、また、インタフェースタイプとの間で発生する可能性があります。階層の最上位にL2SC続いて、PSCインタフェース続いTDMインタフェース、続いLSCインターフェース続くFSCインタフェースは、です。この方法は、開始及びPSCインタフェースで終了LSPが起動しL2SCインタフェースで終了LSPに（一緒に、他のLSPとの）ネストすることができます。このLSPは、今度は、開始及びTDMインタフェースで終了LSPに（一緒に、他のLSPとの）ネストすることができます。今度は、このLSPが起動し、FSCインタフェースで終了LSPに（一緒に、他のLSPで）順番に入れ子にすることができるLSCインターフェース上で開始および終了するLSPに（一緒に、他のLSPとの）ネストすることができます。
The establishment of LSPs that span only Packet Switch Capable (PSC) or Layer-2 Switch Capable (L2SC) interfaces is defined for the original MPLS and/or MPLS-TE control planes. GMPLS extends these control planes to support each of the five classes of interfaces (i.e., layers) defined in the previous section.
パケットのみにまたがるLSPの確立が可能なことができる（PSC）またはレイヤ2スイッチ（L2SC）インタフェースが元のMPLSおよび/またはMPLS-TE制御プレーンのために定義されたスイッチ。 GMPLSは、前のセクションで定義されたインタフェースの5つのクラス（すなわち、層）の各々をサポートするために、これらの制御プレーンを拡張します。
Note that the GMPLS control plane supports an overlay model, an augmented model, and a peer (integrated) model. In the near term, GMPLS appears to be very suitable for controlling each layer independently. This elegant approach will facilitate the future deployment of other models.
GMPLS制御プレーンは、オーバーレイ・モデル、拡張モデル、およびピア（統合）モデルをサポートすることに留意されたいです。短期的には、GMPLSは、独立してそれぞれの層を制御するために非常に適していることが表示されます。このエレガントなアプローチは、他のモデルの今後の展開を容易にします。
The GMPLS control plane is made of several building blocks as described in more details in the following sections. These building blocks are based on well-known signaling and routing protocols that have been extended and/or modified to support GMPLS. They use IPv4 and/or IPv6 addresses. Only one new specialized protocol is required to support the operations of GMPLS, a signaling protocol for link management [LMP].
次のセクションで詳細に記載されているようにGMPLS制御プレーンは、いくつかのビルディングブロックで構成されています。これらのビルディングブロックは、GMPLSをサポートするように拡張および/または改変された周知のシグナリングおよびルーティングプロトコルに基づいています。彼らは、IPv4および/またはIPv6アドレスを使用します。唯一の新しい専門プロトコルはGMPLS、[LMP]リンク管理のためのシグナリングプロトコルの動作をサポートするために必要とされます。
GMPLS is indeed based on the Traffic Engineering (TE) extensions to MPLS, a.k.a. MPLS-TE [RFC2702]. This, because most of the technologies that can be used below the PSC level requires some traffic engineering. The placement of LSPs at these levels needs in general to consider several constraints (such as framing, bandwidth, protection capability, etc) and to bypass the legacy Shortest-Path First (SPF) algorithm. Note, however, that this is not mandatory and that in some cases SPF routing can be applied.
GMPLSは、実際にMPLSのトラフィックエンジニアリング（TE）の拡張機能、別名、MPLS-TE [RFC2702]に基づいています。これは、PSCレベル以下に使用することができます技術の最もので、いくつかのトラフィックエンジニアリングが必要です。これらのレベルでのLSPの配置は、（など、フレーミング、帯域幅、保護機能、など）いくつかの制約を考慮すると、従来の最短パスファースト（SPF）アルゴリズムをバイパスするために一般的に必要です。これは必須ではありません、それはいくつかのケースでSPFルーティングが適用可能であること、しかし、注意してください。
In order to facilitate constrained-based SPF routing of LSPs, nodes that perform LSP establishment need more information about the links in the network than standard intra-domain routing protocols provide. These TE attributes are distributed using the transport mechanisms already available in IGPs (e.g., flooding) and taken into consideration by the LSP routing algorithm. Optimization of the LSP routes may also require some external simulations using heuristics that serve as input for the actual path calculation and LSP establishment process.
LSPの制約ベースSPFルーティングを容易にするために、LSPの確立を行うノードは、標準のドメイン内ルーティングプロトコルが提供するよりも、ネットワーク内のリンクに関するより多くの情報が必要。これらTE属性は既にのIGP（例えば、フラッディング）で入手可能であり、LSPルーティングアルゴリズムによって考慮され、搬送機構を使用して分配されます。 LSPルートの最適化は、実際の経路計算及びLSP確立処理のための入力として機能するヒューリスティックを使用して、いくつかの外部のシミュレーションを必要とするかもしれません。
By definition, a TE link is a representation in the IS-IS/OSPF Link State advertisements and in the link state database of certain physical resources, and their properties, between two GMPLS nodes. TE Links are used by the GMPLS control plane (routing and signaling) for establishing LSPs.
定義により、TEリンクは、IS-IS / OSPFリンク状態広告に二つGMPLSノードとの間の特定の物理的リソース、およびそのプロパティのリンク状態データベース内の表現です。 TEリンクは、LSPを確立するためのGMPLS制御プレーン（ルーティングおよびシグナリング）によって使用されます。
Extensions to traditional routing protocols and algorithms are needed to uniformly encode and carry TE link information, and explicit routes (e.g., source routes) are required in the signaling. In addition, the signaling must now be capable of transporting the required circuit (LSP) parameters such as the bandwidth, the type of signal, the desired protection and/or restoration, the position in a particular multiplex, etc. Most of these extensions have already been defined for PSC and L2SC traffic engineering with MPLS. GMPLS primarily defines additional extensions for TDM, LSC, and FSC traffic engineering. A very few elements are technology specific.
伝統的なルーティングプロトコルおよびアルゴリズムの拡張均一にエンコードするために必要とTEリンク情報を搬送している、と明示的経路（例えば、ソースルート）はシグナル伝達に必要とされます。また、シグナリングが今必要な回路（LSP）など、これらの拡張機能のほとんどが持っている帯域幅、信号の種類、所望の保護および/または修復、特にマルチプレックス内の位置、などのパラメータを搬送することができなければなりませんすでにMPLSとPSCとL2SCトラフィックエンジニアリングのために定義されて。 GMPLSは、主にTDM、LSC、及びFSCのトラフィックエンジニアリングのための追加の拡張機能を定義します。非常に少数の要素は、技術固有のものです。
Thus, GMPLS extends the two signaling protocols defined for MPLS-TE signaling, i.e., RSVP-TE [RFC3209] and CR-LDP [RFC3212]. However, GMPLS does not specify which one of these two signaling protocols must be used. It is the role of manufacturers and operators to evaluate the two possible solutions for their own interest.
したがって、GMPLSは、MPLS-TEシグナリング、即ち、RSVP-TE [RFC3209]とCR-LDP [RFC3212]のために定義された2つのシグナリングプロトコルを拡張します。しかし、GMPLSは、これら2つのシグナリングプロトコルのいずれかを使用しなければならないかを指定しません。自分の利益のために2つの解決策を評価するために、メーカーや事業者の役割です。
Since GMPLS signaling is based on RSVP-TE and CR-LDP, it mandates a downstream-on-demand label allocation and distribution, with ingress initiated ordered control. Liberal label retention is normally used, but conservative label retention mode could also be used.
GMPLSシグナリングはRSVP-TEやCR-LDPに基づいているので、制御を注文開始入力と、下流オンデマンドラベル割り当てと分配を義務付け。リベラルラベル保持は通常使用されているが、保守的なラベル保持モードを使用することもできます。
Furthermore, there is no restriction on the label allocation strategy, it can be request/signaling driven (obvious for circuit switching technologies), traffic/data driven, or even topology driven. There is also no restriction on the route selection; explicit routing is normally used (strict or loose) but hop-by-hop routing could be used as well.
また、ラベル割り当て方式に制限はありません、リクエスト/トラフィック/データ駆動型、（回線交換技術には明らか）駆動シグナリング、あるいはトポロジー駆動することができます。ルート選択には制限もありません。明示的なルーティングは、通常、（厳密または緩い）が使用されるが、ホップバイホップルーティングも同様に使用することができます。
GMPLS also extends two traditional intra-domain link-state routing protocols already extended for TE purposes, i.e., OSPF-TE [OSPF-TE] and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is used, the routing algorithms used by these protocols no longer need to be standardized. Extensions for inter-domain routing (e.g., BGP) are for further study.
GMPLSは、既にTEの目的、すなわち、OSPF-TE [OSPF-TE]およびISIS-TE [ISIS-TE]に拡張2伝統的なドメイン内のリンクステートルーティングプロトコルを拡張します。明示的な（ソース）ルーティングを使用する場合は、これらのプロトコルによって使用されるルーティングアルゴリズムは、もはや標準化する必要はありません。ドメイン間ルーティング（例えば、BGP）用の拡張は今後の検討課題です。
The use of technologies like DWDM (Dense Wavelength Division Multiplexing) implies that we can now have a very large number of parallel links between two directly adjacent nodes (hundreds of wavelengths, or even thousands of wavelengths if multiple fibers are used). Such a large number of links was not originally considered for an IP or MPLS control plane, although it could be done. Some slight adaptations of that control plane are thus required if we want to better reuse it in the GMPLS context.
DWDM（高密度波長分割多重）などの技術を使用することは、（複数の繊維が使用されている場合は波長の波長の何百、あるいは数千）私たちは今、2つの直接隣接ノード間のパラレルリンクの非常に大きな数を持つことができることを意味します。それが行うことができるが、リンクのような多数は、元々、IPまたはMPLSコントロールプレーンのために考慮されていませんでした。私たちはより良いGMPLSコンテキストでそれを再利用する場合、そのコントロールプレーンのいくつかのわずかな適応は、このように求められています。
For instance, the traditional IP routing model assumes the establishment of a routing adjacency over each link connecting two adjacent nodes. Having such a large number of adjacencies does not scale well. Each node needs to maintain each of its adjacencies one by one, and link state routing information must be flooded throughout the network.
例えば、伝統的なIPルーティングモデルは、2つの隣接ノードを接続する各リンクを介してルーティング隣接関係の確立を前提としています。隣接のような大規模な数を持つことは十分に拡張しません。各ノードは、その隣接の各一つずつを維持する必要があり、リンク状態ルーティング情報は、ネットワーク全体にフラッディングされなければなりません。
To solve this issue the concept of link bundling was introduced. Moreover, the manual configuration and control of these links, even if they are unnumbered, becomes impractical. The Link Management Protocol (LMP) was specified to solve these issues.
この問題を解決するには、リンクバンドリングの概念が導入されました。また、これらのリンクの手動設定や制御は、彼らが無番号であっても、非現実的になります。リンク管理プロトコル（LMP）は、これらの問題を解決するために指定されました。
LMP runs between data plane adjacent nodes and is used to manage TE links. Specifically, LMP provides mechanisms to maintain control channel connectivity (IP Control Channel Maintenance), verify the physical connectivity of the data-bearing links (Link Verification), correlate the link property information (Link Property Correlation), and manage link failures (Fault Localization and Fault Notification). A unique feature of LMP is that it is able to localize faults in both opaque and transparent networks (i.e., independent of the encoding scheme and bit rate used for the data).
LMPは、データプレーンの隣接ノード間で実行され、TEリンクを管理するために使用されます。具体的には、LMPは、フォールトローカリゼーション（制御チャネル接続（IP制御チャネルメンテナンス）を維持するデータ・ベアリング・リンク（リンクの検証）の物理的な接続を確認、リンク属性情報（リンクプロパティ相関を）相関、及びリンク障害を管理するためのメカニズムを提供しますそして、障害通知）。 LMPのユニークな特徴は、不透明と透明ネットワークの両方の障害をローカライズすることが可能であるということである（すなわち、データのために使用される符号化方式とビットレートとは無関係）。
LMP is defined in the context of GMPLS, but is specified independently of the GMPLS signaling specification since it is a local protocol running between data-plane adjacent nodes.
LMPは、GMPLSの文脈で定義され、それはデータプレーン隣接ノードとの間に実行されているローカルプロトコルであるので、独立して仕様をGMPLSシグナリングの指定されています。
Consequently, LMP can be used in other contexts with non-GMPLS signaling protocols.
したがって、LMPは、非GMPLSシグナリングプロトコルと他の状況で使用することができます。
MPLS signaling and routing protocols require at least one bi-directional control channel to communicate even if two adjacent nodes are connected by unidirectional links. Several control channels can be used. LMP can be used to establish, maintain and manage these control channels.
MPLSシグナリングおよびルーティングプロトコルは、2つの隣接ノードが一方向リンクによって接続されていても通信するために少なくとも1つの双方向制御チャネルを必要とします。いくつかの制御チャネルを使用することができます。 LMPは、これらの制御チャネルを確立、維持及び管理するために使用することができます。
GMPLS does not specify how these control channels must be implemented, but GMPLS requires IP to transport the signaling and routing protocols over them. Control channels can be either in-band or out-of-band, and several solutions can be used to carry IP. Note also that one type of LMP message (the Test message) is used in-band in the data plane and may not be transported over IP, but this is a particular case, needed to verify connectivity in the data plane.
GMPLSは、これらの制御チャネルを実装する必要がありますどのように指定されていませんが、GMPLSは、その上のシグナリングおよびルーティングプロトコルを輸送するためにIPが必要です。制御チャネルは、インバンドまたはアウト・オブ・バンドのいずれかとすることができ、いくつかのソリューションは、IPを運ぶために使用することができます。メモはまた、LMPメッセージ（テストメッセージ）の1つのタイプは、データプレーン内で帯域使用され、IPの上で輸送されないことがあり、これは、データ・プレーンに接続を確認するために必要な特別な場合です。
Some key extensions brought by GMPLS to MPLS-TE are highlighted in the following. Some of them are key advantages of GMPLS to control TDM, LSC and FSC layers.
MPLS-TEにGMPLSによってもたらされたいくつかの重要な機能拡張は、以下で強調表示されています。それらのいくつかは、TDM、LSCとFSC層を制御するGMPLSの重要な利点です。
- In MPLS-TE, links traversed by an LSP can include an intermix of links with heterogeneous label encoding (e.g., links between routers, links between routers and ATM-LSRs, and links between ATM-LSRs. GMPLS extends this by including links where the label is encoded as a time slot, or a wavelength, or a position in the (real world) physical space.
- でMPLS-TE、ルータ、ルータとATM-LSRの間のリンク、およびATM-LSRの間のリンクの間で異種標識符号化（例えば、リンクとリンクの混在を含むことができるLSPが横断するリンクGMPLSはリンク場所を含むことによって、これを延びています。ラベルは、タイムスロット、または波長、または（実世界）物理空間における位置として符号化されます。
- In MPLS-TE, an LSP that carries IP has to start and end on a router. GMPLS extends this by requiring an LSP to start and end on similar type of interfaces.
- でMPLS-TE、IP開始およびルータに終了しなければならない運ぶLSP。 GMPLSは、開始とインターフェイスの同様の種類に終了するLSPを要求することによって、これを延びています。
- The type of a payload that can be carried in GMPLS by an LSP is extended to allow such payloads as SONET/SDH, G.709, 1Gb or 10Gb Ethernet, etc.
- LSPによりGMPLSで実施することができるペイロードのタイプが等、SONET / SDH、G.709、1GB以上10 Gbイーサネットのようなペイロードを可能にするように拡張されます
- The use of Forwarding Adjacencies (FA) provides a mechanism that can improve bandwidth utilization, when bandwidth allocation can be performed only in discrete units. It offers also a mechanism to aggregate forwarding state, thus allowing the number of required labels to be reduced.
- 転送隣接関係（FA）の使用は、帯域割当のみ個別の単位で行うことができる場合に、帯域幅利用率を向上させることができる機構を提供します。したがって、必要なラベルの数を減らすことができるように、また、フォワーディング状態を集計するメカニズムを提供します。
- GMPLS allows suggesting a label by an upstream node to reduce the setup latency. This suggestion may be overridden by a downstream node but in some cases, at the cost of higher LSP setup time.
- GMPLSは、セットアップの待ち時間を減らすために、上流のノードでラベルを示唆できます。この提案は、より高いLSPセットアップ時間を犠牲にして、下流のノードではなく、いくつかの場合には上書きされてもよいです。
- GMPLS extends on the notion of restricting the range of labels that may be selected by a downstream node. In GMPLS, an upstream node may restrict the labels for an LSP along either a single hop or the entire LSP path. This feature is useful in photonic networks where wavelength conversion may not be available.
- GMPLSは、下流ノードによって選択することができるラベルの範囲を制限する概念に延びています。 GMPLSにおいて、上流ノードは、シングルホップまたは全LSPパスのいずれかに沿ってLSPのラベルを制限してもよいです。この機能は、波長変換が利用できない場合があり、フォトニックネットワークに有用です。
- While traditional TE-based (and even LDP-based) LSPs are unidirectional, GMPLS supports the establishment of bi-directional LSPs.
- TEベースの伝統的な（とでもLDPベース）のLSPは単方向ですが、GMPLSは、双方向のLSPの確立をサポートしています。
- GMPLS supports the termination of an LSP on a specific egress port, i.e., the port selection at the destination side.
- GMPLSは、特定の出力ポート、デスティネーション側で、すなわち、ポート選択に関するLSPの終端をサポートします。
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid failure notification.
- RSVP-TEとGMPLSは、迅速な障害通知のためのRSVP特定のメカニズムをサポートしています。
Note also some other key differences between MPLS-TE and GMPLS:
また、MPLS-TEとGMPLSの間に他のいくつかの重要な違いに注意してください。
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units.
- TDM、LSCとFSCインターフェイスは、LSPのための帯域幅割り当ては、個別の単位で行うことができます。
- It is expected to have (much) fewer labels on TDM, LSC or FSC links than on PSC or L2SC links, because the former are physical labels instead of logical labels.
- 前者は物理的なラベルの代わりに、論理的なラベルであるので、PSCまたはL2SCリンク上よりもTDM、LSCまたはFSCリンク上（多くの）少数のラベルを持つことが期待されています。
GMPLS is based on the IP routing and addressing models. This assumes that IPv4 and/or IPv6 addresses are used to identify interfaces but also that traditional (distributed) IP routing protocols are reused. Indeed, the discovery of the topology and the resource state of all links in a routing domain is achieved via these routing protocols.
GMPLSは、IPルーティングおよびアドレッシングのモデルに基づいています。これは、IPv4および/またはIPv6アドレスがインターフェイスを識別するために使用されるだけでなく、その伝統的な（分散）IPルーティングプロトコルが再利用されることを想定しています。確かに、トポロジーの発見およびルーティングドメイン内のすべてのリンクのリソース状態は、これらのルーティングプロトコルを介して達成されます。
Since control and data planes are de-coupled in GMPLS, control-plane neighbors (i.e., IGP-learnt neighbors) may not be data-plane neighbors. Hence, mechanisms like LMP are needed to associate TE links with neighboring nodes.
コントロールプレーンとデータプレーンは、GMPLSに脱結合されているので、制御プレーン隣人（すなわち、IGP学習近隣）は、データプレーンの近隣ではないかもしれません。したがって、LMPなどの機構は、隣接ノードとTEリンクを関連付けるために必要とされます。
IP addresses are not used only to identify interfaces of IP hosts and routers, but more generally to identify any PSC and non-PSC interfaces. Similarly, IP routing protocols are used to find routes for IP datagrams with a SPF algorithm; they are also used to find routes for non-PSC circuits by using a CSPF algorithm.
IPアドレスは、IPホストとルータのインターフェイスを識別するためにのみ使用されていないが、より一般的に任意のPSCと非PSCインターフェイスを識別します。同様に、IPルーティングプロトコルは、SPFアルゴリズムでIPデータグラムのルートを見つけるために使用されます。彼らはまた、CSPFアルゴリズムを使用することにより、非PSC回路のためのルートを見つけるために使用されています。
However, some additional mechanisms are needed to increase the scalability of these models and to deal with specific traffic engineering requirements of non-PSC layers. These mechanisms will be introduced in the following.
しかし、いくつかの追加のメカニズムは、これらのモデルの拡張性を高め、非PSC層の特定のトラフィックエンジニアリングの要件に対処するために必要とされています。これらのメカニズムは、以下に紹介します。
Re-using existing IP routing protocols allows for non-PSC layers taking advantage of all the valuable developments that took place since years for IP routing, in particular, in the context of intra-domain routing (link-state routing) and inter-domain routing (policy routing).
再使用して既存のIPルーティングプロトコルは、ドメイン内ルーティング（リンクステートルーティング）とドメイン間のコンテキストで、特に、IPルーティングのための年以来行われたすべての貴重な進展を活用して非PSC層が可能になりますルーティング（ポリシールーティング）。
In an overlay model, each particular non-PSC layer can be seen as a set of Autonomous Systems (ASs) interconnected in an arbitrary way. Similarly to the traditional IP routing, each AS is managed by a single administrative authority. For instance, an AS can be an SONET/SDH network operated by a given carrier. The set of interconnected ASs can be viewed as SONET/SDH internetworks.
オーバーレイモデルでは、各特定の非PSC層は、任意の方法で相互接続された自律システム（のAS）のセットとして見ることができます。同様に、伝統的なIPルーティングに、各ASは、単一の管理機関によって管理されています。例えば、ASは、所与のキャリアによって運営SONET / SDHネットワークとすることができます。相互接続のASのセットは、SONET / SDHインターネットワークとみなすことができます。
Exchange of routing information between ASs can be done via an inter-domain routing protocol like BGP-4. There is obviously a huge value of re-using well-known policy routing facilities provided by BGP in a non-PSC context. Extensions for BGP traffic engineering (BGP-TE) in the context of non-PSC layers are left for further study.
AS間ルーティング情報の交換は、BGP-4様ドメイン間ルーティングプロトコルを介して行うことができます。非PSCコンテキストでBGPが提供する再使用して、よく知られたポリシールーティング施設の巨大な値は明らかにあります。非PSC層のコンテキストでBGPトラフィックエンジニアリング（BGP-TE）のための拡張機能は、さらなる研究のために残されています。
Each AS can be sub-divided in different routing domains, and each can run a different intra-domain routing protocol. In turn, each routing-domain can be divided in areas.
各ASは、異なるルーティングドメインに細分することができ、それぞれが異なるドメイン内ルーティングプロトコルを実行することができます。順番に、各ルーティングドメインは領域に分割することができます。
A routing domain is made of GMPLS enabled nodes (i.e., a network device including a GMPLS entity). These nodes can be either edge nodes (i.e., hosts, ingress LSRs or egress LSRs), or internal LSRs. An example of non-PSC host is an SONET/SDH Terminal Multiplexer (TM). Another example is an SONET/SDH interface card within an IP router or ATM switch.
ルーティングドメインは、GMPLSで形成されている使用可能ノード（即ち、GMPLSエンティティを含むネットワークデバイス）。これらのノードはエッジノード（すなわち、ホスト、イングレスのLSRまたは出口LSRs）、または内部のLSRのいずれかであり得ます。非PSCホストの例は、SONET / SDHターミナルマルチプレクサ（TM）です。別の例では、IPルータまたはATMスイッチ内のSONET / SDHインターフェースカードです。
Note that traffic engineering in the intra-domain requires the use of link-state routing protocols like OSPF or IS-IS.
ドメイン内でのトラフィックエンジニアリングは、OSPFなどのリンクステートルーティングプロトコルの使用を必要とするか、またはIS-ISことに注意してください。
GMPLS defines extensions to these protocols. These extensions are needed to disseminate specific TDM, LSC and FSC static and dynamic characteristics related to nodes and links. The current focus is on intra-area traffic engineering. However, inter-area traffic engineering is also under investigation.
GMPLSは、これらのプロトコルへの拡張を定義します。これらの拡張機能は、特定のTDM、LSCとノードとリンクに関連したFSC静的および動的特性を広めるために必要とされています。現在の焦点は、エリア内のトラフィックエンジニアリングです。しかし、エリア間のトラフィックエンジニアリングは調査中でもあります。
The fact that IPv4 and/or IPv6 addresses are used does not imply at all that they should be allocated in the same addressing space than public IPv4 and/or IPv6 addresses used for the Internet. Private IP addresses can be used if they do not require to be exchanged with any other operator; public IP addresses are otherwise required. Of course, if an integrated model is used, two layers could share the same addressing space. Finally, TE links may be "unnumbered" i.e., not have any IP addresses, in case IP addresses are not available, or the overhead of managing them is considered too high.
IPv4および/またはIPv6アドレスが使用されているという事実は、彼らがインターネットのために使用されるパブリックIPv4および/またはIPv6アドレスと同じアドレス空間に割り当てられるべきであることは全く意味するものではありません。彼らは、他の事業者との間で交換する必要がない場合は、プライベートIPアドレスを使用することができます。パブリックIPアドレスは、それ以外の場合は必要とされます。統合モデルが使用されている場合はもちろん、二つの層は、同じアドレス空間を共有することができます。最後に、TEリンクは「番号なし」、すなわち、IPアドレスが利用できない、またはそれらを管理するためのオーバーヘッドが非常に高いと考えられる場合には、任意のIPアドレスを持っていないかもしれません。
Note that there is a benefit of using public IPv4 and/or IPv6 Internet addresses for non-PSC layers if an integrated model with the IP layer is foreseen.
IP層との統合モデルが予見される場合には非PSC層のためのパブリックIPv4および/またはIPv6インターネットアドレスを使用する利点があることに注意してください。
If we consider the scalability enhancements proposed in the next section, the IPv4 (32 bits) and the IPv6 (128 bits) addressing spaces are both more than sufficient to accommodate any non-PSC layer. We can reasonably expect to have much less non-PSC devices (e.g., SONET/SDH nodes) than we have today IP hosts and routers.
我々は次のセクションで提案されたスケーラビリティ拡張を考慮すれば、スペースをアドレスはIPv4（32ビット）とIPv6（128ビット）の両方の任意の非PSC層を収容するのに十分すぎるほどです。私たちは、合理的に、我々は今日のIPホストとルータを持っているよりもはるかに少ない非PSCデバイス（例えば、SONET / SDHノード）を持つことを期待することができます。
TDM, LSC and FSC layers introduce new constraints on the IP addressing and routing models since several hundreds of parallel physical links (e.g., wavelengths) can now connect two nodes. Most of the carriers already have today several tens of wavelengths per fiber between two nodes. New generation of DWDM systems will allow several hundreds of wavelengths per fiber.
並列物理リンク（例えば、波長）の数百は現在二つのノードを接続することができるので、TDM、LSCとFSC層は、IPアドレッシングおよびルーティングモデルに新たな制約を導入します。キャリアのほとんどは、すでに今日、2つのノード間のファイバあたりの波長の数十を持っています。 DWDMシステムの新世代は、ファイバあたりの波長の数百を許可します。
It becomes rather impractical to associate an IP address with each end of each physical link, to represent each link as a separate routing adjacency, and to advertise and to maintain link states for each of these links. For that purpose, GMPLS enhances the MPLS routing and addressing models to increase their scalability.
これは、各物理リンクの各端にIPアドレスを関連付けるために個別のルーティング隣接各リンクを表すために、およびアドバタイズすると、これらのリンクのそれぞれについてリンク状態を維持するためにかなり非現実的となります。そのために、GMPLSは、MPLSルーティングを高め、そのスケーラビリティを高めるためのモデルを扱います。
Two optional mechanisms can be used to increase the scalability of the addressing and the routing: unnumbered links and link bundling. These two mechanisms can also be combined. They require extensions to signaling (RSVP-TE and CR-LDP) and routing (OSPF-TE and IS-IS-TE) protocols.
アンナンバードリンクとリンクバンドル：2つのオプションのメカニズムは、アドレッシングとルーティングのスケーラビリティを向上させるために使用することができます。これら2つのメカニズムを組み合わせることもできます。彼らは（RSVP-TEやCR-LDP）及びルーティング（OSPF-TEおよびIS-IS-TE）シグナリングプロトコルへの拡張を必要とします。
Traditionally, a TE link is advertised as an adjunct to a "regular" OSPF or IS-IS link, i.e., an adjacency is brought up on the link. When the link is up, both the regular IGP properties of the link (basically, the SPF metric) and the TE properties of the link are then advertised.
伝統的に、TEリンクは、「通常の」OSPFやリンク、すなわち、隣接関係はリンクの上に育っている-ISの補助として宣伝されています。リンクは、アップすると、両方のリンク（基本的には、SPFメトリック）とリンクのTEのプロパティの定期的なIGP性質は、その後宣伝されています。
However, GMPLS challenges this notion in three ways:
しかし、GMPLSの3つの方法でこの概念に挑戦します：
- First, links that are non-PSC may yet have TE properties; however, an OSPF adjacency could not be brought up directly on such links.
- まず、非PSCあるリンクはまだTEの特性を有することができます。ただし、OSPFの隣接関係は、このようなリンクを直接起動することができませんでした。
- Second, an LSP can be advertised as a point-to-point TE link in the routing protocol, i.e., as a Forwarding Adjacency (FA); thus, an advertised TE link need no longer be between two OSPF direct neighbors. Forwarding Adjacencies (FA) are further described in Section 8.
- 第二に、LSPは、転送隣接（FA）として、即ち、ルーティングプロトコルにポイントツーポイントTEリンクとして広告することができます。このように、広告を出してTEのリンクは、2人のOSPFの直接の隣人の間ではもはや必要ありません。転送隣接関係（FA）はさらに、セクション8に記載されています。
- Third, a number of links may be advertised as a single TE link (e.g., for improved scalability), so again, there is no longer a one-to-one association of a regular adjacency and a TE link.
- 第三に、リンクの数（スケーラビリティの向上のために、例えば、）単一のTEリンクとして広告することができるので、再度、正規隣接し、TEリンクの一対一の関連付けがなくなります。
Thus, we have a more general notion of a TE link. A TE link is a logical link that has TE properties. Some of these properties may be configured on the advertising LSR, others may be obtained from other LSRs by means of some protocol, and yet others may be deduced from the component(s) of the TE link.
したがって、我々は、TEリンクのより一般的な概念を持っています。 TEリンクはTEの特性を有している論理リンクです。これらの特性のいくつかは他のものは、いくつかのプロトコルによって他のLSRから得ることができる、さらに他のものはTEリンクの成分（複数可）から推定することができる、広告LSRに構成されてもよいです。
An important TE property of a TE link is related to the bandwidth accounting for that link. GMPLS will define different accounting rules for different non-PSC layers. Generic bandwidth attributes are however defined by the TE routing extensions and by GMPLS, such as the unreserved bandwidth, the maximum reservable bandwidth and the maximum LSP bandwidth.
TEリンクの重要なTEプロパティは、そのリンクを占め帯域幅に関連しています。 GMPLSは異なる非PSC層のためのさまざまな会計ルールを定義します。一般的な帯域幅の属性は、しかしながら、TEルーティング拡張によって、そのような未予約帯域幅、最大予約可能帯域幅と最大のLSP帯域幅としてGMPLS、によって定義されます。
It is expected in a dynamic environment to have frequent changes of bandwidth accounting information. A flexible policy for triggering link state updates based on bandwidth thresholds and link-dampening mechanism can be implemented.
帯域幅の会計情報の頻繁な変更を持っているダイナミックな環境の中で期待されています。帯域幅閾値およびリンク減衰メカニズムに基づいてリンク状態の更新をトリガするための柔軟なポリシーを実施することができます。
TE properties associated with a link should also capture protection and restoration related characteristics. For instance, shared protection can be elegantly combined with bundling. Protection and restoration are mainly generic mechanisms also applicable to MPLS. It is expected that they will first be developed for MPLS and later on generalized to GMPLS.
リンクに関連したTEの特性はまた、保護と回復に関する特性をキャプチャする必要があります。例えば、共有保護はエレガントに束ねると組み合わせることができます。保護と回復は主にMPLSにも適用できる汎用的なメカニズムです。彼らが最初にMPLSのために開発され、後にGMPLSに一般化されることが期待されます。
A TE link between a pair of LSRs does not imply the existence of an IGP adjacency between these LSRs. A TE link must also have some means by which the advertising LSR can know of its liveness (e.g., by using LMP 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 GMPLS enhanced OSPF or IS-IS neighbors using the TE objects/TLVs. We call the interfaces over which GMPLS enhanced OSPF or IS-IS adjacencies are established "control channels".
LSRのペア間のTEリンクは、これらのLSR間のIGP隣接関係が存在することを意味するものではありません。 TEリンクはまた、広告LSRは（LMPのhelloを使用することにより、例えば）その生存性を知ることができるいくつかの手段を持っている必要があります。 LSRは、TEリンクがアップしていることを知っている、とTEリンクのTEの特性を決定することができたとき、LSRはそのGMPLSにそのリンクを広告するOSPFを増強またはTEオブジェクト/ TLVを使用してネイバー-ISがIS。私たちは、OSPFを強化GMPLSまたはIS-IS隣接関係が「制御チャネル」確立され、その上のインターフェイスを呼び出します。
Unnumbered links (or interfaces) are links (or interfaces) that do not have IP addresses. Using such links involves two capabilities: the ability to specify unnumbered links in MPLS TE signaling, and the ability to carry (TE) information about unnumbered links in IGP TE extensions of IS-IS-TE and OSPF-TE.
アンナンバードリンク（またはインターフェース）は、IPアドレスを持っていないリンク（またはインターフェース）です。 MPLS TEシグナリングにアンナンバードリンクを指定する機能、およびIS-IS-TEとOSPF-TEのIGP TE拡張でアンナンバードリンクについて（TE）の情報を運ぶ能力：そのようなリンクを使用することの2つの機能が含まれます。
A. The ability to specify unnumbered links in MPLS TE signaling requires extensions to RSVP-TE [RFC3477] and CR-LDP [RFC3480]. The MPLS-TE signaling does not provide support for unnumbered links, because it does not provide a way to indicate an unnumbered link in its Explicit Route Object/TLV and in its Record Route Object (there is no such TLV for CR-LDP). GMPLS defines simple extensions to indicate an unnumbered link in these two Objects/TLVs, using a new Unnumbered Interface ID sub-object/sub-TLV.
A. MPLS TEシグナリングに無数のリンクを指定する機能は、[RFC3477]とCR-LDP [RFC3480]-TEをRSVPの拡張を必要とします。それは、その明示的経路オブジェクト/ TLVそのレコードルートオブジェクト（CR-LDPのためのそのようなTLVが存在しない）でで無数のリンクを示すための方法を提供しないので、MPLS-TEシグナリングは、無数のリンクのためのサポートを提供しません。 GMPLSは、新しいアンナンバードインターフェイスIDサブオブジェクト/サブTLVを使用して、これら二つのオブジェクト/のTLVに無数のリンクを示すために、簡単な拡張を定義します。
Since unnumbered links are not identified by an IP address, then for the purpose of MPLS TE each end need some other identifier, local to the LSR to which the link belongs. LSRs at the two end-points of an unnumbered link exchange with each other the identifiers they assign to the link. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP ([LMP]), by means of RSVP-TE/CR-LDP (especially in the case where a link is a Forwarding Adjacency, see below), or by means of IS-IS or OSPF extensions ([ISIS-TE-GMPLS], [OSPF-TE-GMPLS]).
アンナンバードリンクはIPアドレスで識別されていないので、その後、MPLS TEの目的のために、それぞれの端にはリンクが所属するLSRへのローカルいくつかの他の識別子を、必要とします。それらはリンクに割り当てる識別子互いに無数のリンク交換の2つのエンドポイントでのLSR。識別子は、例えばLMP（[LMP]）などのプロトコルを用いて、構成することによって達成することができる交換、RSVP-TE / CR-LDPを用いて、（特にリンクが転送隣接場合には、以下を参照のこと）またはISIS又はOSPF拡張（[ISIS-TE-GMPLS]、[OSPF-TE-GMPLS]）によって。
Consider an (unnumbered) link between LSRs A and B. LSR A chooses an identifier 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間（番号なし）リンクがそのリンクの識別子を選択考えます。だから、LSR B.たちは、「リンクローカル識別子」としてリンクに割り当てられた識別子を参照してくださいAの視点から行います（または単に「ローカル識別子」）、およびBは、リモート「リンクとしてリンクに割り当てられた識別子へ識別子」（または単に 『リモート識別子』）。同様に、Bの視点からBがリンクに割り当てられた識別子はローカル識別子であり、リンクに割り当てられた識別子は、リモート識別子です。
The new Unnumbered Interface ID sub-object/sub-TLV for the ER Object/TLV contains the Router ID of the LSR at the upstream end of the unnumbered link and the link local identifier with respect to that upstream LSR.
新しい番号なしインターフェースIDサブオブジェクト/サブTLV ERオブジェクト用/ TLVは、無数のリンクの上流端にLSRのルータIDが含まれており、その上流のLSRに対して、リンクローカル識別子。
The new Unnumbered Interface ID sub-object for the RR Object contains the link local identifier with respect to the LSR that adds it in the RR Object.
RRオブジェクトの新しい番号なしインターフェースIDサブオブジェクトは、RRオブジェクトにそれを追加しLSRに対して、リンクローカル識別子を含みます。
B. The ability to carry (TE) information about unnumbered links in IGP TE extensions requires new sub-TLVs for the extended IS reachability TLV defined in IS-IS-TE and for the TE LSA (which is an opaque LSA) defined in OSPF-TE. A Link Local Identifier sub-TLV and a Link Remote Identifier sub-TLV are defined.
B. IGP TE拡張に無数のリンクについて（TE）情報を運ぶ能力を拡張するための新しいサブTLVを必要とするが、到達可能性TLVは、OSPFで定義されたIS-IS-TEおよび（オペークLSA）とTE LSAのために定義され-TE。リンクローカル識別子サブTLVおよびリンクリモート識別子サブTLVが定義されています。
If an LSR that originates an LSP advertises this LSP as an unnumbered FA in IS-IS or OSPF, or the LSR uses this FA as an unnumbered component link of a bundled link, the LSR must allocate an Interface ID to that FA. If the LSP is bi-directional, the tail end does the same and allocates an Interface ID to the reverse FA.
LSPを発信LSRは、IS-ISやOSPF、またはLSRで無数のFAとして、このLSPをアドバタイズバンドルリンクの無数のコンポーネントリンクとしてFAを使用する場合、LSRはそのFAにインターフェースIDを割り当てる必要があります。 LSPが双方向である場合には、テールエンドは、同じことを行い、逆FAのインタフェースIDを割り当てます。
Signaling has been enhanced to carry the Interface ID of a FA in the new LSP Tunnel Interface ID object/TLV. This object/TLV contains the Router ID (of the LSR that generates it) and the Interface ID. It is called the Forward Interface ID when it appears in a Path/REQUEST message, and it is called the Reverse Interface ID when it appears in the Resv/MAPPING message.
シグナリングは、新しいLSPトンネルインターフェイスIDのオブジェクト/ TLVでFAのインタフェースIDを運ぶために強化されました。このオブジェクト/ TLVは、（それを生成するLSRの）ルータのID及びインタフェースIDを含んでいます。それはパス/ REQUESTメッセージに表示されるとき、それはフォワードインタフェースIDと呼ばれ、それがのResv /マッピングメッセージに表示されたときには、リバース・インタフェースIDと呼ばれています。
The concept of link bundling is essential in certain networks employing the GMPLS control plane as is defined in [BUNDLE]. A typical example is an optical meshed network where adjacent optical cross-connects (LSRs) are connected by several hundreds of parallel wavelengths. In this network, consider the application of link state routing protocols, like OSPF or IS-IS, with suitable extensions for resource discovery and dynamic route computation. Each wavelength must be advertised separately to be used, except if link bundling is used.
リンクバンドリングの概念は、[バンドル]で定義されているようにGMPLS制御プレーンを用いた特定のネットワークに不可欠です。典型的な例は、隣接する光クロスコネクト（のLSR）を平行波長の数百によって接続された光メッシュネットワークです。このネットワークでは、資源の発見と動的経路計算に適した拡張子を持つOSPFまたはIS-ISのようなリンクステートルーティングプロトコルのアプリケーションを、考えます。各波長は、リンクバンドリングが使用されている場合を除き、使用されるように個別に宣伝する必要があります。
When a pair of LSRs is connected by multiple links, it is possible to advertise several (or all) of these links as a single link into OSPF and/or IS-IS. This process is called link bundling, or just bundling. The resulting logical link is called a bundled link as its physical links are called component links (and are identified by interface indexes).
LSRの一対の複数のリンクによって接続されている場合、それはOSPFに単一のリンクとしてこれらのリンクのいくつか（またはすべて）を宣伝することが可能であるおよび/またはIS-IS。このプロセスは、リンクバンドル、または単にバンドルと呼ばれています。得られた論理リンクは、物理リンクコンポーネントリンクと呼ばれ（及びインタフェースインデックスによって識別される）としてバンドルリンクと呼ばれます。
The result is that a combination of three identifiers ((bundled) link identifier, component link identifier, label) is sufficient to unambiguously identify the appropriate resources used by an LSP.
結果は、3つの識別子（（バンドル）リンク識別子、コンポーネントリンク識別子、ラベル）の組み合わせは明白LSPによって使用される適切なリソースを識別するのに十分であることです。
The purpose of link bundling is to improve routing scalability by reducing the amount of information that has to be handled by OSPF and/or IS-IS. This reduction is accomplished by performing information aggregation/abstraction. As with any other information aggregation/abstraction, this results in losing some of the information. To limit the amount of losses one need to restrict the type of the information that can be aggregated/abstracted.
リンクバンドルの目的は、OSPFによって扱われなければならない、および/または、ある情報の量を低減することにより、ルーティングのスケーラビリティを改善することです。この減少は、情報集合/抽象化を行うことによって達成されます。その他の情報の集約/抽象化と同じように、これは情報の一部を失うことになります。損失一方の量を制限する/抽象化集約することができる情報の種類を制限する必要があります。
The following restrictions are required for bundling links. All component links in a bundle must begin and end on the same pair of LSRs; and share some common characteristics or properties defined in [OSPF-TE] and [ISIS-TE], i.e., they must have the same:
次のような制限は、リンクをバンドルするために必要とされます。バンドル内のすべてのコンポーネントのリンクが始まるとのLSRの同じペアで終わらなければなりません。そして、すなわち、それらは同じでなければならず、いくつかの共通の特性または[OSPF-TE]と[ISIS-TE]で定義された特性を共有します。
- Link Type (i.e., point-to-point or multi-access), - TE Metric (i.e., an administrative cost), - Set of Resource Classes at each end of the links (i.e., colors).
- リンクのタイプ（すなわち、ポイントツーポイントまたはマルチアクセス）、 - TEメトリック（すなわち、管理コスト） - リンク（即ち、色）の各端部にリソースクラスのセット。
Note that a FA may also be a component link. In fact, a bundle can consist of a mix of point-to-point links and FAs, but all sharing some common properties.
FAはまた、コンポーネントリンクであってもよいことに留意されたいです。実際には、バンドルにはいくつかの共通の特性を共有するポイントツーポイントリンクとのFAが、すべての組み合わせで構成することができます。
A bundled link is just another kind of TE link such as those defined by [GMPLS-ROUTING]. The liveness of the bundled link is determined by the liveness of each its component links. A bundled link is alive when at least one of its component links is alive. The liveness of a component link can be determined by any of several means: IS-IS or OSPF hellos over the component link, or RSVP Hello (hop local), or LMP hellos (link local), or from layer 1 or layer 2 indications.
バンドルリンクは、[GMPLS-ROUTING]によって定義されたもののようなTEリンクのちょうど別の種類です。バンドルリンクの生存性は、それぞれのコンポーネントリンクの生存性によって決定されます。そのコンポーネントリンクの少なくとも一方が生きているときにバンドルリンクが生きています。いくつかの手段のいずれかによって決定することができるコンポーネントリンクのライブネス：コンポーネントリンクを介してIS-ISまたはOSPFのhello、またはRSVPハロー（ローカルホップ）、またはLMPのhello（リンクローカル）、またはレイヤ1またはレイヤ2からの指示。
Note that (according to the RSVP-TE specification [RFC3209]) the RSVP Hello mechanism is intended to be used when notification of link layer failures is not available and unnumbered links are not used, or when the failure detection mechanisms provided by the link layer are not sufficient for timely node failure detection.
（RSVP-TEの仕様に従って、[RFC3209]）RSVPハロー機構は、リンクレイヤ障害の通知がない場合に利用可能であり、無数のリンクが使用されていない使用されることが意図されることに留意されたいとき、またはリンク層により提供される故障検出機構タイムリーなノード障害の検出のために十分ではありません。
Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links.
バンドルリンクは生きていると判断されたら、それはTEリンクとして宣伝することができ、TE情報が氾濫することができます。 IS-IS / OSPFのhelloは、コンポーネントリンク上で実行されている場合は、IS-IS / OSPFフラッディングはコンポーネントリンクのひとつに制限することができます。
Note that advertising a (bundled) TE link between a pair of LSRs does not imply that there is an IGP adjacency between these LSRs that is associated with just that link. In fact, in certain cases a TE link between a pair of LSRs could be advertised even if there is no IGP adjacency at all between the LSR (e.g., when the TE link is an FA).
LSRのペア間（同梱）TEリンクを宣伝するだけでそのリンクに関連付けられているこれらのLSR間のIGP隣接関係があることを意味するものではないことに注意してください。実際には、特定の場合においてのLSRsの対の間のTEリンクは、LSR（例えば、TEリンクがFAである場合）との間に全くIGP隣接関係が存在しない場合であってもアドバタイズすることができました。
Forming a bundled link consist in aggregating the identical TE parameters of each individual component link to produce aggregated TE parameters. A TE link as defined by [GMPLS-ROUTING] has many parameters; adequate aggregation rules must be defined for each one.
バンドルリンクを形成する凝集TEパラメータを生成するために、各個々のコンポーネントのリンクの同一のTEパラメータを集約することからなります。 [GMPLS-ROUTING]によって定義されるTEリンクは、多くのパラメータを有しています。適切な集計規則は、それぞれのために定義されなければなりません。
Some parameters can be sums of component characteristics such as the unreserved bandwidth and the maximum reservable bandwidth. Bandwidth information is an important part of a bundle advertisement and it must be clearly defined since an abstraction is done.
いくつかのパラメータは、未予約帯域幅、最大予約可能帯域幅のような成分特性の合計とすることができます。帯域幅情報は、バンドル広告の重要な部分であり、抽象化が行われているので、それを明確に定義する必要があります。
A GMPLS node with bundled links must apply admission control on a per-component link basis.
バンドルリンクとGMPLSノードごとのコンポーネントリンクに基づいてアドミッション制御を適用しなければなりません。
Typically, an LSP's explicit route (e.g., contained in an explicit route Object/TLV) will choose the bundled link to be used for the LSP, but not the component link(s). This because information about the bundled link is flooded but information about the component links is not.
典型的には、（明示的経路オブジェクト/ TLVに含ま例えば、）LSPの明示的な経路がLSPに使用するバンドルのリンクを選択するではなく、コンポーネントのリンク（複数可）。このバンドルリンクの情報が氾濫が、コンポーネントのリンクに関する情報がないからです。
The choice of the component link to use is always made by an upstream node. If the LSP is bi-directional, the upstream node chooses a component link in each direction.
使用するコンポーネントリンクの選択は、常に上流のノードによって行われます。 LSPが双方向である場合、上流ノードは、各方向の成分のリンクを選択します。
Three mechanisms for indicating this choice to the downstream node are possible.
下流のノードにこの選択を指示するための3つのメカニズムが可能です。
This mechanism requires that each component link has a dedicated signaling channel (e.g., the link is a Sonet/SDH link using the DCC for in-band signaling). The upstream node tells the receiver which component link to use by sending the message over the chosen component link's dedicated signaling channel. Note that this signaling channel can be in-band or out-of-band. In this last case, the association between the signaling channel and that component link need to be explicitly configured.
この機構は、各コンポーネントリンクは、専用シグナリングチャネル（例えば、リンクがDCCを使用して、SONET / SDHリンクは、帯域内シグナリングのためのものである）を有することを必要とします。上流ノードは、選択されたコンポーネントのリンクの専用シグナリングチャネルを介してメッセージを送信することによって、使用するコンポーネントリンク受信機に伝えます。このシグナリングチャネルは、帯域内または帯域外とすることができることに留意されたいです。この最後の場合では、シグナリングチャネルとそのコンポーネントリンクとの間の関連付けは、明示的に設定する必要があります。
This mechanism requires that the component link has a unique remote IP address. The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV carrying either an IPv4 or an IPv6 address in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively). For a bi-directional LSP, a component link is provided for each direction by the upstream node.
このメカニズムは、コンポーネントリンクが独自のリモートIPアドレスを持っていることが必要です。上流ノードは新たIF_ID RSVP_HOPオブジェクト/ IPv4またはパス/ラベル要求メッセージにIPv6アドレスのいずれかを担持IF_ID TLV（それぞれ、[RFC3473] / [RFC3472]を参照）を含むことにより、コンポーネントリンクの選択を示しています。双方向LSPのために、コンポーネントリンクはアップストリームノードによって各方向に設けられています。
This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.
このメカニズムは、独自の制御チャネルを持つように、各コンポーネントのリンクを必要としません。実際には、それも、独自の制御チャネルを持つように全体（バンドル）リンクを必要としません。
With this mechanism, each component link that is unnumbered is assigned a unique Interface Identifier (32 bits value). The upstream node indicates the choice of the component link by including a new IF_ID RSVP_HOP object/IF_ID TLV in the Path/Label Request message (see [RFC3473]/[RFC3472], respectively).
このメカニズムで、無数の各成分のリンクは、固有のインターフェース識別子（32ビット値）が割り当てられます。上流ノードは新たIF_ID RSVP_HOPオブジェクト/パス/ラベル要求メッセージにIF_ID TLV（それぞれ、[RFC3473] / [RFC3472]を参照）を含むことにより、コンポーネントリンクの選択を示しています。
This object/TLV carries the component interface ID in the downstream direction for a unidirectional LSP, and in addition, the component interface ID in the upstream direction for a bi-directional LSP.
このオブジェクト/ TLVは、単方向LSPのために下流方向に、及び他にコンポーネントインタフェースID、双方向LSP用の上流方向におけるコンポーネントインタフェースIDを運びます。
The two LSRs at each end of the bundled link exchange these identifiers. Exchanging the identifiers may be accomplished by configuration, by means of a protocol such as LMP (preferred solution), by means of RSVP-TE/CR-LDP (especially in the case where a component link is a Forwarding Adjacency), or by means of IS-IS or OSPF extensions.
束ねられたリンクの各末端に2つのLSRは、これらの識別子を交換します。識別子を交換するRSVP-TE / CR-LDP（特にコンポーネントリンクが転送隣接の場合）、または手段によってによって、そのようなLMP（好適な溶液）などのプロトコルを用いて、構成することによって達成することができますIS-ISまたはOSPF拡張。
This mechanism does not require each component link to have its own control channel. In fact, it does not even require the whole (bundled) link to have its own control channel.
このメカニズムは、独自の制御チャネルを持つように、各コンポーネントのリンクを必要としません。実際には、それも、独自の制御チャネルを持つように全体（バンドル）リンクを必要としません。
A bundled link may itself be numbered or unnumbered independent of whether the component links are numbered or not. This affects how the bundled link is advertised in IS-IS/OSPF and the format of LSP EROs that traverse the bundled link. Furthermore, unnumbered Interface Identifiers for all unnumbered outgoing links of a given LSR (whether component links, Forwarding Adjacencies or bundled links) must be unique in the context of that LSR.
バンドルリンクは、それ自体の番号またはコンポーネントリンクが番号付けされているか否かの無数の独立していてもよいです。これは、バンドルリンクはIS-IS / OSPFとバンドルリンクを通過するLSPエロスの形式でアドバタイズされる方法に影響します。さらに、所与のLSRのすべての無数の発信リンクのための無数のインタフェース識別子は、（成分のリンクか、転送隣接関係またはバンドルリンク）そのLSRのコンテキスト内で一意でなければなりません。
The generic rule for bundling component links is to place those links that are correlated in some manner in the same bundle. If links may be correlated based on multiple properties then the bundling may be applied sequentially based on these properties. For instance, links may be first grouped based on the first property. Each of these groups may be then divided into smaller groups based on the second property and so on. The main principle followed in this process is that the properties of the resulting bundles should be concisely summarizable. Link bundling may be done automatically or by configuration. Automatic link bundling can apply bundling rules sequentially to produce bundles.
コンポーネントリンクを束ねるための一般的なルールは同じバンドルにいくつかの方法で相関しているこれらのリンクを配置することです。リンクは、複数のプロパティに基づいて相関させることができる場合、バンドルは、これらのプロパティに基づいて順次に適用することができます。例えば、リンクは、まず、第1の特性に基づいてグループ化することができます。これらの基の各々は、次に、第二の特性等に基づいて小さなグループに分割することができます。この過程で、続いて主要な原理は、得られた束の特性が簡潔に集計可能でなければならないということです。リンクバンドルには、自動的に、または設定することによって行うことができます。自動リンクバンドリングは、バンドルを生成するために順番に束ねるルールを適用することができます。
For instance, the first property on which component links may be correlated could be the Interface Switching Capability [GMPLS-ROUTING], the second property could be the Encoding [GMPLS-ROUTING], the third property could be the Administrative Weight (cost), the fourth property could be the Resource Classes and finally links may be correlated based on other metrics such as SRLG (Shared Risk Link Groups).
例えば、コンポーネントリンクが相関することができる、最初のプロパティは、機能[GMPLS-ROUTING]をインタフェース切替可能であり、第二の特性は、エンコーディング[GMPLS-ROUTING]とすることができる、第3の特性は、管理上の重み（コスト）とすることができます第四プロパティは、リソースクラス可能性があり、最終的にはリンクが、このようなSRLG（共有リスクリンクグループ）など、他のメトリックに基づいて相関させることができます。
When routing an alternate path for protection purposes, the general principle followed is that the alternate path is not routed over any link belonging to an SRLG that belongs to some link of the primary path. Thus, the rule to be followed is to group links belonging to exactly the same set of SRLGs.
保護の目的のために代替パスをルーティングする場合、一般的な原則は、その後は、代替パスがプライマリパスのいくつかのリンクに属しているSRLGに属する任意のリンクを介してルーティングされていないということです。このように、従うべきルールがSRLGsのとまったく同じセットに属するグループのリンクにあります。
This type of sequential sub-division may result in a number of bundles between two adjacent nodes. In practice, however, the link properties may not be very heterogeneous among component links between two adjacent nodes. Thus, the number of bundles in practice may not be large.
シーケンシャルサブ分割のこのタイプは、2つの隣接するノード間のバンドルの数をもたらすことができます。しかし、実際には、リンク特性は、2つの隣接ノード間のリンクのコンポーネントの間で非常に不均質ではないかもしれません。したがって、実際にはバンドルの数が大きくなくてもよいです。
The interface between an edge GMPLS node and a GMPLS LSR on the network side may be referred to as a User to Network Interface (UNI), while the interface between two-network side LSRs may be referred to as a Network to Network Interface (NNI).
二ネットワーク側のLSRとの間のインタフェースは、ネットワークインタフェース（NNIへのネットワークと呼ぶことができるが、エッジGMPLSノードとネットワーク側のGMPLSのLSRとの間のインタフェースは、ネットワークインタフェース（UNI）へのユーザと呼ぶことができます）。
GMPLS does not specify separately a UNI and an NNI. Edge nodes are connected to LSRs on the network side, and these LSRs are in turn connected between them. Of course, the behavior of an edge node is not exactly the same as the behavior of an LSR on the network side. Note also, that an edge node may run a routing protocol, however it is expected that in most of the cases it will not (see also section 5.2 and the section about signaling with an explicit route).
GMPLSは別途UNIとNNIを指定しません。エッジノードは、ネットワーク側のLSRに接続されており、これらのLSRは、順番に、それらの間に接続されています。もちろん、エッジノードの動作は、ネットワーク側のLSRの動作と全く同じではありません。エッジノードは、ルーティングプロトコルを実行することができることも注意してください、しかし、ほとんどの場合、それは（また、セクション5.2及び明示的経路とシグナリングに関するセクションを参照）ではないことが予想されます。
Conceptually, a difference between UNI and NNI make sense either if both interface uses completely different protocols, or if they use the same protocols but with some outstanding differences. In the first case, separate protocols are often defined successively, with more or less success.
概念的には、UNIとNNIの違いは、両方のインターフェイスが完全に異なるプロトコルを使用して、またはそれらが同じプロトコルを使用している場合場合は、いくつかの優秀な違いがいずれかの意味をなします。最初のケースでは、別のプロトコルは、多くの場合、多かれ少なかれ成功し、連続的に定義されています。
The GMPLS approach consisted in building a consistent model from day one, considering both the UNI and NNI interfaces at the same time [GMPLS-OVERLAY]. For that purpose, a very few specific UNI particularities have been ignored in a first time. GMPLS has been enhanced to support such particularities at the UNI by some other standardization bodies (see hereafter).
GMPLSアプローチは[GMPLSオーバーレイ]同時に両方UNIおよびNNIインターフェイスを考慮し、初日から一貫性のあるモデルを構築することにありました。そのために、非常に少数の特定のUNIの特殊性は、初めてでは無視されています。 GMPLSは、いくつかの他の標準化団体（以下参照）によりUNIで、このような特殊性をサポートするように拡張されました。
This section is only given for reference to the OIF work related to GMPLS. The current OIF UNI specification [OIF-UNI] defines an interface between a client SONET/SDH equipment and an SONET/SDH network, each belonging to a distinct administrative authority. It is designed for an overlay model. The OIF UNI defines additional mechanisms on the top of GMPLS for the UNI.
このセクションでは、唯一のGMPLSに関連OIFの仕事への参照のために与えられています。現在OIF UNI仕様[OIF-UNI]は、それぞれが別個の管理権限に属する、クライアントSONET / SDH装置とSONET / SDHネットワークとの間のインタフェースを定義しています。これは、オーバーレイモデルのために設計されています。 OIF UNIはUNIのためのGMPLSの上に追加のメカニズムを定義しています。
For instance, the OIF service discovery procedure is a precursor to obtaining UNI services. Service discovery allows a client to determine the static parameters of the interconnection with the network, including the UNI signaling protocol, the type of concatenation, the transparency level as well as the type of diversity (node, link, SRLG) supported by the network.
例えば、OIFサービス発見手順は、UNIサービスを得るための前駆体です。サービス発見は、クライアントがネットワークによってサポートUNIシグナリングプロトコル、連結の種類、透明度、並びに多様のタイプ（ノード、リンク、SRLG）を含むネットワークとの相互接続の静的パラメータを決定することを可能にします。
Since the current OIF UNI interface does not cover photonic networks, G.709 Digital Wrapper, etc, it is from that perspective a subset of the GMPLS Architecture at the UNI.
現在OIF UNIインターフェイスは等フォトニックネットワーク、G.709デジタルラッパーを、カバーしていないので、その観点からUNIにおけるGMPLSアーキテクチャのサブセットです。
This section discusses the selection of an explicit route by an edge node. The selection of the first LSR by an edge node connected to multiple LSRs is part of that problem.
このセクションでは、エッジノードによって明示的ルートの選択を論じています。複数のLSRに接続されたエッジノードによって最初LSRの選択は、その問題の一部です。
An edge node (host or LSR) can participate more or less deeply in the GMPLS routing. Four different routing models can be supported at the UNI: configuration based, partial peering, silent listening and full peering.
エッジノード（ホスト又はLSR）は、GMPLSルーティングに多少深く関与することができます。コンフィギュレーションに基づく、部分的ピアリング、サイレントリスニングとフルピアリング：四つの異なるルーティングモデルは、UNIでサポートすることができます。
- Configuration based: this routing model requires the manual or automatic configuration of an edge node with a list of neighbor LSRs sorted by preference order. Automatic configuration can be achieved using DHCP for instance. No routing information is exchanged at the UNI, except maybe the ordered list of LSRs. The only routing information used by the edge node is that list. The edge node sends by default an LSP request to the preferred LSR. ICMP redirects could be send by this LSR to redirect some LSP requests to another LSR connected to the edge node. GMPLS does not preclude that model.
- コンフィギュレーションベース：このルーティングモデルは、優先順位によってソート近隣のLSRのリストとエッジノードの手動または自動設定を必要とします。自動設定は、例えばDHCPを使用して達成することができます。何ルーティング情報は、のLSRのかもしれない順序付きリストを除き、UNIで交換されません。エッジノードによって使用のみルーティング情報は、そのリストです。エッジ・ノードは、デフォルトで好ましいLSRへLSP要求を送信します。 ICMPリダイレクトは、エッジノードに接続された他のLSRにいくつかのLSP要求をリダイレクトするために、このLSRによって送信することができます。 GMPLSは、そのモデルを排除するものではありません。
- Partial peering: limited routing information (mainly reachability) can be exchanged across the UNI using some extensions in the signaling plane. The reachability information exchanged at the UNI may be used to initiate edge node specific routing decision over the network. GMPLS does not have any capability to support this model today.
- 一部ピアリング：限定されたルーティング情報（主に到達可能）がシグナリング・プレーンにおけるいくつかの拡張を使用して、UNIを横切って交換することができます。 UNIで交換到達可能性情報をネットワークを介してエッジノード特定のルーティング決定を開始するために使用されてもよいです。 GMPLSは、今日、このモデルをサポートする任意の機能を持っていません。
- Silent listening: the edge node can silently listen to routing protocols and take routing decisions based on the information obtained. An edge node receives the full routing information, including traffic engineering extensions. One LSR should forward transparently all routing PDUs to the edge node. An edge node can now compute a complete explicit route taking into consideration all the end-to-end routing information. GMPLS does not preclude this model.
- サイレントリスニング：エッジノードは静かなルーティングプロトコルに耳を傾け、得られた情報に基づいてルーティング決定を行うことができます。エッジノードは、トラフィックエンジニアリングの拡張を含む完全なルーティング情報を受信します。一のLSRは、エッジノードに透過的にすべてのルーティングPDUを転送しなければなりません。エッジノードは、現在考慮すべてのエンドツーエンドルーティング情報を取る完全な明示的なルートを計算することができます。 GMPLSは、このモデルを排除するものではありません。
- Full peering: in addition to silent listening, the edge node participates within the routing, establish adjacencies with its neighbors and advertises LSAs. This is useful only if there are benefits for edge nodes to advertise themselves traffic engineering information. GMPLS does not preclude this model.
- フルピアリングは：サイレントリスニングに加えて、エッジノードは、ルーティング内参加し、隣国との隣接関係を確立し、LSAをアドバタイズします。これは、エッジノードは、自分自身にトラフィックエンジニアリング情報を宣伝するための利点がある場合にのみ有効です。 GMPLSは、このモデルを排除するものではありません。
In the context of GMPLS, a pair of nodes (e.g., a photonic switch) may be connected by tens of fibers, and each fiber may be used to transmit hundreds of wavelengths if DWDM is used. Multiple fibers and/or multiple wavelengths may also be combined into one or more bundled links for routing purposes. Furthermore, to enable communication between nodes for routing, signaling, and link management, control channels must be established between a node pair.
GMPLSの文脈では、ノードの対（例えば、フォトニックスイッチは）繊維数十によって接続され、各繊維は、DWDMが使用される場合、波長の何百を送信するために使用されてもよいです。複数の繊維および/または複数の波長は、ルーティングの目的のための1つ以上のバンドルリンクに結合されてもよいです。また、ルーティング、シグナリング、およびリンク管理のためのノード間の通信を可能にするために、制御チャネルは、ノード対の間で確立されなければなりません。
Link management is a collection of useful procedures between adjacent nodes that provide local services such as control channel management, link connectivity verification, link property correlation, and fault management. The Link Management Protocol (LMP) [LMP] has been defined to fulfill these operations. LMP has been initiated in the context of GMPLS but is a generic toolbox that can be also used in other contexts.
リンク管理は、制御チャネル管理、リンク接続性検証、リンク特性の相関関係、及び障害管理などのローカルサービスを提供する隣接ノードの間の有用な手順の集まりです。リンク管理プロトコル（LMP）[LMP]は、これらの操作を満たすために定義されています。 LMPは、GMPLSの文脈で開始されただけでなく、他のコンテキストで使用することができる汎用的なツールボックスです。
In GMPLS, the control channels between two adjacent nodes are no longer required to use the same physical medium as the data links between those nodes. Moreover, the control channels that are used to exchange the GMPLS control-plane information exist independently of the links they manage. Hence, LMP was designed to manage the data links, independently of the termination capabilities of those data links.
GMPLSでは、2つの隣接ノード間の制御チャネルは、もはやそれらのノード間のデータリンクと同じ物理的な媒体を使用するために必要とされません。また、GMPLS制御プレーンの情報を交換するために使用される制御チャネルは、独立して、それらが管理するリンクの存在します。したがって、LMPは、独立して、それらのデータリンクの終了能力の、データリンクを管理するように設計されました。
Control channel management and link property correlation procedures are mandatory per LMP. Link connectivity verification and fault management procedures are optional.
制御チャネル管理およびリンクプロパティ相関手続きLMPあたり必須です。リンク接続性検証や障害管理手順は任意です。
LMP control channel management is used to establish and maintain control channels between nodes. Control channels exist independently of TE links, and can be used to exchange MPLS control-plane information such as signaling, routing, and link management information.
LMP制御チャネル管理は、ノード間の制御チャネルを確立し、維持するために使用されます。制御チャネルは独立TEリンクの存在、およびそのようなシグナリング、ルーティング、リンク管理情報としてMPLSコントロールプレーンの情報を交換するために使用することができます。
An "LMP adjacency" is formed between two nodes that support the same LMP capabilities. Multiple control channels may be active simultaneously for each adjacency. A control channel can be either explicitly configured or automatically selected, however, LMP currently assume that control channels are explicitly configured while the configuration of the control channel capabilities can be dynamically negotiated.
「LMP隣接」は同じLMP機能をサポートする2つのノード間に形成されます。複数の制御チャネルは、各隣接同時にアクティブであってもよいです。制御チャネルは、明示的に設定されるか、または自動的に選択され、ただし、LMPは、現在の制御チャネル機能の設定を動的にネゴシエートすることができるが、制御チャネルが明示的に設定されていると仮定する。
For the purposes of LMP, the exact implementation of the control channel is left unspecified. The control channel(s) between two adjacent nodes is no longer required to use the same physical medium as the data-bearing links between those nodes. For example, a control channel could use a separate wavelength or fiber, an Ethernet link, or an IP tunnel through a separate management network.
LMPの目的のために、制御チャネルの正確な実装は、不特定のままです。 2つの隣接ノード間の制御チャネル（複数可）は、もはやそれらのノード間のデータ・ベアリング・リンクと同じ物理媒体を使用するために必要とされません。例えば、制御チャネルは、別個の管理ネットワークを介して別の波長またはファイバ、イーサネットリンク、またはIPトンネルを使用することができます。
A consequence of allowing the control channel(s) between two nodes to be physically diverse from the associated data-bearing links is that the health of a control channel does not necessarily correlate to the health of the data-bearing links, and vice-versa. Therefore, new mechanisms have been developed in LMP to manage links, both in terms of link provisioning and fault isolation.
2つのノード間の制御チャネル（複数可）は、関連するデータ・ベアリング・リンクから物理的に多様化されることを可能にするの結果は、制御チャネルの状態は、必ずしもデータ・ベアリング・リンクの健康と相関する、およびその逆ないことです。そのため、新しいメカニズムは、リンクのプロビジョニングおよび障害分離の両方の観点から、リンクを管理するためにLMPに開発されています。
LMP does not specify the signaling transport mechanism used in the control channel, however it states that messages transported over a control channel must be IP encoded. Furthermore, since the messages are IP encoded, the link level encoding is not part of LMP. A 32-bit non-zero integer Control Channel Identifier (CCId) is assigned to each direction of a control channel.
LMPは、制御チャネルで使用されるシグナリング・トランスポート機構を指定していない、しかし、それは、制御チャネル上で伝送メッセージはIP符号化しなければならないと述べています。メッセージはIP符号化されるので、リンク・レベルの符号化は、LMPの一部ではありません。 32ビットの非ゼロ整数制御チャネル識別子（CCID）は、制御チャネルの各方向に割り当てられます。
Each control channel individually negotiates its control channel parameters and maintains connectivity using a fast Hello protocol. The latter is required if lower-level mechanisms are not available to detect link failures.
各制御チャネルは、個別にその制御チャネルパラメータをネゴシエートし、高速のHelloプロトコルを使用して接続を維持します。下位レベルのメカニズムがリンク障害を検出するために利用可能でない場合は後者が必要とされます。
The Hello protocol of LMP is intended to be a lightweight keep-alive mechanism that will react to control channel failures rapidly so that IGP Hellos are not lost and the associated link-state adjacencies are not removed uselessly.
LMPのハロープロトコルはIGPハローズが失われていないと、関連するリンクステート隣接が無駄に除去されないように急速にチャネルの障害を制御するために反応する軽量キープアライブメカニズムであることを意図しています。
The Hello protocol consists of two phases: a negotiation phase and a keep-alive phase. The negotiation phase allows negotiation of some basic Hello protocol parameters, like the Hello frequency. The keep-alive phase consists of a fast lightweight bi-directional Hello message exchange.
ネゴシエーションフェーズとキープアライブ相：こんにちはプロトコルは、2つのフェーズで構成します。ネゴシエーションフェーズこんにちは周波数のように、いくつかの基本的なハロープロトコルパラメータのネゴシエーションを可能にします。キープアライブ相は、高速軽量な双方向Helloメッセージ交換で構成されています。
If a group of control channels share a common node pair and support the same LMP capabilities, then LMP control channel messages (except Configuration messages, and Hello's) may be transmitted over any of the active control channels without coordination between the local and remote nodes.
制御チャネルのグループは、共通ノード対を共有し、同じLMP機能をサポートしている場合、（構成メッセージ、およびハローの除く）をLMP制御チャネルメッセージは、ローカルとリモートノード間の調整なしにアクティブ制御チャネルのいずれかを介して送信されてもよいです。
For LMP, it is essential that at least one control channel is always available. In case of control channel failure, it may be possible to use an alternate active control channel without coordination.
LMPのために、少なくとも1つの制御チャネルが常に利用可能であることが不可欠です。制御チャネルに障害が発生した場合には、調整なし代替アクティブ制御チャネルを使用することも可能です。
As part of LMP, a link property correlation exchange is defined. The exchange is used to aggregate multiple data-bearing links (i.e., component links) into a bundled link and exchange, correlate, or change TE link parameters. The link property correlation exchange may be done at any time a link is up and not in the Verification process (see next section).
LMPの一環として、リンクプロパティ相関交換が定義されます。交換は、バンドルリンクと交換に複数のデータ・ベアリング・リンク（すなわち、コンポーネントリンク）を集約相関、またはTEリンクパラメータを変更するために使用されます。リンクプロパティ相関交換は、（次のセクションを参照）リンクが検証処理中にはなく、任意の時点で行うことができます。
It allows, for instance, the addition of component links to a link bundle, change of a link's minimum/maximum reservable bandwidth, change of port identifiers, or change of component identifiers in a bundle. This mechanism is supported by an exchange of link summary messages.
これは、例えば、リンクバンドル、リンクの最小/最大予約可能帯域幅、ポート識別子の変更、またはバンドル内のコンポーネント識別子の変化の変化に対する成分のリンクの追加を可能にします。このメカニズムは、リンクサマリメッセージの交換によってサポートされています。
Link connectivity verification is an optional procedure that may be used to verify the physical connectivity of data-bearing links as well as to exchange the link identifiers that are used in the GMPLS signaling.
リンク接続性検証は、データベアリングリンクの物理的な接続を確認するだけでなく、GMPLSシグナリングに使用されているリンク識別子を交換するために使用され得る任意の手順です。
This procedure should be performed initially when a data-bearing link is first established, and subsequently, on a periodic basis for all unallocated (free) data-bearing links.
この手順は、すべての未割り当て（無料）データ・ベアリング・リンクについて定期的に、その後のデータ・ベアリング・リンクが最初に確立されたときに最初に実行され、しなければなりません。
The verification procedure consists of sending Test messages in-band over the data-bearing links. This requires that the unallocated links must be opaque; however, multiple degrees of opaqueness (e.g., examining overhead bytes, terminating the payload, etc.), and hence different mechanisms to transport the Test messages, are specified. Note that the Test message is the only LMP message that is transmitted over the data-bearing link, and that Hello messages continue to be exchanged over the control channel during the link verification process. Data-bearing links are tested in the transmit direction as they are unidirectional. As such, it is possible for LMP neighboring nodes to exchange the Test messages simultaneously in both directions.
検証手順は、データ担持リンク上で帯域内テストメッセージを送信することから成ります。これは、未割り当てのリンクは不透明でなければならないことが必要です。しかしながら、不透明の多重度（例えば、など、オーバーヘッドバイトを検査ペイロードを終了）、テストメッセージを転送するための、したがって異なるメカニズムが、指定されています。テストメッセージは、データ・ベアリング・リンクを介して送信される唯一のLMPメッセージであること、およびHelloメッセージがリンク検証処理中に制御チャネルを介して交換され続けることに留意されたいです。彼らは単方向としてデータ・ベアリング・リンクが送信方向でテストされています。 LMP隣接ノードが両方向に同時にテストメッセージを交換するためにそのようなものとして、それが可能です。
To initiate the link verification procedure, a node must first notify the adjacent node that it will begin sending Test messages over a particular data-bearing link, or over the component links of a particular bundled link. The node must also indicate the number of data-bearing links that are to be verified; the interval at which the test messages will be sent; the encoding scheme, the transport mechanisms that are supported, the data rate for Test messages; and, in the case where the data-bearing links correspond to fibers, the wavelength over which the Test messages will be transmitted. Furthermore, the local and remote bundled link identifiers are transmitted at this time to perform the component link association with the bundled link identifiers.
リンク検証手順を開始するために、ノードは、最初に、特定のデータ・ベアリング・リンクを介してテストメッセージを送信し、または特定のバンドルリンクのコンポーネントリンク上で開始され、隣接ノードに通知しなければなりません。ノードは、検証されるべきデータ・ベアリング・リンクの数を示さなければなりません。テストメッセージが送信される間隔。符号化方式、サポートされているトランスポートメカニズム、テストメッセージのためのデータレート、そして、データ担持リンクがファイバに対応する場合には、波長がその上にテストメッセージが送信されます。また、ローカルとリモートのバンドルリンク識別子はバンドルリンク識別子を持つコンポーネントリンクの関連付けを行うために、この時点で送信されます。
Fault management is an important requirement from the operational point of view. Fault management includes usually: fault detection, fault localization and fault notification. When a failure occurs and is detected (fault detection), an operator needs to know exactly where it happened (fault localization) and a source node may need to be notified in order to take some actions (fault notification).
障害管理は、動作の観点から重要な要件です。障害管理は、通常は含まれています：障害検出、障害の局在と障害通知を。障害が発生し、（障害検知）が検出された場合、オペレータは、それが（障害ローカリゼーション）が起こった場所を正確に知る必要があり、ソースノードは、いくつかのアクション（障害通知）を取るために通知する必要があるかもしれません。
Note that fault localization can also be used to support some specific (local) protection/restoration mechanisms.
障害の局在はまた、いくつかの特定の（ローカル）の保護/回復メカニズムをサポートするために使用できることに注意してください。
In new technologies such as transparent photonic switching currently no method is defined to locate a fault, and the mechanism by which the fault information is propagated must be sent "out of band" (via the control plane).
透明な光スイッチングなどの新しい技術に現在のところ方法は、障害、および障害情報を（制御プレーンを介して）「帯域外」送信されなければならない伝播される機構を配置するために定義されていません。
LMP provides a fault localization procedure that can be used to rapidly localize link failures, by notifying a fault up to the node upstream of that fault (i.e., through a fault notification procedure).
LMPは急速に（すなわち、障害通知手順を介して）その障害の上流のノードに障害を通知することにより、リンク障害をローカライズするために使用することができる障害ローカライゼーション手順を提供します。
A downstream LMP neighbor that detects data link failures will send an LMP message to its upstream neighbor notifying it of the failure. When an upstream node receives a failure notification, it can correlate the failure with the corresponding input ports to determine if the failure is between the two nodes. Once the failure has been localized, the signaling protocols can be used to initiate link or path protection/restoration procedures.
データリンク障害を検出し、下流LMP隣人は障害のことを通知し、その上流の隣人へのLMPメッセージを送信します。上流ノードが障害通知を受信すると、故障が2つのノード間にあるかどうかを決定するために対応する入力ポートに障害を相関させることができます。障害がローカライズされたならば、シグナリングプロトコルは、リンクまたはパス保護/回復手順を開始するために使用することができます。
In an all-optical environment, LMP focuses on peer communications (e.g., OXC-to-OXC). A great deal of information about a link between two OXCs is known by the OLS (Optical Line System or WDM Terminal multiplexer). Exposing this information to the control plane can improve network usability by further reducing required manual configuration, and by greatly enhancing fault detection and recovery.
全光環境では、LMPは、ピア通信に焦点を当てて（例えば、OXCツーOXC）。 2つのOXC間のリンクについての多くの情報は、OLS（光回線システムやWDMターミナルマルチプレクサ）によって知られています。制御プレーンにこの情報を公開することをさらに必要な手動設定を低減することによって、ネットワークのユーザビリティを改善し、大幅に障害検出および回復を増強することによってすることができます。
LMP-WDM [LMP-WDM] defines extensions to LMP for use between an OXC and an OLS. These extensions are intended to satisfy the Optical Link Interface Requirements described in [OLI-REQ].
LMP-WDM [LMP-WDM]はOXCとOLSの間に使用するためのLMPへの拡張を定義します。これらの拡張機能は、[OLI-REQ]で説明した光リンクインタフェース要件を満たすことを目的としています。
Fault detection is particularly an issue when the network is using all-optical photonic switches (PXC). Once a connection is established, PXCs have only limited visibility into the health of the connection. Although the PXC is all-optical, long-haul OLSs typically terminate channels electrically and regenerate them optically. This provides an opportunity to monitor the health of a channel between PXCs. LMP-WDM can then be used by the OLS to provide this information to the PXC.
障害検出ネットワークは全光フォトニックスイッチ（PXC）を使用しているが特に問題です。接続が確立されると、PXCsは接続のみの健康への可視性が限られています。 PXCは、全光であるが、長距離OLSSは、典型的には、電気チャネルを終端し、光学的にそれらを再生します。これはPXCsとの間のチャネルの状態を監視するための機会を提供します。 LMP-WDMは、次いでPXCにこの情報を提供するために、OLSで使用することができます。
In addition to the link information known to the OLS that is exchanged through LMP-WDM, some information known to the OXC may also be exchanged with the OLS through LMP-WDM. This information is useful for alarm management and link monitoring (e.g., trace monitoring). Alarm management is important because the administrative state of a connection, known to the OXC (e.g., this information may be learned through the Admin Status object of GMPLS signaling [RFC3471]), can be used to suppress spurious alarms. For example, the OXC may know that a connection is "up", "down", in a "testing" mode, or being deleted ("deletion-in-progress"). The OXC can use this information to inhibit alarm reporting from the OLS when a connection is "down", "testing", or being deleted.
LMP-WDMを介して交換されるOLSに知られているリンク情報に加えて、OXCに知られているいくつかの情報はまた、LMP-WDM介しOLSと交換することができます。この情報は、アラーム管理及びリンク監視（例えば、トレース監視）のために有用です。 OXCに知られている接続の管理状態（例えば、この情報は[RFC3471]をGMPLSシグナリングの管理ステータスオブジェクトを介して知ることができる）ので、アラーム管理が重要であり、偽のアラームを抑制するために使用することができます。例えば、OXCは、接続が「上」、「テスト」モードで「ダウン」、または削除されている（「欠失進行中」）であることを知ることができます。 OXCは、接続が「ダウン」で、「テスト」、または削除されるとき、OLSからアラーム通知を抑制するために、この情報を使用することができます。
It is important to note that an OXC may peer with one or more OLSs and an OLS may peer with one or more OXCs. Although there are many similarities between an OXC-OXC LMP session and an OXC-OLS LMP session, particularly for control management and link verification, there are some differences as well. These differences can primarily be attributed to the nature of an OXC-OLS link, and the purpose of OXC-OLS LMP sessions. The OXC-OXC links can be used to provide the basis for GMPLS signaling and routing at the optical layer. The information exchanged over LMP-WDM sessions is used to augment knowledge about the links between OXCs.
OXCは、1つまたは複数のOLSSでじっとあり、OLSは、1つのまたは複数のOXCとピアリングできることに留意することが重要です。特に制御管理及びリンク検証のためのOXC-OXC LMPセッションとOXC-OLS LMPセッションの間に多くの類似点があるが、同様にいくつかの違いがあります。これらの違いは、主にOXC-OLSリンクの性質、およびOXC-OLS LMPセッションの目的に起因することができます。 OXC-OXCリンクシグナリング及び光学層でルーティングGMPLSのための基礎を提供するために使用することができます。 LMP-WDMセッション上で交換される情報は、のOXC間のリンクについての知識を増強するために使用されます。
In order for the information exchanged over the OXC-OLS LMP sessions to be used by the OXC-OXC session, the information must be coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP sessions are run independently and must be maintained separately. One critical requirement when running an OXC-OLS LMP session is the ability of the OLS to make a data link transparent when not doing the verification procedure. This is because the same data link may be verified between OXC-OLS and between OXC-OXC. The verification procedure of LMP is used to coordinate the Test procedure (and hence the transparency/opaqueness of the data links). To maintain independence between the sessions, it must be possible for the LMP sessions to come up in any order. In particular, it must be possible for an OXC-OXC LMP session to come up without an OXC-OLS LMP session being brought up, and vice-versa.
OXC-OXCセッションで使用するOXC-OLS LMPセッションを介して交換される情報のためのためには、情報がOXCによって調整されなければなりません。しかし、OXC-OXCとOXC-OLS LMPセッションは独立して実行され、別々に維持されなければなりません。 OXC-OLS LMPセッションを実行している1つの重要な要件は、検証手続きを行っていないときに、データリンクを透明にするOLSの能力です。同一のデータリンクはOXC-OLS間およびOXC-OXC間に検証することができるからです。 LMPの検証手順は、試験手順（したがって、データリンクの透明度/不透明）を調整するために使用されます。 LMPセッションは、任意の順序で考え出すためのセッション間の独立性を維持するために、それが可能でなければなりません。 OXC-OXC LMPセッションが育っさOXC-OLS LMPセッション、およびその逆ずに思い付くするために特に、それが可能でなければなりません。
The GMPLS signaling extends certain base functions of the RSVP-TE and CR-LDP signaling and, in some cases, adds functionality. These changes and additions impact basic LSP properties: how labels are requested and communicated, the unidirectional nature of LSPs, how errors are propagated, and information provided for synchronizing the ingress and egress.
GMPLSシグナリングは、RSVP-TEやCR-LDPシグナリングの特定の基底関数を拡張し、いくつかのケースでは、機能を追加します。エラーが伝播され、情報が入力および出力を同期させるために提供されているか、ラベルが要求されたと伝えているか、LSPの一方向の性質上、これらの変更や追加は、基本的なLSPの性質に影響を与えます。
The core GMPLS signaling specification is available in three parts:
コアGMPLSシグナリング仕様は、3つの部分で利用可能です。
1. A signaling functional description [RFC3471]. 2. RSVP-TE extensions [RFC3473]. 3. CR-LDP extensions [RFC3472].
機能説明シグナリング1. A [RFC3471]。 2. RSVP-TE拡張[RFC3473]。 3. CR-LDPの拡張[RFC3472]。
In addition, independent parts are available per technology:
また、独立した部分は、技術ごとに用意されています。
1. GMPLS extensions for SONET and SDH control [RFC3946]. 2. GMPLS extensions for G.709 control [GMPLS-G709].
SONETおよびSDH制御1. GMPLS拡張[RFC3946]。 G.709制御[GMPLS-G709] 2. GMPLS拡張。
The following MPLS profile expressed in terms of MPLS features [RFC3031] applies to GMPLS:
MPLS機能[RFC3031]で表さ次のMPLSプロファイルは、GMPLSに適用されます。
- Downstream-on-demand label allocation and distribution.
- ダウンストリームオンデマンドラベル割り当てと配布。
- Ingress initiated ordered control.
- 入力制御を命じ開始しました。
- Liberal (typical), or conservative (could) label retention mode.
- （標準）リベラル、あるいは保守的（可能性）ラベル保持モード。
- Request, traffic/data, or topology driven label allocation strategy.
- 要求、トラフィック/データ、またはトポロジードリブンラベル割り当て戦略。
- Explicit routing (typical), or hop-by-hop routing.
- 明示的ルーティング（標準）、またはホップバイホップルーティング。
The GMPLS signaling defines the following new building blocks on the top of MPLS-TE:
GMPLSシグナリングは、MPLS-TEの上に次の新しいビルディングブロックを定義します。
1. A new generic label request format. 2. Labels for TDM, LSC and FSC interfaces, generically known as Generalized Label. 3. Waveband switching support. 4. Label suggestion by the upstream for optimization purposes (e.g., latency). 5. Label restriction by the upstream to support some optical constraints. 6. Bi-directional LSP establishment with contention resolution. 7. Rapid failure notification extensions. 8. Protection information currently focusing on link protection, plus primary and secondary LSP indication. 9. Explicit routing with explicit label control for a fine degree of control. 10. Specific traffic parameters per technology. 11. LSP administrative status handling. 12. Control channel separation.
1.新しい汎用ラベル要求フォーマット。 TDM、LSCとFSCインターフェイス、2.ラベルを総称して一般化ラベルとして知られています。 3.波長群スイッチングサポート。最適化の目的（例えば、レイテンシ）のための上流4.ラベル提案。いくつかの光学的制約をサポートするために、上流5.ラベル制限。競合解決6.双方向LSPの確立。 7.迅速な障害通知の拡張機能。 8.保護情報は、現在、リンク保護に加え、プライマリおよびセカンダリLSP指標に焦点を当てました。コントロールの微度の明示的なラベルコントロール9.明示的なルーティング。技術あたり10.特定のトラフィックパラメータ。 11. LSP管理ステータスの扱い。前記制御チャネル分離。
These building blocks will be described in more details in the following. A complete specification can be found in the corresponding documents.
これらのビルディングブロックは、以下でより詳細に説明します。完全な仕様は、対応する文書に記載されています。
Note that GMPLS is highly generic and has many options. Only building blocks 1, 2 and 10 are mandatory, and only within the specific format that is needed. Typically, building blocks 6 and 9 should be implemented. Building blocks 3, 4, 5, 7, 8, 11 and 12 are optional.
GMPLSは非常に汎用的であり、多くのオプションを持っていることに注意してください。唯一のビルディングブロックは1、2及び10は、必須、およびのみ必要とされる特定のフォーマットの範囲内です。典型的には、ビルディングブロック6,9は、実施されるべきです。ビルディングブロック3、4、5、7、8、11及び12は任意です。
A typical SONET/SDH switching network would implement building blocks: 1, 2 (the SONET/SDH label), 6, 9, 10 and 11. Building blocks 7 and 8 are optional since the protection can be achieved using SONET/SDH overhead bytes.
典型的なSONET / SDHのスイッチングネットワークは、ビルディングブロック実装であろう：1、2（SONET / SDHのラベル）、6、9、10及び11のビルディングブロック7,8を保護は、SONET / SDHオーバーヘッドバイトを使用して達成することができるので、任意です。
A typical wavelength switching network would implement building blocks: 1, 2 (the generic format), 4, 5, 6, 7, 8, 9 and 11. Building block 3 is only needed in the particular case of waveband switching.
典型的な波長スイッチングネットワークは、ビルディングブロックを実装するであろう：1、2（汎用フォーマット）、4、5、6、7、8、9および11ビルディングブロック3のみ帯の切り替えの特定の場合において必要とされます。
A typical fiber switching network would implement building blocks: 1, 2 (the generic format), 6, 7, 8, 9 and 11.
1、2（汎用フォーマット）、6、7、8、9および11：典型的なファイバ交換網は、ビルディングブロックを実装することになります。
A typical MPLS-IP network would not implement any of these building blocks, since the absence of building block 1 would indicate regular MPLS-IP. Note however that building block 1 and 8 can be used to signal MPLS-IP as well. In that case, the MPLS-IP network can benefit from the link protection type (not available in CR-LDP, some very basic form being available in RSVP-TE). Building block 2 is here a regular MPLS label and no new label format is required.
ブロック1を構築するの不在は、通常のMPLS-IPを示すことになるので、一般的なMPLS-IPネットワークでは、これらのビルディング・ブロックのいずれかを実装していないでしょう。しかし、そのビルディングブロック注1及び8も同様にMPLS-IPをシグナリングするために使用することができます。その場合には、MPLS-IPネットワークは、リンク保護タイプ（CR-LDP、RSVP-TEで利用可能であるいくつかの非常に基本的な形で利用可能ではない）から利益を得ることができます。ビルディングブロック2は、ここでは通常のMPLSラベルで、新しいラベルフォーマットは必要ありません。
GMPLS does not specify any profile for RSVP-TE and CR-LDP implementations that have to support GMPLS - except for what is directly related to GMPLS procedures. It is to the manufacturer to decide which are the optional elements and procedures of RSVP-TE and CR-LDP that need to be implemented. Some optional MPLS-TE elements can be useful for TDM, LSC and FSC layers, for instance the setup and holding priorities that are inherited from MPLS-TE.
直接GMPLS手続きに関連しているものを除いて - GMPLSは、GMPLSをサポートする必要がRSVP-TEとCR-LDPの実装のための任意のプロファイルを指定しません。これは実装する必要がRSVP-TEやCR-LDPの任意の要素と手順であるかを決定するために製造業者にあります。いくつかのオプションのMPLS-TE素子は、例えば、セットアップとMPLS-TEから継承された優先順位を保持するため、TDM、LSCとFSC層のために有用であり得ます。
A TDM, LSC or FSC LSP is established by sending a PATH/Label Request message downstream to the destination. This message contains a Generalized Label Request with the type of LSP (i.e., the layer concerned), and its payload type. An Explicit Route Object (ERO) is also normally added to the message, but this can be added and/or completed by the first/default LSR.
TDMは、LSCまたはFSC LSPが宛先に下流PATH /ラベル要求メッセージを送信することによって確立されます。このメッセージは、LSPのタイプ（すなわち、層心配）、そのペイロードタイプと一般化ラベル要求を含みます。明示的ルート・オブジェクト（ERO）は、通常、メッセージに追加され、これは最初の/デフォルトのLSRによって追加及び/又は完了させることができます。
The requested bandwidth is encoded in the RSVP-TE SENDER_TSPEC object, or in the CR-LDP Traffic Parameters TLV. Specific parameters for a given technology are given in these traffic parameters, such as the type of signal, concatenation and/or transparency for a SONET/SDH LSP. For some other technology there be could just one bandwidth parameter indicating the bandwidth as a floating-point value.
要求された帯域幅は、RSVP-TE SENDER_TSPECオブジェクト内、またはCR-LDPトラフィックパラメータTLVでエンコードされています。所与の技術のための特定のパラメータは、SONET / SDH LSPのための信号、連結及び/又は透明の種類として、これらのトラフィックパラメータに与えられています。他のいくつかの技術のためのちょうど1つの帯域幅パラメータは、浮動小数点値として帯域幅を示す可能性があります。
The requested local protection per link may be requested using the Protection Information Object/TLV. The end-to-end LSP protection is for further study and is introduced LSP protection/restoration section (see after).
リンクあたり要求された地域の保護は、保護情報オブジェクト/ TLVを使用して要求することができます。エンドツーエンドのLSP保護は今後の検討課題であるとLSP保護/復元部（後を参照）が導入されます。
If the LSP is a bi-directional LSP, an Upstream Label is also specified in the Path/Label Request message. This label will be the one to use in the upstream direction.
LSPが双方向LSPの場合は、上流のラベルもパス/ラベル要求メッセージに指定されています。このラベルは、上流方向に使用する1つになります。
Additionally, a Suggested Label, a Label Set and a Waveband Label can also be included in the message. Other operations are defined in MPLS-TE.
また、推奨ラベル、ラベルの設定および波長群のラベルもメッセージに含めることができます。その他の操作は、MPLS-TEで定義されています。
The downstream node will send back a Resv/Label Mapping message including one Generalized Label object/TLV that can contain several Generalized Labels. For instance, if a concatenated SONET/SDH signal is requested, several labels can be returned.
下流のノードは、いくつかの一般ラベルを含めることができます1つの汎用ラベルオブジェクト/ TLVを含めたResv /ラベルマッピングメッセージを送り返します。連結SONET / SDH信号が要求された場合、例えば、複数のラベルを返すことができます。
In case of SONET/SDH virtual concatenation, a list of labels is returned. Each label identifying one element of the virtual concatenated signal. This limits virtual concatenation to remain within a single (component) link.
SONET / SDH仮想連結の場合には、ラベルのリストが返されます。各ラベルは、仮想連結信号の一つの要素を識別する。これは、単一の（コンポーネント）リンク内に留まるためにバーチャルコンカチネーションを制限します。
In case of any type of SONET/SDH contiguous concatenation, only one label is returned. That label is the lowest signal of the contiguous concatenated signal (given an order specified in [RFC3946]).
SONET / SDHの連続連結の任意のタイプの場合には、唯一つのラベルが返されます。そのラベルが連続連結信号の最低の信号である（[RFC3946]で指定された順序与えられます）。
In case of SONET/SDH "multiplication", i.e., co-routing of circuits of the same type but without concatenation but all belonging to the same LSP, the explicit ordered list of all signals that take part in the LSP is returned.
SONET / SDH「乗算」の場合には、同じタイプの回路、すなわち、同時ルーティングが、連結することなく、しかし、すべて同じLSPに属し、LSPに参加する全ての信号の明示的な順序付きリストが返されます。
The Generalized Label Request is a new object/TLV to be added in an RSVP-TE Path message instead of the regular Label Request, or in a CR-LDP Request message in addition to the already existing TLVs. Only one label request can be used per message, so a single LSP can be requested at a time per signaling message.
一般化ラベル要求ではなく通常ラベル要求のRSVP-TE Pathメッセージにおいて、または既存のTLVに加えてCR-LDP要求メッセージに追加される新しいオブジェクト/ TLVです。単一LSPがシグナリングメッセージあたりの時に要求できるように唯一つのラベルの要求は、メッセージごとに使用することができます。
The Generalized Label Request gives three major characteristics (parameters) required to support the LSP being requested: the LSP Encoding Type, the Switching Type that must be used and the LSP payload type called Generalized PID (G-PID).
LSPエンコーディングタイプ、使用されなければならない切換タイプと一般PID（G-PID）と呼ばれるLSPのペイロードタイプ：一般化ラベル要求は、要求されたLSPをサポートするために必要な3つの主要な特性（パラメータ）を提供します。
The LSP Encoding Type indicates the encoding type that will be used with the data associated with the LSP, i.e., the type of technology being considered. For instance, it can be SDH, SONET, Ethernet, ANSI PDH, etc. It represents the nature of the LSP, and not the nature of the links that the LSP traverses. This is used hop-by-hop by each node.
LSP符号化タイプは、技術のタイプが考慮され、すなわち、LSPに関連するデータと共に使用される符号化タイプを示します。例えば、それはLSPの性質ではなく、LSPが横断リンクの性質を表す等SDH、SONET、イーサネット（登録商標）、ANSI PDHすることができます。これは、各ノードがホップバイホップに使用されます。
A link may support a set of encoding formats, where support means that a link is able to carry and switch a signal of one or more of these encoding formats. The Switching Type indicates then the type of switching that should be performed on a particular link for that LSP. This information is needed for links that advertise more than one type of switching capability.
リンクは、支持リンクは、これらの符号化フォーマットのうちの1つまたは複数の信号を搬送し、切り替えることができることを意味する符号化フォーマットのセットをサポートすることができます。スイッチングタイプは、そのLSPのための特定のリンク上で実行されるべきスイッチングの種類を示します。この情報は、機能を切り替える複数のタイプの広告をリンクするために必要とされています。
Nodes must verify that the type indicated in the Switching Type is supported on the corresponding incoming interface; otherwise, the node must generate a notification message with a "Routing problem/Switching Type" indication.
ノードは、スイッチングタイプに示されるタイプは、対応する着信インターフェイス上でサポートされていることを確認しなければなりません。そうでない場合、ノードは、「ルーティング問題/スイッチングタイプ」表示と通知メッセージを生成しなければなりません。
The LSP payload type (G-PID) identifies the payload carried by the LSP, i.e., an identifier of the client layer of that LSP. For some technologies, it also indicates the mapping used by the client layer, e.g., byte synchronous mapping of E1. This must be interpreted according to the LSP encoding type and is used by the nodes at the endpoints of the LSP to know to which client layer a request is destined, and in some cases by the penultimate hop.
LSPのペイロードタイプ（G-PID）は、LSPによって運ばれるペイロード、すなわち、そのLSPのクライアント層の識別子を識別する。いくつかの技術のために、それはまた、クライアント層、例えば、E1のバイト同期マッピングによって使用されるマッピングを示しています。これは、LSP符号化タイプに従って解釈されなければならず、最後から二番目のホップによって要求を宛先とするクライアント層これまで、いくつかのケースで知ることがLSPの端点のノードによって使用されます。
Other technology specific parameters are not transported in the Generalized Label Request but in technology specific traffic parameters as explained hereafter. Currently, two set of traffic parameters are defined, one for SONET/SDH and one for G.709.
以下に説明するように、他の技術の特定のパラメータは、汎用ラベル要求ではなく、技術の特定のトラフィックパラメータに輸送されていません。現在、トラフィックパラメータの2セットは、SONET / SDH用とG.709のための1つを定義しています。
Note that it is expected than specific traffic parameters will be defined in the future for photonic (all optical) switching.
特定のトラフィックパラメータは、フォトニック（全光）は、スイッチングのために将来に定義されるであろうよりもそれが期待されていることに留意されたいです。
The GMPLS SONET/SDH traffic parameters [RFC3946] specify a powerful set of capabilities for SONET [ANSI-T1.105] and SDH [ITUT-G.707].
GMPLS SONET / SDHトラフィックパラメータ[RFC3946] SONET [ANSI-T1.105]とSDH [ITUT-G.707]のための機能の強力なセットを指定します。
The first traffic parameter specifies the type of the elementary SONET/SDH signal that comprises the requested LSP, e.g., VC-11, VT6, VC-4, STS-3c, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP.
最初のトラフィックパラメータは、いくつかの変換は、その後に、基本信号に連続して適用することができる等、要求LSPを含む基本SONET / SDH信号、例えば、VC-11、VT6の種類、VC-4、STS-3cは、指定します実際にLSPのために要求され、最終的な信号を構築します。
These transforms are the contiguous concatenation, the virtual concatenation, the transparency and the multiplication. Each one is optional. They must be applied strictly in the following order:
これらの変換は、連続した連結、仮想連結、透明性と乗算されています。それぞれが任意です。彼らは、次の順序で厳密に適用する必要があります。
- First, contiguous concatenation can be optionally applied on the Elementary Signal, resulting in a contiguously concatenated signal.
- まず、連続連結は、必要に応じて連続連結信号が得られ、基本信号に適用することができます。
- Second, virtual concatenation can be optionally applied either directly on the elementary Signal, or on the contiguously concatenated signal obtained from the previous phase.
- 第二に、バーチャルコンカチネーションは、必要に応じて直接基本信号に、または前段階から得られた連続連結信号のいずれかに適用することができます。
- Third, some transparency can be optionally specified when requesting a frame as signal rather than a container. Several transparency packages are defined.
- 信号としてフレームではなく、コンテナを要求するときに第三に、いくつかの透明度は、任意に指定することができます。いくつかの透明パッケージが定義されています。
- Fourth, a multiplication can be optionally applied either directly on the elementary Signal, or on the contiguously concatenated signal obtained from the first phase, or on the virtually concatenated signal obtained from the second phase, or on these signals combined with some transparency.
- 第四に、乗算は必要に応じて直接基本信号に、又は第一段階から得られた連続連結信号に、又は第二の相から得られた事実上連結信号に、またはいくつかの透明性と組み合わせ、これらの信号のいずれかに適用することができます。
For RSVP-TE, the SONET/SDH traffic parameters are carried in a new SENDER_TSPEC and FLOWSPEC. The same format is used for both. There is no Adspec associated with the SENDER_TSPEC, it is omitted or a default value is used. The content of the FLOWSPEC object received in a Resv message should be identical to the content of the SENDER_TSPEC of the corresponding Path message. In other words, the receiver is normally not allowed to change the values of the traffic parameters. However, some level of negotiation may be achieved as explained in [RFC3946].
RSVP-TEの場合は、SONET / SDHトラフィックパラメータは、新しいSENDER_TSPECとFLOWSPECで運ばれます。同じフォーマットの両方のために使用されます。 SENDER_TSPEC、それが省略されているか、デフォルト値が使用されているに関連付けられADSPECはありません。 Resvメッセージで受信FLOWSPECオブジェクトの内容は、対応するPathメッセージのSENDER_TSPECの内容と同一であるべきです。換言すれば、受信機は、通常のトラフィックパラメータの値を変更することは許されません。 [RFC3946]で説明したようしかし、交渉のあるレベルを達成することができます。
For CR-LDP, the SONET/SDH traffic parameters are simply carried in a new TLV.
CR-LDPのために、SONET / SDHのトラフィックパラメータは、単に新しいTLVで搬送されます。
Note that a general discussion on SONET/SDH and GMPLS can be found in [SONET-SDH-GMPLS-FRM].
SONET / SDHとGMPLS上の一般的な議論は[SONET、SDH-GMPLS-FRM]に見出すことができることに留意されたいです。
Simply said, an [ITUT-G.709] based network is decomposed in two major layers: an optical layer (i.e., made of wavelengths) and a digital layer. These two layers are divided into sub-layers and switching occurs at two specific sub-layers: at the OCh (Optical Channel) optical layer and at the ODU (Optical channel Data Unit) electrical layer. The ODUk notation is used to denote ODUs at different bandwidths.
光学層（すなわち、波長製）及びデジタル層：単に[ITUT-G.709]ベースのネットワークは、二つの主要な層に分解される、と述べました。これら二つの層は、副層に分割され、スイッチングは、2つの特定の副層で起こる：OCH（光チャネル）の光学層に及びODU（光チャネルデータユニット）に電気層。 ODUk表記は、異なる帯域幅でのODUを示すために使用されます。
The GMPLS G.709 traffic parameters [GMPLS-G709] specify a powerful set of capabilities for ITU-T G.709 networks.
GMPLS G.709トラフィックパラメータ[GMPLS-G709]は、ITU-T G.709のネットワークのための機能の強力なセットを指定します。
The first traffic parameter specifies the type of the elementary G.709 signal that comprises the requested LSP, e.g., ODU1, OCh at 40 Gbps, etc. Several transforms can then be applied successively on the elementary Signal to build the final signal being actually requested for the LSP.
最初のトラフィックパラメータは、例えば、ODU1、OCH3 40 Gbpsの、などのいくつかの変換は、実際に要求され、最終的な信号を構築するために基本信号に連続的に適用することができ、要求されたLSPを備える基本G.709信号の種類を指定しますLSPのために。
These transforms are the virtual concatenation and the multiplication. Each one of these transforms is optional. They must be applied strictly in the following order:
これらの変換は、仮想連結と乗算されています。これらの変換の各々は任意です。彼らは、次の順序で厳密に適用する必要があります。
- First, virtual concatenation can be optionally applied directly on the elementary Signal,
- まず、バーチャルコンカチネーションは、必要に応じて、基本信号に直接適用することができます
- Second, a multiplication can be optionally applied, either directly on the elementary Signal, or on the virtually concatenated signal obtained from the first phase.
- 第二に、乗算は、必要に応じて直接基本信号に、又は第一段階から得られる仮想連結信号のいずれかを適用することができます。
Additional ODUk Multiplexing traffic parameters allow indicating an ODUk mapping (ODUj into ODUk) for an ODUk multiplexing LSP request. G.709 supports the following multiplexing capabilities: ODUj into ODUk (k > j) and ODU1 with ODU2 multiplexing into ODU3.
追加のODUk多重トラフィックパラメータは、のODUk多重化LSP要求ためのODUkマッピング（のODUkにがODUj）を示すことを可能にします。 G.709は、次の多重化機能をサポートしていますがODUjのODUk（K> J）へとODU3へのODU2多重化とODU1。
For RSVP-TE, the G.709 traffic parameters are carried in a new SENDER-TSPEC and FLOWSPEC. The same format is used for both. There is no Adspec associated with the SENDER_TSPEC, it is omitted or a default value is used. The content of the FLOWSPEC object received in a Resv message should be identical to the content of the SENDER_TSPEC of the corresponding Path message.
RSVP-TEの場合は、G.709トラフィックパラメータは、新たな送信者TSPECとFLOWSPECで運ばれます。同じフォーマットの両方のために使用されます。 SENDER_TSPEC、それが省略されているか、デフォルト値が使用されているに関連付けられADSPECはありません。 Resvメッセージで受信FLOWSPECオブジェクトの内容は、対応するPathメッセージのSENDER_TSPECの内容と同一であるべきです。
For CR-LDP, the G.709 traffic parameters are simply carried in a new TLV.
CR-LDPのために、G.709トラフィックパラメータは、単に新しいTLVで運ばれます。
Some technologies that do not have (yet) specific traffic parameters just require a bandwidth encoding transported in a generic form. Bandwidth is carried in 32-bit number in IEEE floating-point format (the unit is bytes per second). Values are carried in a per protocol specific manner. For non-packet LSPs, it is useful to define discrete values to identify the bandwidth of the LSP.
持っていないいくつかの技術は（まだ）特定のトラフィックパラメータは、単に一般的な形態で輸送帯域幅のエンコードが必要です。帯域幅（単位は、秒あたりのバイト数である）IEEE浮動小数点形式の32ビットの数値で運ばれます。値は、プロトコルごとに特定の方法で実施されています。非パケットのLSPのために、LSPの帯域幅を識別するために、離散的な値を定義することが有用です。
It should be noted that this bandwidth encoding do not apply to SONET/SDH and G.709, for which the traffic parameters fully define the requested SONET/SDH or G.709 signal.
トラフィックパラメータが完全に要求されたSONET / SDHまたはG.709信号を定義するために、この帯域幅のエンコーディングはSONET / SDHおよびG.709には適用されないことに留意すべきです。
The bandwidth is coded in the Peak Data Rate field of Int-Serv objects for RSVP-TE in the SENDER_TSPEC and FLOWSPEC objects and in the Peak and Committed Data Rate fields of the CR-LDP Traffic Parameters TLV.
帯域幅はSENDER_TSPECとFLOWSPECオブジェクトにとピークにRSVP-TEのためのInt-Servのオブジェクトのピークデータレートフィールドに符号化され、CR-LDPトラフィックパラメータTLVのデータレートフィールドをコミットしています。
The Generalized Label extends the traditional MPLS label by allowing the representation of not only labels that travel in-band with associated data packets, but also (virtual) labels that identify time-slots, wavelengths, or space division multiplexed positions.
一般化ラベルは、関連するデータパケットと帯域内移動しないだけのラベルの表現を可能にすることによって、従来のMPLSラベルを拡張するだけでなく、タイムスロット、波長、または空間分割多重位置を識別（仮想）ラベル。
For example, the Generalized Label may identify (a) a single fiber in a bundle, (b) a single waveband within fiber, (c) a single wavelength within a waveband (or fiber), or (d) a set of time-slots within a wavelength (or fiber). It may also be a generic MPLS label, a Frame Relay label, or an ATM label (VCI/VPI). The format of a label can be as simple as an integer value such as a wavelength label or can be more elaborated such as an SONET/SDH or a G.709 label.
例えば、一般化ラベルは識別することができる（a）は、バンドル内の単繊維、（b）は、ファイバ内の単一波長帯、（c）の波長帯（またはファイバ）内の単一波長、または（d）のタイムセット波長（またはファイバ）内のスロット。また、一般的なMPLSラベル、フレームリレーのラベル、またはATMラベル（VCI / VPI）であってもよいです。ラベルの形式は、このような波長ラベルとして整数値のように単純であり得るか、またはそれ以上のこのようなSONET / SDH又はG.709ラベルとして精緻化することができます。
SDH and SONET define each a multiplexing structure. These multiplexing structures will be used as naming trees to create unique labels. Such a label will identify the exact position (times-lot(s)) of a signal in a multiplexing structure. Since the SONET multiplexing structure may be seen as a subset of the SDH multiplexing structure, the same format of label is used for SDH and SONET. A similar concept is applied to build a label at the G.709 ODU layer.
SDH及びSONETは、各多重化構造を定義します。これらの多重構造は、ユニークなラベルを作成するために木を命名として使用されます。そのようなラベルは、多重構造における信号の正確な位置（時間ロット（S））を特定します。 SONET多重構造はSDH多重構造のサブセットとして見ることができるので、ラベルの同じフォーマットは、SDH及びSONETのために使用されます。同様の概念は、G.709 ODUレイヤでラベルを構築するために適用されます。
Since the nodes sending and receiving the Generalized Label know what kinds of link they are using, the Generalized Label does not identify its type. Instead, the nodes are expected to know from the context what type of label to expect.
一般ラベルを送信側と受信側のノードは、彼らが使用しているリンクの種類を知っているので、一般ラベルは、そのタイプを識別しません。代わりに、ノードは、ラベルの種類を期待する文脈から知っていることが予想されます。
A Generalized Label only carries a single level of label i.e., it is non-hierarchical. When multiple levels of labels (LSPs within LSPs) are required, each LSP must be established separately.
一般化ラベルのみ、すなわち、それは非階層的であるラベルの単一レベルを運びます。ラベル（のLSP内のLSP）の複数のレベルが必要な場合、各LSPは別々に確立されなければなりません。
A special case of wavelength switching is waveband switching. A waveband represents a set of contiguous wavelengths, which can be switched together to a new waveband. For optimization reasons, it may be desirable for a photonic cross-connect to optically switch multiple wavelengths as a unit. This may reduce the distortion on the individual wavelengths and may allow tighter separation of the individual wavelengths. A Waveband label is defined to support this special case.
波長切替の特殊なケースは、波長帯の切り替えです。波長帯は、新しい波長帯に一緒に切り替えることができる連続した波長の集合を表します。光クロスコネクトは、光学ユニットとして複数の波長を切り替えるための最適化の理由から、それは望ましいかもしれません。これは、個々の波長の歪みを低減することができ、個々の波長の緊密な分離を可能にすることができます。波長群のラベルは、この特殊なケースをサポートするために定義されています。
Waveband switching naturally introduces another level of label hierarchy and as such the waveband is treated the same way, all other upper layer labels are treated. As far as the MPLS protocols are concerned, there is little difference between a waveband label and a wavelength label. Exception is that semantically the waveband can be subdivided into wavelengths whereas the wavelength can only be subdivided into time or statistically multiplexed labels.
波長帯は、自然ラベルスイッチング階層の別のレベルを導入し、このような波長帯が同じように処理されるように、他のすべての上層ラベルが処理されます。限りMPLSプロトコルが懸念しているとして、波長帯ラベルと波長ラベルの間にはほとんど違いがあります。例外は、波長だけ時間または統計的に多重化されたラベルに細分することができるのに対し、意味的に波長帯が波長に細分することができることです。
In the context of waveband switching, the generalized label used to indicate a waveband contains three fields, a waveband ID, a Start Label and an End Label. The Start and End Labels are channel identifiers from the sender perspective that identify respectively, the lowest value wavelength and the highest value wavelength making up the waveband.
波長帯の切り替えのコンテキストでは、波長帯を示すために使用される一般的なラベルは、三つのフィールド、波長帯のID、開始ラベルと終了ラベルが含まれています。開始と終了ラベルは、それぞれ特定の送信者の観点から、チャネル識別子、最低値の波長と波長帯を構成する最も価値の高い波長です。
GMPLS allows for a label to be optionally suggested by an upstream node. This suggestion may be overridden by a downstream node but in some cases, at the cost of higher LSP setup time. The suggested label is valuable when establishing LSPs through certain kinds of optical equipment where there may be a lengthy (in electrical terms) delay in configuring the switching fabric. For example, micro mirrors may have to be elevated or moved, and this physical motion and subsequent damping takes time. If the labels and hence switching fabric are configured in the reverse direction (the norm), the Resv/MAPPING message may need to be delayed by 10's of milliseconds per hop in order to establish a usable forwarding path. It can be important for restoration purposes where alternate LSPs may need to be rapidly established as a result of network failures.
GMPLSは、必要に応じて上流ノードによって示唆されるラベルを可能にします。この提案は、より高いLSPセットアップ時間を犠牲にして、下流のノードではなく、いくつかの場合には上書きされてもよいです。スイッチングファブリックの設定で（電気換算）長い遅延が存在し得る光学機器の特定の種類を介してLSPを確立する際に提案ラベルは価値があります。例えば、マイクロミラーが上昇又は移動させる必要があり、この物理的運動とその後の減衰時間がかかります。ラベルひいてはスイッチングファブリックが逆方向（ノルム）で構成されている場合、のResv /マッピングメッセージは、使用可能な転送パスを確立するためにホップ毎ミリ秒10件のだけ遅延される必要があるかもしれません。これは、代替のLSPが急速にネットワーク障害の結果として確立される必要があるかもしれない復元のために重要であり得ます。
An upstream node can optionally restrict (limit) the choice of label of a downstream node to a set of acceptable labels. Giving lists and/or ranges of inclusive (acceptable) or exclusive (unacceptable) labels in a Label Set provides this restriction. If not applied, all labels from the valid label range may be used. There are at least four cases where a label restriction is useful in the "optical" domain.
上流ノードは、任意的に許容可能なラベルのセットに（限界）下流ノードのラベルの選択を制限することができます。ラベルセットにリストおよび/または包括的（許容）または排他的（受け入れられない）ラベルの範囲を与えることは、この制限を提供します。適用されない場合は、有効なラベル範囲からすべてのラベルを使用することができます。ラベル制限は「光」ドメインに有用である、少なくとも4つのケースがあります。
Case 1: the end equipment is only capable of transmitting and receiving on a small specific set of wavelengths/wavebands.
ケース1：エンド装置は、波長/波長バンドの小さな特定のセット上で送信及び受信することができるだけです。
Case 2: there is a sequence of interfaces, which cannot support wavelength conversion and require the same wavelength be used end-to-end over a sequence of hops, or even an entire path.
ケース2：波長変換をサポートし、同じ波長がホップのシーケンス、あるいは経路全体にわたってエンド・ツー・エンドを使用することが必要としないことができるインターフェース、のシーケンスがあります。
Case 3: it is desirable to limit the amount of wavelength conversion being performed to reduce the distortion on the optical signals.
ケース3：光信号に歪みを低減するために行われている波長変換の量を制限することが望ましいです。
Case 4: two ends of a link support different sets of wavelengths.
ケース4：リンクの両端は、波長の異なるセットをサポートしています。
The receiver of a Label Set must restrict its choice of labels to one that is in the Label Set. A Label Set may be present across multiple hops. In this case, each node generates its own outgoing Label Set, possibly based on the incoming Label Set and the node's hardware capabilities. This case is expected to be the norm for nodes with conversion incapable interfaces.
ラベルセットの受信機は、ラベルセットである1にラベルのその選択を制限する必要があります。ラベルセットは、複数のホップ間で存在することができます。この場合、各ノードは、おそらく、着信ラベルを設定し、ノードのハードウェア機能に基づいた独自の発信ラベルセットを生成します。この場合には変換できないインタフェースを持つノードに対して標準であると予想されます。
GMPLS allows establishment of bi-directional symmetric LSPs (not of asymmetric LSPs). A symmetric bi-directional LSP has the same traffic engineering requirements including fate sharing, protection and restoration, LSRs, and resource requirements (e.g., latency and jitter) in each direction.
GMPLSは、双方向対称LSPの確立（ない非対称LSPの）可能にします。対称双方向LSPは、各方向における運命の共有、保護及び修復、のLSR、およびリソース要件（例えば、遅延およびジッタ）を含む同じトラフィックエンジニアリング要件を有しています。
In the remainder of this section, the term "initiator" is used to refer to a node that starts the establishment of an LSP; the term "terminator" is used to refer to the node that is the target of the LSP. For a bi-directional LSPs, there is only one initiator and one terminator.
このセクションの残りでは、用語「イニシエータ」は、LSPの確立を開始するノードを指すために使用されます。用語「ターミネーター」は、LSPの対象であるノードを指すために使用されます。双方向のLSPのために、唯一のイニシエータと1ターミネータがあります。
Normally to establish a bi-directional LSP when using RSVP-TE [RFC3209] or CR-LDP [RFC3212] two unidirectional paths must be independently established. This approach has the following disadvantages:
RSVP-TE [RFC3209]またはCR-LDP [RFC3212]を使用する場合、通常、双方向LSPを確立するために2つの単方向経路が独立して確立されなければなりません。このアプローチは、次のような欠点があります。
1. The latency to establish the bi-directional LSP is equal to one round trip signaling time plus one initiator-terminator signaling transit delay. This not only extends the setup latency for successful LSP establishment, but it extends the worst-case latency for discovering an unsuccessful LSP to as much as two times the initiator-terminator transit delay. These delays are particularly significant for LSPs that are established for restoration purposes.
1.待ち時間は、双方向LSPを1つの往復シグナリング時間プラスワンイニシエータターミネーターシグナル伝送遅延に等しい確立します。これが成功したLSPの確立のためのセットアップ・レイテンシを拡張するだけでなく、限り2回の開始剤 - ターミネーター通過遅延に失敗したLSPを発見するための最悪の場合の待ち時間を延長します。これらの遅延は、復旧のために確立されたLSPのために特に重要です。
2. The control overhead is twice that of a unidirectional LSP. This is because separate control messages (e.g., Path and Resv) must be generated for both segments of the bi-directional LSP.
2.制御オーバーヘッドはその倍の単方向LSPのです。別個の制御メッセージ（例えば、パスとのResv）は、双方向LSPの両方のセグメントについて生成しなければならないためです。
3. Because the resources are established in separate segments, route selection is complicated. There is also additional potential race for conditions in assignment of resources, which decreases the overall probability of successfully establishing the bi-directional connection.
3.リソースが別のセグメントに確立されているので、経路選択は複雑です。成功した双方向の接続を確立するの全体的な確率を減少させ、リソースの割り当て、中状態のため、追加の潜在的な競合もあります。
4. It is more difficult to provide a clean interface for SONET/SDH equipment that may rely on bi-directional hop-by-hop paths for protection switching. Note that existing SONET/SDH equipment transmits the control information in-band with the data.
4.保護スイッチングのための双方向のホップバイホップ経路に依存してもよいSONET / SDH機器のクリーンなインタフェースを提供することはより困難です。 SONET / SDH機器を既存のデータとインバンド制御情報を送信することに留意されたいです。
5. Bi-directional optical LSPs (or lightpaths) are seen as a requirement for many optical networking service providers.
前記双方向光のLSP（又は光パス）多くの光ネットワークサービスプロバイダーの要件として見られています。
With bi-directional LSPs both the downstream and upstream data paths, i.e., from initiator to terminator and terminator to initiator, are established using a single set of signaling messages. This reduces the setup latency to essentially one initiator-terminator round trip time plus processing time, and limits the control overhead to the same number of messages as a unidirectional LSP.
イニシエータからのターミネーターおよび開始するターミネーターに、双方向のLSPの両方のダウンストリーム及びアップストリームデータパス、すなわち、と、シグナリングメッセージの単一のセットを使用して確立されます。これは、本質的に1つのイニシエータターミネーターラウンドトリップ時間と処理時間に設定待ち時間を低減し、及び一方向LSPなどのメッセージの同じ数に制御オーバーヘッドを制限します。
For bi-directional LSPs, two labels must be allocated. Bi-directional LSP setup is indicated by the presence of an Upstream Label in the appropriate signaling message.
双方向のLSPのために、2つのラベルを割り当てる必要があります。双方向LSPセットアップは、適切なシグナリングメッセージの上流標識の存在によって示されます。
Contention for labels may occur between two bi-directional LSP setup requests traveling in opposite directions. This contention occurs when both sides allocate the same resources (ports) at effectively the same time. GMPLS signaling defines a procedure to resolve that contention: the node with the higher node ID will win the contention. To reduce the probability of contention, some mechanisms are also suggested.
ラベルの競合が反対方向に進行2双方向LSP設定要求間で起こり得ます。両側が効果的に同時に同じリソース（ポート）を割り当てる場合、この競合が発生します。 GMPLSシグナリングは、その競合を解決するための手順を定義しています。高いノードIDを持つノードが競合に勝つだろう。競合の可能性を減らすために、いくつかのメカニズムも提案されています。
GMPLS defines several signaling extensions that enable expedited notification of failures and other events to nodes responsible for restoring failed LSPs, and error handling.
GMPLSは、迅速な障害が発生したLSPを復元する責任ノードに障害やその他のイベントの通知、およびエラー処理を可能にするいくつかのシグナル拡張を定義します。
There are cases in traditional MPLS and in GMPLS that result in an error message containing an "Unacceptable label value" indication. When these cases occur, it can useful for the node generating the error message to indicate which labels would be acceptable. To cover this case, GMPLS introduces the ability to convey such information via the "Acceptable Label Set". An Acceptable Label Set is carried in appropriate protocol specific error messages. The format of an Acceptable Label Set is identical to a Label Set.
「許容できないラベル値」の表示を含むエラーメッセージが表示され、伝統的なMPLS内とGMPLSのケースがあります。これらのケースが発生したとき、それが示すエラーメッセージを生成するノードのために有用なそのラベルは許容可能であることができます。このケースをカバーするために、GMPLSは、「受け入れ可能なラベルセット」を介して、このような情報を伝えるための機能が導入されました。許容可能なラベルセットは、適切なプロトコル固有のエラーメッセージで運ばれます。許容可能なラベルセットの形式は、ラベルセットと同じです。
Extensions to RSVP-TE enable expedited notification of failures and other events to determined nodes. For CR-LDP, there is not currently a similar mechanism. The first extension identifies where event notifications are to be sent. The second provides for general expedited event notification with a Notify message. Such extensions can be used by fast restoration mechanisms. Notifications may be requested in both the upstream and downstream directions.
拡張機能は、RSVP-TEのために失敗し、決定ノードへの他のイベントの迅速な通知を可能にします。 CR-LDPのために、同様のメカニズムは現在存在しません。イベント通知が送信される場所を最初の拡張が識別されます。第二は、Notifyメッセージとの一般的な促進イベント通知を提供します。このような拡張は、高速復旧メカニズムによって使用することができます。通知は両方の上流及び下流方向で要求されてもよいです。
The Notify message is a generalized notification mechanism that differs from the currently defined error messages in that it can be "targeted" to a node other than the immediate upstream or downstream neighbor. The Notify message does not replace existing error messages. The Notify message may be sent either (a) normally, where non-target nodes just forward the Notify message to the target node, similar to ResvConf processing in [RFC2205]; or (b) encapsulated in a new IP header whose destination is equal to the target IP address.
通知メッセージは、それが即時の上流または下流の隣接以外のノードに対して「標的化」することができるという点で、現在定義されたエラーメッセージとは異なる一般的な通知メカニズムです。通知メッセージは、既存のエラーメッセージに代わるものではありません。通知メッセージは、非ターゲットノードがちょうど[RFC2205]にResvConf処理と同様に、ターゲット・ノードに通知メッセージを転送する場合、いずれかの（a）は通常送信されてもよいです。または（b）宛先目標IPアドレスと等しい新しいIPヘッダでカプセル化されました。
A specific RSVP optimization allowing in some cases the faster removal of intermediate states. This extension is used to deal with specific RSVP mechanisms.
いくつかのケースでは中間状態の速い除去を可能に特定のRSVPの最適化。この拡張は、特定のRSVPメカニズムに対処するために使用されます。
Protection information is carried in the new optional Protection Information Object/TLV. It currently indicates the desired link protection for each link of an LSP. If a particular protection type, i.e., 1+1, or 1:N, is requested, then a connection request is processed only if the desired protection type can be honored. Note that GMPLS advertises the protection capabilities of a link in the routing protocols. Path computation algorithms may consider this information when computing paths for setting up LSPs.
保護情報は、新しいオプションの保護情報オブジェクト/ TLVで運ばれます。これは、現在、LSPの各リンクの目的のリンクの保護を示します。すなわち、1 + 1、又は1、特に保護タイプの場合：N、要求され、次いで、接続要求は、所望の保護型が表彰することができる場合にのみ処理されます。 GMPLSは、ルーティングプロトコルにおけるリンクの保護機能をアドバタイズしていることに注意してください。 LSPを設定するためのパスを計算するときに経路計算アルゴリズムは、この情報を考慮することができます。
Protection information also indicates if the LSP is a primary or secondary LSP. A secondary LSP is a backup to a primary LSP. The resources of a secondary LSP are normally not used until the primary LSP fails, but they may be used by other LSPs until the primary LSP fails over the secondary LSP. At that point, any LSP that is using the resources for the secondary LSP must be preempted.
LSPは、一次または二次LSPであれば保護情報も示しています。二次LSPは、一次LSPにバックアップです。一次LSPが失敗するまで二次LSPのリソースは、通常使用されていないが、一次LSPは、二次LSP上に失敗するまで、彼らは、他のLSPによって使用されてもよいです。その時点で、セカンダリLSPのためのリソースを使用しているすべてのLSPを先取りしなければなりません。
Six link protection types are currently defined as individual flags and can be combined: enhanced, dedicated 1+1, dedicated 1:1, shared, unprotected, extra traffic. See [RFC3471] section 7.1 for a precise definition of each.
シックス・リンク保護タイプは、現在、個々のフラグとして定義されていると組み合わせることができます、共有、保護されていない、余分なトラフィックを1：、強化+ 1 1を捧げ、1を捧げました。それぞれの正確な定義のために[RFC3471]セクション7.1を参照。
By using an explicit route, the path taken by an LSP can be controlled more or less precisely. Typically, the node at the head-end of an LSP finds an explicit route and builds an Explicit Route Object (ERO)/ Explicit Route (ER) TLV that contains that route. Possibly, the edge node does not build any explicit route, and just transmit a signaling request to a default neighbor LSR (as IP/MPLS hosts would). For instance, an explicit route could be added to a signaling message by the first switching node, on behalf of the edge node. Note also that an explicit route is altered by intermediate LSRs during its progression towards the destination.
明示的なルートを使用することによって、LSPによって取られる経路は、多かれ少なかれ正確に制御することができます。典型的には、LSPのヘッドエンドにおけるノードは、明示的なルートを見つけ、その経路が含ま明示的ルート・オブジェクト（ERO）/明示的経路（ER）TLVを構築します。おそらく、エッジノードは、明示的なルートを構築せず、単にデフォルトの隣接LSR（IP / MPLSホストと同じように）にシグナリング要求を送信します。例えば、明示的経路は、エッジノードに代わって、第一スイッチングノードによってシグナリングメッセージに追加することができます。明示的なルートが目的地に向かってその進行中に中間のLSRによって変更されることにも留意されたいです。
The explicit route is originally defined by MPLS-TE as a list of abstract nodes (i.e., groups of nodes) along the explicit route. Each abstract node can be an IPv4 address prefix, an IPv6 address prefix, or an AS number. This capability allows the generator of the explicit route to have incomplete information about the details of the path. In the simplest case, an abstract node can be a full IP address (32 bits) that identifies a specific node (called a simple abstract node).
明示的な経路が元々抽象ノードのリストとしてMPLS-TEによって定義される（すなわち、ノードのグループ）明示的経路に沿っ。各抽象ノードは、IPv4アドレスのプレフィックス、IPv6アドレスのプレフィックス、またはAS番号を指定できます。この機能は、明示的なルートの発電機は、パスの詳細についての不完全な情報を持つことができます。最も単純なケースでは、抽象ノードは、（単純な抽象ノードと呼ばれる）特定のノードを識別する完全なIPアドレス（32ビット）とすることができます。
MPLS-TE allows strict and loose abstract nodes. The path between a strict node and its preceding node must include only network nodes from the strict node and its preceding abstract node. The path between a loose node and its preceding abstract node may include other network nodes that are not part of the loose node or its preceding abstract node.
MPLS-TEは、厳密とルーズ抽象ノードを可能にします。厳密ノードとその前のノードの間の経路は、厳密なノードからのみネットワークノードとその前の抽象ノードを含んでいなければなりません。ルーズノードとその前の抽象ノードの間の経路が緩んノードまたはその前の抽象ノードの一部ではない他のネットワークノードを含むことができます。
This explicit route was extended to include interface numbers as abstract nodes to support unnumbered interfaces; and further extended by GMPLS to include labels as abstract nodes. Having labels in an explicit route is an important feature that allows controlling the placement of an LSP with a very fine granularity. This is more likely to be used for TDM, LSC and FSC links.
この明示的なルートは無数のインタフェースをサポートする抽象ノードとインタフェース番号を含むように拡張しました。さらに抽象ノードとしてラベルを含むようにGMPLSによって拡張。明示的なルートのラベルを持つことは非常に細かい粒度でLSPの配置を制御することができる重要な機能です。これは、TDM、LSCとFSCのリンクに使用される可能性が高いです。
In particular, the explicit label control in the explicit route allows terminating an LSP on a particular outgoing port of an egress node. Indeed, a label sub-object/TLV must follow a sub-object/TLV containing the IP address, or the interface identifier (in case of unnumbered interface), associated with the link on which it is to be used.
具体的には、明示的経路に明示的ラベルの制御は、出口ノードの特定の出力ポートにLSPを終了することができます。実際、ラベルサブオブジェクト/ TLVは、IPアドレスを含むサブオブジェクト/ TLVに従わなければならない、またはそれが使用されるのリンクに関連付けられた（番号なしインターフェースの場合）インタフェース識別子、。
This can also be used when it is desirable to "splice" two LSPs together, i.e., where the tail of the first LSP would be "spliced" into the head of the second LSP.
最初のLSPの尾部は、第二LSPの先頭に「スプライシングされる」ことになる2つのLSP、すなわち、「スプライス」させることが望ましい場合に使用することもできます。
When used together with an optimization algorithm, it can provide very detailed explicit routes, including the label (timeslot) to use on a link, in order to minimize the fragmentation of the SONET/SDH multiplex on the corresponding interface.
最適化アルゴリズムと共に使用される場合、それは対応するインタフェースにSONET / SDHマルチプレックスの断片化を最小限にするために、リンク上で使用するラベル（タイムスロット）を含む非常に詳細な明示的なルートを提供することができます。
In order to improve the reliability and the manageability of the LSP being established, the concept of the route recording was introduced in RSVP-TE to function as:
信頼性と確立されたLSPの管理を改善するために、ルート記録の概念は、以下のように機能するRSVP-TEに導入されました。
- First, a loop detection mechanism to discover L3 routing loops, or loops inherent in the explicit route (this mechanism is strictly exclusive with the use of explicit routing objects).
- まず、L3ルーティングのループを検出するループ検出機構、または明示的な経路に固有のループ（このメカニズムは、明示的なルーティング・オブジェクトを用いて厳密に排他的です）。
- Second, a route recording mechanism collects up-to-date detailed path information on a hop-by-hop basis during the LSP setup process. This mechanism provides valuable information to the source and destination nodes. Any intermediate routing change at setup time, in case of loose explicit routing, will be reported.
- 第二に、経路記録機構は、LSPセットアッププロセス中にホップバイホップベースで最新の詳細な経路情報を収集します。この機構は、送信元ノードと宛先ノードに貴重な情報を提供します。セットアップ時に任意の中間ルーティングの変更は、緩い明示的なルーティングの場合には、報告されます。
- Third, a recorded route can be used as input for an explicit route. This is useful if a source node receives the recorded route from a destination node and applies it as an explicit route in order to "pin down the path".
- 第三に、記録された経路は、明示的な経路の入力として使用することができます。ソースノードが宛先ノードから記録されたルートを受信し、「パスを突き止める」するために明示的なルートとしてそれを適用する場合に便利です。
Within the GMPLS architecture, only the second and third functions are mainly applicable for TDM, LSC and FSC layers.
GMPLSアーキテクチャ内で、唯一第二及び第三の機能は、TDM、LSCとFSC層のために主に適用可能です。
LSP modification and re-routing are two features already available in MPLS-TE. GMPLS does not add anything new. Elegant re-routing is possible with the concept of "make-before-break" whereby an old path is still used while a new path is set up by avoiding double reservation of resources. Then, the node performing the re-routing can swap on the new path and close the old path. This feature is supported with RSVP-TE (using shared explicit filters) and CR-LDP (using the action indicator flag).
LSPの修正と再ルーティングは、MPLS-TEですでに利用可能な2つの機能です。 GMPLSは、新しいものを追加しません。エレガントな再ルーティングは、新たなパスがリソースの二重予約を回避することにより、設定されている間、古いパスがまだ使用されていることにより、「作る・ビフォア・ブレイク」の概念で可能です。次いで、再ルーティングを行うノードは、新しいパスに交換し、古いパスを閉じることができます。この機能は、RSVP-TE（共有明示的なフィルタを用いて）及び（アクションインジケータフラグを使用）CR-LDPでサポートされています。
LSP modification consists in changing some LSP parameters, but normally without changing the route. It is supported using the same mechanism as re-routing. However, the semantic of LSP modification will differ from one technology to the other. For instance, further studies are required to understand the impact of dynamically changing some SONET/SDH circuit characteristics such as the bandwidth, the protection type, the transparency, the concatenation, etc.
LSPの変更は、通常はルートを変更することなく、いくつかのLSPパラメータを変更することで構成されています。これは、再ルーティングと同じメカニズムを使用してサポートされています。しかし、LSPの修正の意味は、他の1つの技術とは異なります。例えば、さらなる研究を動的等帯域幅、保護型、透明、連結、などのいくつかのSONET / SDH回路特性を変化させる影響を理解するために必要とされます
GMPLS provides the optional capability to indicate the administrative status of an LSP by using a new Admin Status object/TLV. Administrative Status information is currently used in two ways.
GMPLSは、新しい管理ステータスオブジェクト/ TLVを使用することにより、LSPの管理ステータスを示すために、オプションの機能を提供します。管理ステータス情報は、現在、2つの方法で使用されます。
In the first usage, the Admin Status object/TLV is carried in a Path/Label Request or Resv/Label Mapping message to indicate the administrative state of an LSP. In this usage, Administrative Status information indicates the state of the LSP, which include "up" or "down", if it in a "testing" mode, and if deletion is in progress.
最初の使用では、管理ステータスオブジェクト/ TLVは、LSPの管理状態を示すために、パス/ラベル要求やたResv / Label Mappingメッセージで運ばれます。この使用法では、管理ステータス情報が削除が進行中である「テスト」モードであれば、および場合は、「アップ」または「ダウン」を含むLSPの状態を示しています。
Based on that administrative status, a node can take local decisions, like inhibit alarm reporting when an LSP is in "down" or "testing" states, or report alarms associated with the connection at a priority equal to or less than "Non service affecting".
その管理状況に基づいて、ノードは、LSPは「ダウン」または「テスト」状態にあるときに禁止アラームが報告のように、地元の意思決定を取る、またはそれに等しいか非サービスに影響」未満の優先順位での接続に関連付けられているアラームを報告することができます」。
It is possible that some nodes along an LSP will not support the Admin Status Object/TLV. In the case of a non-supporting transit node, the object will pass through the node unmodified and normal processing can continue.
LSPに沿っていくつかのノードは、管理ステータスオブジェクト/ TLVをサポートしていない可能性があります。非支持トランジットノードの場合には、オブジェクトは、非修飾および通常の処理を継続することができるノードを通過することになります。
In some circumstances, particularly optical networks, it is useful to set the administrative status of an LSP to "being deleted" before tearing it down in order to avoid non-useful generation of alarms. The ingress LSR precedes an LSP deletion by inserting an appropriate Admin Status Object/TLV in a Path/Label Request (with the modification action indicator flag set to modify) message. Transit LSRs process the Admin Status Object/TLV and forward it. The egress LSR answers in a Resv/Label Mapping (with the modification action indicator flag set to modify) message with the Admin Status object. Upon receiving this message and object, the ingress node sends a PathTear/Release message downstream to remove the LSP and normal RSVP-TE/CR-LDP processing takes place.
いくつかの状況、特に光ネットワークでは、アラームの非有用発生を回避するために、それを切断する前に、「削除中」するLSPの管理状態を設定することが有用です。入口LSRは、（変更する設定変更アクションインジケータフラグ付き）パス/ラベル要求メッセージ内の適切な管理ステータスオブジェクト/ TLVを挿入することによって、LSPの削除を先行します。トランジットのLSRは、管理ステータスオブジェクト/ TLVを処理し、それを転送します。 （変更する設定変更アクションインジケータフラグ付き）のResv /ラベルマッピング管理ステータスオブジェクトとのメッセージで出力LSR回答。このメッセージオブジェクトを受信すると、入口ノードは、LSPを除去するために下流PathTear /リリースメッセージを送信し、通常のRSVP-TE / CR-LDP処理が行われます。
In the second usage, the Admin Status object/TLV is carried in a Notification/Label Mapping (with the modification action indicator flag set to modify) message to request that the ingress node change the administrative state of an LSP. This allows intermediate and egress nodes triggering the setting of administrative status. In particular, this allows intermediate or egress LSRs requesting a release of an LSP initiated by the ingress node.
入口ノードは、LSPの管理状態を変更することを要求する第2の使用では、管理ステータスオブジェクト/ TLVを（変更する設定変更アクションインジケータフラグで）通知/ラベルマッピングで運ばれるメッセージ。これは、中間体および出口ノードが管理ステータスの設定をトリガすることができます。特に、これは、入口ノードによって開始されたLSPの解放を要求する中間又は出口LSRsを可能にします。
In GMPLS, a control channel be separated from the data channel. Indeed, the control channel can be implemented completely out-of-band for various reason, e.g., when the data channel cannot carry in-band control information. This issue was even originally introduced to MPLS in the context of link bundling.
GMPLSにおいて、制御チャネルは、データチャネルから分離します。データチャネルは、帯域内制御情報を運ぶことができない場合、実際に、制御チャネルは、例えば、様々な理由のためにアウトオブバンド完全に実現することができます。この問題はでも、もともとリンクバンドルのコンテキストでMPLSに導入されました。
In traditional MPLS, there is an implicit one-to-one association of a control channel to a data channel. When such an association is present, no additional or special information is required to associate a particular LSP setup transaction with a particular data channel.
従来のMPLSにおいて、データチャネルに対する制御チャネルの暗黙的な一対一の関連があります。そのような関連付けが存在する場合、追加の又は特別な情報は、特定のデータチャネルと、特定のLSPセットアップトランザクションを関連付けるために必要とされません。
Otherwise, it is necessary to convey additional information in signaling to identify the particular data channel being controlled. GMPLS supports explicit data channel identification by providing interface identification information. GMPLS allows the use of a number of interface identification schemes including IPv4 or IPv6 addresses, interface indexes (for unnumbered interfaces) and component interfaces (for bundled interfaces), unnumbered bundled interfaces are also supported.
そうでなければ、制御される特定のデータチャネルを識別するために、シグナリングに追加的な情報を伝える必要があります。 GMPLSは、インタフェース識別情報を提供することによって、明示的なデータチャネル識別をサポートします。 GMPLSは、（番号なしインターフェイスの場合）IPv4またはIPv6アドレス、インターフェースインデックスと（バンドルインターフェイスの）コンポーネント・インタフェースを含むインタフェース識別方式の数を使用することができ、無数のバンドルインターフェイスもサポートされています。
The choice of the data interface to use is always made by the sender of the Path/Label Request message, and indicated by including the data channel's interface identifier in the message using a new RSVP_HOP object sub-type/Interface TLV.
使用するデータ・インタフェースの選択は、常にパス/ラベル要求メッセージの送信者によって作られた、と新しいRSVP_HOPオブジェクトのサブタイプ/インタフェースTLVを使用して、メッセージ内のデータ・チャネルのインタフェース識別子を含めることによって示されます。
For bi-directional LSPs, the sender chooses the data interface in each direction. In all cases but bundling, the upstream interface is implied by the downstream interface. For bundling, the Path/Label Request sender explicitly identifies the component interface used in each direction. The new object/TLV is used in Resv/Label Mapping message to indicate the downstream node's usage of the indicated interface(s).
双方向のLSPのために、送信者は、各方向のデータインタフェースを選択します。全ての場合しかし結束において、上流インターフェースは、下流インタフェースによって暗示されています。束ねるため、パス/ラベルリクエスト送信者が明示的に各方向に使用されるコンポーネント・インタフェースを識別する。新しいオブジェクトが/ TLVが指示インターフェース（複数可）の下流ノードの使用状況を示すためのResv / Label Mappingメッセージに使用されます。
The new object/TLV can contain a list of embedded TLVs, each embedded TLV can be an IPv4 address, and IPv6 address, an interface index, a downstream component interface ID or an upstream component interface ID. In the last three cases, the embedded TLV contains itself an IP address plus an Interface ID, the IP address being used to identify the interface ID (it can be the router ID for instance).
新しいオブジェクトが/ TLVは、埋め込みのTLVのリストを含めることができ、各埋め込みTLVは、IPv4アドレス、IPv6アドレス、インタフェースインデックス、下流コンポーネントインタフェースIDまたは上流のコンポーネントインタフェースIDとすることができます。最後の三つのケースでは、埋め込まれたTLVは、それ自身のIPアドレスとインタフェースID、インタフェースIDを識別するために使用されているIPアドレスを（それは例えば、ルータIDであってもよい）を含みます。
There are cases where it is useful to indicate a specific interface associated with an error. To support these cases the IF_ID ERROR_SPEC RSVP Objects are defined.
エラーに関連付けられた特定のインターフェイスを示すために有用である場合があります。これらのケースをサポートするためにIF_ID ERROR_SPECのRSVPオブジェクトが定義されています。
To improve scalability of MPLS TE (and thus GMPLS) it may be useful to aggregate multiple TE LSPs inside a bigger TE LSP. Intermediate nodes see the external LSP only. They do not have to maintain forwarding states for each internal LSP, less signaling messages need to be exchanged and the external LSP can be somehow protected instead (or in addition) to the internal LSPs. This can considerably increase the scalability of the signaling.
MPLS TE（したがってGMPLS）のスケーラビリティを向上させるためには大きなTE LSP内の複数のTE LSPを集約することが有用であり得ます。中間ノードは、外部LSPを参照してください。彼らはそれぞれの内部LSPの転送状態を維持する必要はありません、以下のシグナリングメッセージを交換する必要があり、外部のLSPは何とか内部のLSPに（または加えて）の代わりに保護することができます。これはかなりのシグナリングのスケーラビリティを向上させることができます。
The aggregation is accomplished by (a) an LSR creating a TE LSP, (b) the LSR forming a forwarding adjacency out of that LSP (advertising this LSP as a Traffic Engineering (TE) link into IS-IS/OSPF), (c) allowing other LSRs to use forwarding adjacencies for their path computation, and (d) nesting of LSPs originated by other LSRs into that LSP (e.g., by using the label stack construct in the case of IP).
凝集は（a）のLSRがTE LSPを作成することによって達成される、（b）は、LSRは、LSPのうち転送隣接形成、（C（トラフィックエンジニアリング（TE）リンクとして、このLSPを広告IS-IS / OSPFに） ）他のLSRが、その経路計算の転送隣接関係を使用することができ、そのLSPに、他のLSRによって発信LSPの（d）のネスティング（例えば、ラベルスタックを使用して、IPの場合コンストラクト）。
ISIS/OSPF floods the information about "Forwarding Adjacencies" FAs just as it floods the information about any other links. Consequently to this flooding, an LSR has in its TE link state database the information about not just conventional links, but FAs as well.
ISIS / OSPFは、それが他のリンクに関する情報をフラッディングと同じように「フォワーディング隣接関係」のFAに関する情報をフラッディングします。したがって、この洪水に、LSRはそのTEリンク状態データベースだけではなく、従来のリンクに関する情報を持っていますが、FAのにも。
An LSR, when performing path computation, uses not just conventional links, but FAs as well. Once a path is computed, the LSR uses RSVP-TE/CR-LDP for establishing label binding along the path. FAs need simple extensions to signaling and routing protocols.
LSRは、経路計算を行う場合には、同様に従来のリンクが、FAのではないだけを使用しています。経路が計算されると、LSRは、経路に沿ってラベルバインディングを確立するためのRSVP-TE / CR-LDPを使用します。 FASがシグナリングプロトコルとルーティングへの簡単な拡張を必要とします。
Forwarding adjacencies may be represented as either unnumbered or numbered links. A FA can also be a bundle of LSPs between two nodes.
フォワーディング隣接関係は、非番号または番号のいずれかのリンクとして表すことができます。 FAはまた、2つのノード間のLSPの束とすることができます。
FAs are advertised as GMPLS TE links such as defined in [HIERARCHY]. GMPLS TE links are advertised in OSPF and IS-IS such as defined in [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. These last two specifications enhance [OSPF-TE] and [ISIS-TE] that defines a base TE link.
FAは[HIERARCHY]で定義されるようなGMPLS TEリンクとして宣伝されています。 GMPLS TEリンクは、[OSPF-TE-GMPLS]で定義され、[ISIS-TE-GMPLS]としてOSPFおよびISISにアドバタイズされます。これらの最後の2つの仕様を高める[OSPF-TE]とベースTEリンクを定義する[ISIS-TE]。
When a FA is created dynamically, its TE attributes are inherited from the FA-LSP that induced its creation. [HIERARCHY] specifies how each TE parameter of the FA is inherited from the FA-LSP. Note that the bandwidth of the FA must be at least as big as the FA-LSP that induced it, but may be bigger if only discrete bandwidths are available for the FA-LSP. In general, for dynamically provisioned forwarding adjacencies, a policy-based mechanism may be needed to associate attributes to forwarding adjacencies.
FAが動的に作成されると、そのTE属性は、その作成を誘発FA-LSPから継承されます。 [階層] FAの各TEパラメータは、FA-LSPから継承される方法を指定します。 FAの帯域幅がそれを誘発FA-LSPと少なくとも同じ大きさでなければなりませんが、唯一の離散的な帯域幅は、FA-LSPのために利用可能である場合に大きくなることがあります。一般的に、動的にプロビジョニングされた転送隣接のために、ポリシーベースのメカニズムは、転送隣接に属性を関連付けるために必要とされるかもしれません。
A FA advertisement could contain the information about the path taken by the FA-LSP associated with that FA. Other LSRs may use this information for path computation. This information is carried in a new OSPF and IS-IS TLV called the Path TLV.
FAの広告はそのFAに関連付けられているFA-LSPが取るパスに関する情報が含まれている可能性があります。他のLSRは、経路計算のために、この情報を使用することができます。この情報は、新しいOSPFで運ばれ、IS-IS TLVはパスTLVと呼ばれます。
It is possible that the underlying path information might change over time, via configuration updates, or dynamic route modifications, resulting in the change of that TLV.
基礎となる経路情報がそのTLVの変化をもたらす、設定の更新、または動的経路変更を介して、時間とともに変化する可能性があることが可能です。
If forwarding adjacencies are bundled (via link bundling), and if the resulting bundled link carries a Path TLV, the underlying path followed by each of the FA-LSPs that form the component links must be the same.
転送隣接は、（リンクバンドルを介して）バンドルされ、得られたバンドルリンクパスTLVを運ぶ場合、コンポーネントリンクを形成するFA-LSPの各々に続く基礎のパスは同じでなければならない。場合
It is expected that forwarding adjacencies will not be used for establishing IS-IS/OSPF peering relation between the routers at the ends of the adjacency.
転送隣接は隣接の端部にルータ間IS-IS / OSPFピアリング関係を確立するために使用されないことが予想されます。
LSP hierarchy could exist both with the peer and with the overlay models. With the peer model, the LSP hierarchy is realized via FAs and an LSP is both created and used as a TE link by exactly the same instance of the control plane. Creating LSP hierarchies with overlays does not involve the concept of FA. With the overlay model an LSP created (and maintained) by one instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control plane. Moreover, the nodes using a TE link are expected to have a routing and signaling adjacency.
LSP階層は、ピアとオーバレイモデルの両方で存在し得ます。ピア・モデルを用いて、LSPの階層は、Fasを介して実現され、LSPは、制御プレーンの厳密に同じインスタンスによって作成され、TEリンクとして使用され、両方。オーバーレイとLSPの階層を作成すると、FAの概念を必要としません。オーバーレイモデルとGMPLS制御プレーンの1つのインスタンスによって作成された（及び維持）LSPは、GMPLS制御プレーンの別のインスタンスによってTEリンクとして使用されます。また、TEリンクを使用して、ノードは、ルーティングおよびシグナリング隣接関係を有することが期待されます。
For the purpose of processing the explicit route in a Path/Request message of an LSP that is to be tunneled over a forwarding adjacency, an LSR at the head-end of the FA-LSP views the LSR at the tail of that FA-LSP as adjacent (one IP hop away).
転送隣接を通じてトンネリングされるLSPのパス/要求メッセージ内の明示的なルートを処理する目的のために、FA-LSPのヘッドエンドにおけるLSRは、FA-LSPの末尾にLSRを見隣接するとして（1つのIPは、ホップ離れて）。
With an integrated model, several layers are controlled using the same routing and signaling protocols. A network may then have links with different multiplexing/demultiplexing capabilities. For example, a node may be able to multiplex/demultiplex individual packets on a given link, and may be able to multiplex/demultiplex channels within a SONET payload on other links.
統合されたモデルを用いて、いくつかの層は、同一のルーティングおよびシグナリングプロトコルを使用して制御されます。その後、ネットワークは、異なる多重化/逆多重化機能を備えたリンクを有することができます。例えば、ノードは、所与のリンク上の個々のパケットを逆多重化/多重化することができる場合があり、そして他のリンク上のSONETペイロード内のチャネルを逆多重化/多重化することができるかもしれません。
A new OSPF and IS-IS sub-TLV has been defined to advertise the multiplexing capability of each interface: PSC, L2SC, TDM, LSC or FSC. This sub-TLV is called the Interface Switching Capability Descriptor sub-TLV, which complements the sub-TLVs defined in
PSC、L2SC、TDM、LSCまたはFSC：新しいOSPFやサブTLV-ISは、各インターフェイスの多重化機能をアドバタイズするように定義されています。このサブTLVが定義サブTLVを補完する能力ディスクリプタサブTLVを、スイッチングインタフェースと呼ばれ
[OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. The information carried in this sub-TLV is used to construct LSP regions, and determine region's boundaries.
[OSPF-TE-GMPLS]および[ISIS-TE-GMPLS]。このサブTLVで搬送される情報は、LSPの領域を構築し、地域の境界を決定するために使用されます。
Path computation may take into account region boundaries when computing a path for an LSP. For example, path computation may restrict the path taken by an LSP to only the links whose multiplexing/demultiplexing capability is PSC. When an LSP need to cross a region boundary, it can trigger the establishment of an FA at the underlying layer (i.e., the L2SC layer). This can trigger a cascading of FAs between layers with the following obvious order: L2SC, then TDM, then LSC, and then finally FSC.
LSPのパスを計算する際の経路計算は、アカウントの領域境界にかかる場合があります。例えば、経路計算は、多重化/逆多重化能力PSCされたリンクのみLSPによって取られる経路を制限することができます。 LSPは、領域境界を横断する必要がある場合には、下地層（すなわち、L2SC層）でFAの確立をトリガすることができます。その後、L2SC、その後、TDM、その後、LSC、そして最後にFSC：これは、次の明白な順序で層の間のFAのカスケードを誘発することができます。
By definition, two nodes have a routing (IS-IS/OSPF) adjacency if they are neighbors in the IS-IS/OSPF sense.
彼らはIS-IS / OSPFの意味で隣接している場合は、定義により、2つのノードは、ルーティング（IS-IS / OSPF）隣接関係を持っています。
By definition, two nodes have a signaling (RSVP-TE/CR-LDP) adjacency if they are neighbors in the RSVP-TE/CR-LDP sense. Nodes A and B are RSVP-TE neighbors if they directly exchange RSVP-TE messages (Path/Resv) (e.g., as described in sections 7.1.1 and 7.1.2 of [HIERARCHY]). The neighbor relationship includes exchanging RSVP-TE Hellos.
それらはRSVP-TE / CR-LDPの意味で隣接している場合、定義により、2つのノードは、シグナリング（RSVP-TE / CR-LDP）隣接関係を有しています。それらは直接RSVP-TEメッセージ（パス/のResv）（例えば、[HIERARCHY]のセクション7.1.1および7.1.2に記載されているように）を交換した場合、ノードA及びBは、RSVP-TE隣人です。隣接関係は、RSVP-TE helloを交換しています。
By definition, a Forwarding Adjacency (FA) is a TE Link between two GMPLS nodes whose path transits one or more other (G)MPLS nodes in the same instance of the (G)MPLS control plane. If two nodes have one or more non-FA TE Links between them, these two nodes are expected (although not required) to have a routing adjacency. If two nodes do not have any non-FA TE Links between them, it is expected (although not required) that these two nodes would not have a routing adjacency. To state the obvious, if the TE links between two nodes are to be used for establishing LSPs, the two nodes must have a signaling adjacency.
定義により、転送隣接（FA）は、経路（G）MPLSコントロールプレーンの同じインスタンス内の1つまたは複数の他の（G）MPLSノードを通過する2つのGMPLSノード間のTEリンクです。 2つのノードがそれらの間に1つ以上の非FA TEリンクを持っている場合、これら二つのノードは、ルーティング隣接関係を有することが（必須ではないが）が期待されます。 2つのノードが、それらの間の任意の非FA TEリンクを持っていない場合は、これら2つのノードは、ルーティング隣接関係を持っていないことを（必須ではないが）期待されています。 2つのノード間のTEリンクがLSPを確立するために使用される場合、明白なことを述べるために、2つのノードは、シグナリング隣接を持っている必要があります。
If one wants to establish routing and/or signaling adjacency between two nodes, there must be an IP path between them. This IP path can be, for example, a TE Link with an interface switching capability of PSC, anything that looks likes an IP link (e.g., GRE tunnel, or a (bi-directional) LSP that with an interface switching capability of PSC).
1は、2つのノード間のルーティングおよび/またはシグナリング隣接関係を確立することを望んでいる場合は、それらの間のIPパスが存在しなければなりません。このIPパスは、例えば、PSCの機能を切り替えるインターフェースを持つTEリンク、（PSCの機能を切り替えるインタフェースであることなど、GREトンネル、または（双方向）LSP）IPリンクを好きに見える何かをすることができ。
A TE link may not be capable of being used directly for maintaining routing and/or signaling adjacencies. This is because GMPLS routing and signaling adjacencies requires exchanging data on a per frame/ packet basis, and a TE link (e.g., a link between OXCs) may not be capable of exchanging data on a per packet basis. In this case, the routing and signaling adjacencies are maintained via a set of one or more control channels (see [LMP]).
TEリンクは、ルーティングの維持及び/又は隣接シグナリングのために直接使用されることが可能ではないかもしれません。 GMPLSルーティングおよびシグナリング隣接フレーム/パケット単位でデータを交換する必要があり、TEリンクが（例えば、のOXC間のリンク）は、パケット単位でデータを交換することができない場合があるからです。この場合には、ルーティングおよびシグナリング隣接関係は、1つまたは複数の制御チャネルのセットを介して維持される（[LMP]参照）。
Two nodes may have a TE link between them even if they do not have a routing adjacency. Naturally, each node must run OSPF/IS-IS with GMPLS extensions in order for that TE link to be advertised. More precisely, the node needs to run GMPLS extensions for TE Links with an interface switching capability (see [GMPLS-ROUTING]) other than PSC. Moreover, this node needs to run either GMPLS or MPLS extensions for TE links with an interface switching capability of PSC.
彼らは、ルーティング隣接関係を持っていない場合でも、2つのノードは、それらの間のTEリンクを有することができます。当然のことながら、OSPFを実行する必要があり、各ノードは、/ IS-IS広告することTEリンクのために、GMPLS拡張子を持ちます。より正確には、ノードは、インターフェーススイッチング能力（参照[GMPLS-ROUTING]）PSC以外でTEリンクのGMPLS拡張を実行する必要があります。また、このノードは、PSCのインタフェーススイッチング能力を有するTEリンクにGMPLS又はMPLS拡張機能のいずれかを実行する必要があります。
The mechanisms for Control Channel Separation [RFC3471] should be used (even if the IP path between two nodes is a TE link). I.e., RSVP-TE/CR-LDP signaling should use the Interface_ID (IF_ID) object to specify a particular TE link when establishing an LSP.
制御チャネルセパレーション[RFC3471]のためのメカニズムは、（2つのノード間のIPパスがTEリンクであっても）使用されるべきです。即ち、RSVP-TE / CR-LDPシグナリングは、LSPを確立する際に、特定のTEリンクを指定するInterface_ID（IF_ID）オブジェクトを使用する必要があります。
The IP path could consist of multiple IP hops. In this case, the mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used (in addition to Control Channel Separation).
IPパスが複数のIPホップから構成できます。この場合、[HIERARCHY]のセクション7.1.1及び7.1.2のメカニズムは、（チャネル分離の制御に加えて）使用されるべきです。
Two major types of faults can impact a control plane. The first, referred to as control channel fault, relates to the case where control communication is lost between two neighboring nodes. If the control channel is embedded with the data channel, data channel recovery procedure should solve the problem. If the control channel is independent of the data channel, additional procedures are required to recover from that problem.
障害の2つの主要なタイプは、コントロールプレーンに影響を与えることができます。制御チャネルの障害と呼ばれる、最初は、制御通信は、二つの隣接ノード間で失われた場合にも関します。制御チャネルは、データチャネルに埋め込まれている場合は、データ・チャネル・リカバリ手順は、問題を解決する必要があります。制御チャネルは、データチャネルとは独立している場合は、追加の手順がその問題から回復するために必要とされています。
The second, referred to as nodal faults, relates to the case where node loses its control state (e.g., after a restart) but does not loose its data forwarding state.
第二は、ノード障害と呼ばれる、ノードが（再起動後など、）その制御状態を失うが、状態を転送し、そのデータを失わない場合にも関します。
In transport networks, such types of control plane faults should not have service impact on the existing connections. Under such circumstances, a mechanism must exist to detect a control communication failure and a recovery procedure must guarantee connection integrity at both ends of the control channel.
トランスポート・ネットワークでは、制御プレーン障害のようなタイプは、既存の接続上のサービスへの影響を有してはなりません。このような状況下では、機構は、制御チャネルの両端の接続の完全性を保証しなければならない制御通信障害と回復手順を検出するために存在しなければなりません。
For a control channel fault, once communication is restored routing protocols are naturally able to recover but the underlying signaling protocols must indicate that the nodes have maintained their state through the failure. The signaling protocol must also ensure that any state changes that were instantiated during the failure are synchronized between the nodes.
通信が復元されると、制御チャネルの障害のために、ルーティングプロトコルは、自然に回復することが可能であるが、基礎となるシグナリングプロトコルは、ノードが障害を通ってその状態を維持していることを示さなければなりません。シグナリングプロトコルは、障害時にインスタンス化された任意の状態変化は、ノード間で同期されていることを確認しなければなりません。
For a nodal fault, a node's control plane restarts and loses most of its state information. In this case, both upstream and downstream nodes must synchronize their state information with the restarted node. In order for any resynchronization to occur the node undergoing the restart will need to preserve some information, such as it's mappings of incoming to outgoing labels.
結節障害のために、ノードの制御プレーンを再起動し、その状態情報のほとんどを失います。この場合、上流および下流の両方のノードが再起動ノードとそれらの状態情報を同期化しなければなりません。再起動を受けたノードを発生する任意の再同期ためには、それが発信ラベルに着信のマッピングだなど、いくつかの情報を保存する必要があります。
These issues are addressed in protocol specific fashions, see [RFC3473], [RFC3472], [OSPF-TE-GMPLS] and [ISIS-TE-GMPLS]. Note that these cases only apply when there are mechanisms to detect data channel failures independent of control channel failures.
これらの問題は、[RFC3472]、[OSPF-TE-GMPLS]および[ISIS-TE-GMPLS]、[RFC3473]を参照して、プロトコル特定様式で対処されます。制御チャネル障害の独立したデータチャネルの障害を検出するためのメカニズムが存在する場合、これらの場合にのみ適用されます。
The LDP Fault tolerance (see [RFC3479]) specifies the procedures to recover from a control channel failure. [RFC3473] specifies how to recover from both a control channel failure and a node failure.
LDPフォールトトレランスは、（[RFC3479]を参照）は、制御チャネルの障害から回復するための手順を指定します。 [RFC3473]は、制御チャネルの障害とノード障害の両方から回復する方法を指定します。
This section discusses Protection and Restoration (P&R) issues for GMPLS LSPs. It is driven by the requirements outlined in [RFC3386] and some of the principles outlined in [RFC3469]. It will be enhanced, as more GMPLS P&R mechanisms are defined. The scope of this section is clarified hereafter:
このセクションでは、GMPLSのLSPのための保護と復元（P＆R）の問題について説明します。これは、[RFC3386]に概説要件および[RFC3469]に概説された原理の一部によって駆動されます。もっとGMPLS P＆Rのメカニズムが定義されているように、それは、強化されます。このセクションの範囲は、以下を明らかにされています。
- This section is only applicable when a fault impacting LSP(s) happens in the data/transport plane. Section 10 deals with control plane fault handling for nodal and control channel faults.
- LSPに影響を与える障害（s）はデータ/輸送面で起こる場合、このセクションにのみ適用可能です。節結節及び制御チャネルの障害のための取り扱いコントロールプレーンの障害を持つ10件の取引。
- This section focuses on P&R at the TDM, LSC and FSC layers. There are specific P&R requirements at these layers not present at the PSC layer.
- このセクションでは、TDM、LSCとFSC層でP＆Rに焦点を当てています。 PSC層に存在しないこれらの層における特定P＆Rの要件があります。
- This section focuses on intra-area P&R as opposed to inter-area P&R and even inter-domain P&R. Note that P&R can even be more restricted, e.g., to a collection of like customer equipment, or a collection of equipment of like capabilities, in one single routing area.
- インター領域P＆Rともドメイン間P＆Rとは対照的に、このセクションでは、イントラ領域P＆Rに焦点を当てています。 P＆Rは、一つでも単一のルーティングエリアに、のような顧客機器のコレクション、等の機能の機器の集合体に、例えば、より抑制することができることに留意されたいです。
- This section focuses on intra-layer P&R (horizontal hierarchy as defined in [RFC3386]) as opposed to the inter-layer P&R (vertical hierarchy).
- 層間P＆R（縦階層）とは対照的に、このセクションでは、イントラ層P＆R（水平階層[RFC3386]で定義されるように）に焦点を当てています。
- P&R mechanisms are in general designed to handle single failures, which makes SRLG diversity a necessity. Recovery from multiple failures requires further study.
- P＆RメカニズムはSRLG多様必要になり、単一の障害を処理するように設計された一般的です。複数の障害からの回復はさらなる研究が必要です。
- Both mesh and ring-like topologies are supported.
- メッシュおよびリング状のトポロジの両方がサポートされています。
In the following, we assume that:
以下では、我々はそれを前提としています。
- TDM, LSC and FSC devices are more generally committing recovery resources in a non-best effort way. Recovery resources are either allocated (thus used) or at least logically reserved (whether used or not by preemptable extra traffic but unavailable anyway for regular working traffic).
- TDM、LSCとFSCのデバイスは、より一般的に非ベストエフォートの方法で回復リソースをコミットしています。回復リソースはどちらか（したがって、使用）に割り当てられたか、少なくとも論理的に（通常の作業トラフィックのためにとにかく優先使用可能余分なトラフィックが、使用できないが使用しているか否か）に予約されています。
- Shared P&R mechanisms are valuable to operators in order to maximize their network utilization.
- 共有P＆Rのメカニズムは、ネットワークの利用率を最大化するために、事業者に価値があります。
- Sending preemptable excess traffic on recovery resources is a valuable feature for operators.
- 回復資源にプリエンプタブル過剰なトラフィックを送信すると、事業者のための貴重な機能です。
To describe the P&R architecture, one must consider two dimensions of hierarchy [RFC3386]:
P＆Rアーキテクチャを記述するために、一方が階層[RFC3386]の二次元を考慮しなければなりません。
- A horizontal hierarchy consisting of multiple P&R domains, which is important in an LSP based protection scheme. The scope of P&R may extend over a link (or span), an administrative domain or sub-network, an entire LSP.
- LSPベースの保護方式において重要である複数のP＆Rドメインからなる水平階層、。 P＆Rの範囲は、リンク（またはスパン）、管理ドメインまたはサブネットワーク、全体LSPにわたって延びていてもよいです。
An administrative domain may consist of a single P&R domain or as a concatenation of several smaller P&R domains. The operator can configure P&R domains, based on customers' requirements, and on network topology and traffic engineering constraints.
管理ドメインは、単一のP＆Rドメインまたはいくつかの小さなP＆Rドメインの連結として構成することができます。オペレータは、顧客の要件に基づいて、P＆Rのドメインを設定し、ネットワークトポロジおよびトラフィックエンジニアリングの制約にすることができます。
- A vertical hierarchy consisting of multiple layers of P&R with varying granularities (packet flows, STS trails, lightpaths, fibers, etc).
- 変化する粒度を有するP＆Rの複数層からなる垂直階層（パケットフローは、トレイル、光パス、繊維などをSTS）。
In the absence of adequate P&R coordination, a fault may propagate from one level to the next within a P&R hierarchy. It can lead to "collisions" and simultaneous recovery actions may lead to race conditions, reduced resource utilization, or instabilities [MANCHESTER]. Thus, a consistent escalation strategy is needed to coordinate recovery across domains and layers. The fact that GMPLS can be used at different layers could simplify this coordination.
適切なP＆R連携の非存在下では、障害はP＆Rの階層内の次の1つのレベルから伝搬することができます。これは、競合状態、減少リソース使用率、または不安定性[MANCHESTER]につながる可能性があり、「衝突」と同時回復アクションにつながることができます。したがって、一貫性のエスカレーション戦略はドメイン及び層を横切って回復を調整するために必要とされます。 GMPLSは異なる層で使用することができるという事実は、この調整を簡素化することができます。
There are two types of escalation strategies: bottom-up and top-down. The bottom-up approach assumes that "lower-level" recovery schemes are more expedient. Therefore we can inhibit or hold off higher-level P&R. The Top-down approach attempts service P&R at the higher levels before invoking "lower level" P&R. Higher-layer P&R is service selective, and permits "per-CoS" or "per-LSP" re-routing.
ボトムアップとトップダウン：エスカレーション戦略の2つのタイプがあります。ボトムアップアプローチは、「低レベル」回復スキームは、より好都合であることを前提としています。したがって、我々は、より高いレベルのP＆Rを阻害するか、またはオフに保持することができます。トップダウンアプローチは、「低レベル」P＆Rを呼び出す前に、より高いレベルでサービスP＆Rを試みます。上位層P＆Rは、サービスの選択、および許可「ごとのCoS」または「ごとLSP」再ルーティングです。
Service Level Agreements (SLAs) between network operators and their clients are needed to determine the necessary time scales for P&R at each layer and at each domain.
ネットワークオペレータと顧客間のサービスレベル契約（SLA）は、それぞれの層で、各ドメインでP＆Rのために必要な時間スケールを決定するために必要とされています。
The choice of a P&R scheme is a tradeoff between network utilization (cost) and service interruption time. In light of this tradeoff, network service providers are expected to support a range of different service offerings or service levels.
P＆Rの方式の選択は、ネットワーク使用率（コスト）と、サービス中断時間の間のトレードオフです。このトレードオフの観点から、ネットワークサービスプロバイダは、異なるサービスの提供またはサービス・レベルの範囲をサポートすることが期待されます。
One can classify LSPs into one of a small set of service levels. Among other things, these service levels define the reliability characteristics of the LSP. The service level associated with a given LSP is mapped to one or more P&R schemes during LSP establishment. An advantage that mapping is that an LSP may use different P&E schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection). These details are likely to be service provider specific.
一つは、サービスレベルの小さなセットの一つにLSPを分類することができます。とりわけ、これらのサービスレベルは、LSPの信頼性特性を定義します。所与のLSPに関連するサービスレベルがLSPの確立中に1つのまたは複数のP＆R方式にマッピングされます。マッピングは、LSPがネットワークの異なるセグメントに異なるP＆Eスキームを使用できることであることの利点は、（例えば、いくつかのリンクは、LSPの他のセグメントは、リングプロテクションを利用することができる一方で、スパン保護することができます）。これらの詳細は、特定のサービス・プロバイダーである可能性が高いです。
An alternative to using service levels is for an application to specify the set of specific P&R mechanisms to be used when establishing the LSP. This allows greater flexibility in using different mechanisms to meet the application requirements.
サービス・レベルを使用する代わりに、LSPを確立する際に使用される特定のP＆Rメカニズムのセットを指定するアプリケーションのためのものです。これは、アプリケーションの要件を満たすために異なるメカニズムを使用してより柔軟にできます。
A differentiator between these service levels is service interruption time in case of network failures, which is defined as the length of time between when a failure occurs and when connectivity is re-established. The choice of service level (or P&R scheme) should be dictated by the service requirements of different applications.
これらのサービス・レベルの間の微分は、接続が再確立されたときに障害が発生したときの間の時間の長さとして定義されたネットワーク障害の場合にサービス中断時間です。サービスレベル（又はP＆R方式）の選択は、異なるアプリケーションのサービス要件によって決定されるべきです。
The following figure provides a classification of the possible provisioning types of recovery LSPs, and of the levels of overbooking that is possible for them.
次の図は、回復LSPの可能プロビジョニング種類の、それは彼らのために可能であるオーバーブッキングのレベルの分類を提供します。
+-Computed on +-Established +-Resources pre-| demand | on demand | allocated | | | Recovery LSP | | | Provisioning -+-Pre computed +-Pre established +-Resources allocated on demand
+ + + -Established -resources前に-Computed |需要|オンデマンド|割り当てられました| | |回復LSP | | |プロビジョニング - + - プレ+ -pre確立+ -resources計算需要に割り当てられました
+--- Dedicated (1:1, 1+1)
|
|
+--- Shared (1:N, Ring, Shared mesh)
|
Level of |
Overbooking ---+--- Best effort
Recovery from a network fault or impairment takes place in several stages as discussed in [RFC3469], including fault detection, fault localization, notification, recovery (i.e., the P&R itself) and reversion of traffic (i.e., returning the traffic to the original working LSP or to a new one).
[RFC3469]で説明したようにネットワーク障害や障害からの回復は、障害検出、障害ローカライズ、通知、回復（すなわち、P＆R自体）とトラフィックの復帰（含む、いくつかの段階で行わすなわち、本来の作業にトラフィックを返しますLSPまたは新しい1つ）。
- Fault detection is technology and implementation dependent. In general, failures are detected by lower layer mechanisms (e.g., SONET/SDH, Loss-of-Light (LOL)). When a node detects a failure, an alarm may be passed up to a GMPLS entity, which will take appropriate actions, or the alarm may be propagated at the lower layer (e.g., SONET/SDH AIS).
- 障害検出技術と実装依存です。一般的に、障害が下層メカニズムによって検出された（例えば、SONET / SDH、ロスオブライト（LOL））。ノードが障害を検出した場合、アラームが適切な行動を取るであろう、GMPLSエンティティに渡されてもよい、またはアラームは、下位層（例えば、SONET / SDH AIS）で増殖させることができます。
- Fault localization can be done with the help of GMPLS, e.g., using LMP for fault localization (see section 6.4).
- 障害の局在は（セクション6.4を参照してください）、障害ローカライズのためのLMPを使用して、例えば、GMPLSの助けを借りて行うことができます。
- Fault notification can also be achieved through GMPLS, e.g., using GMPLS RSVP-TE/CR-LDP notification (see section 7.12).
- 障害通知はまた、GMPLS RSVP-TE / CR-LDP通知（セクション7.12を参照）を使用して、例えばGMPLSを介して達成することができます。
- This section focuses on the different mechanisms available for recovery and reversion of traffic once fault detection, localization and notification have taken place.
- このセクションでは、一度故障検出、トラフィックの回復と復帰のために利用可能な異なるメカニズムに焦点を当て、ローカリゼーションと通知が行われています。
Network P&R techniques can be divided into Protection and Restoration. In protection, resources between the protection endpoints are established before failure, and connectivity after failure is achieved simply by switching performed at the protection end-points. In contrast, restoration uses signaling after failure to allocate resources along the recovery path.
ネットワークP＆Rの技術は、保護と回復に分けることができます。保護では、保護エンドポイント間のリソースは、障害が発生する前に確立されており、障害が発生した後の接続は、保護エンドポイントで実行切り替えることによって簡単に達成されます。これとは対照的に、復元が回復経路に沿って、リソースを割り当てるために失敗した後、シグナリングを使用しています。
- Protection aims at extremely fast reaction times and may rely on the use of overhead control fields for achieving end-point coordination. Protection for SONET/SDH networks is described in [ITUT-G.841] and [ANSI-T1.105]. Protection mechanisms can be further classified by the level of redundancy and sharing.
- 保護は極めて速い反応時間を目指し、エンドポイントの連携を実現するためのオーバーヘッド制御フィールドの使用に依拠することができます。 SONET / SDHネットワークの保護は[ITUT-G.841]と[ANSI-T1.105]に記載されています。保護メカニズムは、さらに、冗長性と共有のレベルによって分類することができます。
- Restoration mechanisms rely on signaling protocols to coordinate switching actions during recovery, and may involve simple re-provisioning, i.e., signaling only at the time of recovery; or pre-signaling, i.e., signaling prior to recovery.
- 修復メカニズムがリカバリ中にアクションを切り替える調整するシグナリングプロトコルに依存して、簡単な再プロビジョニングを含むことができる、すなわち、回復時にのみシグナル。またはプレシグナリング、即ち、回復の前にシグナリング。
In addition, P&R can be applied on a local or end-to-end basis. In the local approach, P&R is focused on the local proximity of the fault in order to reduce delay in restoring service. In the end-to-end approach, the LSP originating and terminating nodes control recovery.
また、P＆Rは、ローカルまたはエンドツーエンドベースで適用することができます。地元のアプローチでは、P＆Rは、サービスを復元するには遅延を低減するために、障害の局所的な近さに焦点を当てています。エンドツーエンドのアプローチでは、LSPは、ノード制御回復を発信し、終了します。
Using these strategies, the following recovery mechanisms can be defined.
これらの戦略を使用して、次の回復メカニズムを定義することができます。
Note that protection schemes are usually defined in technology specific ways, but this does not preclude other solutions.
保護スキームは、通常の技術、特定の方法で定義されていることに注意してください、これは他のソリューションを排除するものではありません。
- 1+1 Link Protection: Two pre-provisioned resources are used in parallel. For example, data is transmitted simultaneously on two parallel links and a selector is used at the receiving node to choose the best source (see also [GMPLS-FUNCT]).
- 1 + 1リンク保護：二つの事前プロビジョニングされたリソースを並列に使用されています。例えば、データは、2つの平行リンク上で同時に送信され、セレクタが最適なソースを選択するために、受信ノードで使用されている（参照[GMPLS-FUNCT]）。
- 1:N Link Protection: Working and protecting resources (N working, 1 backup) are pre-provisioned. If a working resource fails, the data is switched to the protecting resource, using a coordination mechanism (e.g., in overhead bytes). More generally, N working and M protecting resources can be assigned for M:N link protection (see also [GMPLS-FUNCT]).
- 1：Nリンク保護：作業および保護リソース（Nは1つのバックアップ、作業は）事前にプロビジョニングされています。作業リソースが失敗した場合は、データ（例えば、オーバーヘッド・バイトに）調整メカニズムを使用して、保護リソースに切り替えられます。より一般的には、Nが動作し、M保護リソースはMに割り当てることができる：Nリンク保護（参照[GMPLS-FUNCT]）。
- Enhanced Protection: Various mechanisms such as protection rings can be used to enhance the level of protection beyond single link failures to include the ability to switch around a node failure or multiple link failures within a span, based on a pre-established topology of protection resources (note: no reference available at publication time).
- 強化された保護：このような保護リングなどの様々な機構は、保護の事前に確立されたトポロジに基づいて、スパン内のノード障害または複数のリンク障害の周囲に切り替える機能を含むように単一のリンク障害を超え保護のレベルを高めるために使用することができますリソース（注：発行時に利用できませ参照）。
- 1+1 LSP Protection: Simultaneous data transmission on working and protecting LSPs and tail-end selection can be applied (see also [GMPLS-FUNCT]).
- 1 + 1 LSP保護：のLSPとテールエンドの選択作業と保護上の同時データ送信を適用することができる（[GMPLS-FUNCT]も参照）。
Thanks to the use of a distributed control plane like GMPLS, restoration is possible in multiple of tenths of milliseconds. It is much harder to achieve when only an NMS is used and can only be done in that case in a multiple of seconds.
GMPLSのような分散制御プレーンの使用のおかげで、復元はミリ秒の十の倍数で可能です。それだけでNMSが使用される場合に達成することは非常に困難ですし、わずか数秒の倍数で、その場合には行うことができます。
- End-to-end LSP restoration with re-provisioning: an end-to-end restoration path is established after failure. The restoration path may be dynamically calculated after failure, or pre-calculated before failure (often during LSP establishment). Importantly, no signaling is used along the restoration path before failure, and no restoration bandwidth is reserved. Consequently, there is no guarantee that a given restoration path is available when a failure occurs. Thus, one may have to crankback to search for an available path.
- 再プロビジョニングとエンドツーエンドLSP復元：エンドツーエンドの復旧パスは、障害が発生した後に確立されます。復旧パスを動的故障後に計算、または（多くの場合、LSPの確立時）障害が発生する前に事前に計算されてもよいです。重要なことには、何らのシグナリングは、故障前に復旧パスに沿って使用されず、いかなる復元帯域幅が予約されていません。その結果、障害が発生したときに与えられた復旧パスが利用可能である保証はありません。このように、1は、利用可能なパスを検索するためにクランクバックする必要があります。
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and no label pre-selection: an end-to-end restoration path is pre-calculated before failure and a signaling message is sent along this pre-selected path to reserve bandwidth, but labels are not selected (see also [GMPLS-FUNCT]).
エンドツーエンドの復旧パスが故障する前に事前に計算され、シグナリングメッセージはリザーブこの予め選択された経路に沿って送信される： - プレシグナリングの回復帯域幅予約なしラベル事前選択とエンドツーエンドLSP復元帯域幅が、ラベルが選択されていない（参照[GMPLS-FUNCT]）。
The resources reserved on each link of a restoration path may be shared across different working LSPs that are not expected to fail simultaneously. Local node policies can be applied to define the degree to which capacity is shared across independent failures. Upon failure detection, LSP signaling is initiated along the restoration path to select labels, and to initiate the appropriate cross-connections.
修復経路の各リンク上で予約されたリソースを同時に失敗することが予想されていない別の作業のLSP間で共有することができます。ローカルノードポリシーは、容量は、独立障害間で共有される程度を定義するために適用することができます。故障検出時に、LSPシグナリングは、ラベルを選択するために、適切な相互接続を開始するために復旧パスに沿って開始されます。
- End-to-end LSP restoration with pre-signaled recovery bandwidth reservation and label pre-selection: An end-to-end restoration path is pre-calculated before failure and a signaling procedure is initiated along this pre-selected path on which bandwidth is reserved and labels are selected (see also [GMPLS-FUNCT]).
- 事前に知らさ回復帯域予約およびラベルの事前選択をエンドツーエンドLSP修復：エンドツーエンドの復旧パスは、障害が発生する前に事前に計算され、シグナリング手順は、どの帯域幅にこの事前選択されたパスに沿って開始され、予約されており、ラベルが選択されている（参照[GMPLS-FUNCT]）。
The resources reserved on each link may be shared across different working LSPs that are not expected to fail simultaneously. In networks based on TDM, LSC and FSC technology, LSP signaling is used after failure detection to establish cross-connections at the intermediate switches on the restoration path using the pre-selected labels.
各リンク上で予約されたリソースが同時に故障することが期待されていない別の作業のLSP間で共有することができます。 TDM、LSCとFSC技術に基づくネットワークにおいて、LSPシグナリングは、予め選択されたラベルを使用して、復旧パス上の中間スイッチで相互接続を確立するために、故障検出後に使用されます。
- Local LSP restoration: the above approaches can be applied on a local basis rather than end-to-end, in order to reduce recovery time (note: no reference available at publication time).
- ローカルLSP復元：上記のアプローチは、回復時間減らすために、エンド・ツー・エンドではなくローカルに基づいて適用することができない（注：出版時点で利用可能な参照）。
This section discusses criteria that could be used by the operator in order to make a choice among the various P&R mechanisms.
このセクションでは、様々なP＆Rメカニズムのうちの選択を行うためにオペレータによって使用され得る基準を論じています。
- Robustness: In general, the less pre-planning of the restoration path, the more robust the restoration scheme is to a variety of failures, provided that adequate resources are available. Restoration schemes with pre-planned paths will not be able to recover from network failures that simultaneously affect both the working and restoration paths. Thus, these paths should ideally be chosen to be as disjoint as possible (i.e., SRLG and node disjoint), so that any single failure event will not affect both paths. The risk of simultaneous failure of the two paths can be reduced by recalculating the restoration path whenever a failure occurs along it.
- 堅牢性：一般的には、復旧パスの少ない事前計画は、よりロバストな復元方式は、十分なリソースが利用可能であることは、障害の種々です。事前に計画パスと復元方式は、同時に両方の作業や復旧パスに影響を与えるネットワーク障害から回復することはできません。従って、これらのパスは、理想的にはできるだけ互いに素になるように選択されるべきである（すなわち、SRLG、ノードディスジョイント）は、任意の単一の障害イベントは、両方のパスに影響を及ぼさないように。 2つのパスの同時故障のリスクは、障害がそれに沿って発生するたびに復旧パスを再計算することによって低減することができます。
The pre-selection of a label gives less flexibility for multiple failure scenarios than no label pre-selection. If failures occur that affect two LSPs that are sharing a label at a common node along their restoration routes, then only one of these LSPs can be recovered, unless the label assignment is changed.
ラベルの事前選択は、ラベルなし事前選択よりも、複数の障害シナリオのためのより少ない柔軟性を提供します。失敗はそれが彼らの修復経路に沿って共通ノードにラベルを共有している2つのLSPに影響が発生した場合、ラベルの割り当てが変更されない限り、1つだけ、これらのLSPのは、回収することができます。
The robustness of a restoration scheme is also determined by the amount of reserved restoration bandwidth - as the amount of restoration bandwidth sharing increases (reserved bandwidth decreases), the restoration scheme becomes less robust to failures. Restoration schemes with pre-signaled bandwidth reservation (with or without label pre-selection) can reserve adequate bandwidth to ensure recovery from any specific set of failure events, such as any single SRLG failure, any two SRLG failures etc. Clearly, more restoration capacity is allocated if a greater degree of failure recovery is required. Thus, the degree to which the network is protected is determined by the policy that defines the amount of reserved restoration bandwidth.
回復スキームのロバスト性も予約修復帯域幅の量によって決定される - 修復帯域幅共有増加（予約帯域幅の減少）量として、復元方式は障害に対してよりロバストになります。 （付きまたはラベル事前選択なし）プレシグナリング帯域予約と復元方式は等、任意の単一のSRLG障害、任意の二つのSRLG障害明らかに、より多くの回復容量と失敗イベントの特定のセットからの回復を確実にするために十分な帯域幅を確保することができ障害回復の大きい程度が必要とされる場合に割り当てられます。したがって、ネットワークが保護される程度は、予約修復帯域幅の量を定義するポリシーによって決定されます。
- Recovery time: In general, the more pre-planning of the restoration route, the more rapid the P&R scheme. Protection schemes generally recover faster than restoration schemes. Restoration with pre-signaled bandwidth reservation are likely to be (significantly) faster than path restoration with re-provisioning, especially because of the elimination of any crankback. Local restoration will generally be faster than end-to-end schemes.
- 復旧時間：復旧ルートの一般的には、より多くの事前計画、より迅速なP＆Rスキーム。保護スキームは、一般的に回復スキームよりも早く回復します。事前通知帯域幅予約と復元は、（大幅に）再プロビジョニングとパスリストアよりも速く、特に理由は任意のクランクバックの排除の可能性が高いです。ローカル修復は、一般的に、エンド・ツー・エンドの方式よりも高速になります。
Recovery time objectives for SONET/SDH protection switching (not including time to detect failure) are specified in [ITUT-G.841] at 50 ms, taking into account constraints on distance, number of connections involved, and in the case of ring enhanced protection, number of nodes in the ring.
（障害を検出するための時間は含まない）SONET / SDH保護スイッチングの回復時間の目標は、50ミリ秒で[ITUT-G.841]で指定された距離に口座の制約を考慮して、関係する接続の数、およびリングの場合に増強されます保護、リング内のノード数。
Recovery time objectives for restoration mechanisms are being defined through a separate effort [RFC3386].
復元メカニズムの回復時間の目標は、別の努力[RFC3386]で定義されています。
- Resource Sharing: 1+1 and 1:N link and LSP protection require dedicated recovery paths with limited ability to share resources: 1+1 allows no sharing, 1:N allows some sharing of protection resources and support of extra (pre-emptable) traffic. Flexibility is limited because of topology restrictions, e.g., fixed ring topology for traditional enhanced protection schemes.
- リソースの共有：+ 1 1と1：NリンクとLSP保護は、リソースを共有するための限られた能力を持つ専用の復旧パスが必要です：+ 1は、何の共有を可能にしない1：N前emptable（保護リソースと追加のサポートのいくつかを共有することができます） トラフィック。柔軟性があるため、トポロジ上の制約、伝統的な強化保護方式のため、例えば、固定されたリングトポロジのために制限されます。
The degree to which restoration schemes allow sharing amongst multiple independent failures is directly dictated by the size of the restoration pool. In restoration schemes with re-provisioning, a pool of restoration capacity can be defined from which all restoration routes are selected after failure. Thus, the degree of sharing is defined by the amount of available restoration capacity. In restoration with pre-signaled bandwidth reservation, the amount of reserved restoration capacity is determined by the local bandwidth reservation policies. In all restoration schemes, pre-emptable resources can use spare restoration capacity when that capacity is not being used for failure recovery.
復元方式は、複数の独立した障害の間で共有できるようにする程度を直接復元プールのサイズによって決定されます。再プロビジョニングと復元方式において、回復能力のプールは、すべての復旧ルートが失敗した後に選択され、そこから定義することができます。従って、共有の程度は、利用可能な回復能力の量によって定義されます。プレシグナリング帯域予約と復元において、予約回復能力の量は、ローカル帯域幅予約ポリシーによって決定されます。すべての復元方式では、事前emptableリソースは、その容量は、障害復旧のために使用されていない予備の回復能力を使用することができます。
Service Providers (SPs) use network management extensively to configure, monitor or provision various devices in their network. It is important to note that a SP's equipment may be distributed across geographically separate sites thus making distributed management even more important. The service provider should utilize an NMS system and standard management protocols such as SNMP (see [RFC3410], [RFC3411] and [RFC3416]) and the relevant MIB modules as standard interfaces to configure, monitor and provision devices at various locations. The service provider may also wish to use the command line interface (CLI) provided by vendors with their devices. However, this is not a standard or recommended solution because there is no standard CLI language or interface, which results in N different CLIs in a network with devices from N different vendors. In the context of GMPLS, it is extremely important for standard interfaces to the SP's devices (e.g., SNMP) to exist due to the nature of the technology itself. Since GMPLS comprises many different layers of control-plane and data-plane technology, it is important for management interfaces in this area to be flexible enough to allow the manager to manage GMPLS easily, and in a standard way.
サービスプロバイダ（SPは）、設定、ネットワーク内のさまざまなデバイスを監視したり、提供するために広くネットワーク管理を使用しています。 SPの機器は、このように分散管理が一層重要になって地理的に別々のサイトに分散することができることに注意することが重要です。サービスプロバイダは、様々な位置で、設定、監視、および提供装置に標準インタフェースとして、関連するMIBモジュール（[RFC3410]、[RFC3411]及び[RFC3416]を参照）NMSシステムおよびSNMPなどの標準的な管理プロトコルを利用すべきです。サービスプロバイダは、自社のデバイスとのベンダーが提供するコマンドラインインタフェース（CLI）を使用することもできます。 N異なるベンダの機器とネットワークでN異なるのCLIになり標準的なCLI言語やインタフェースは、存在しないためしかし、これは標準または推奨されるソリューションではありません。 SPのデバイス（例えば、SNMP）への標準インターフェースが原因技術自体の性質に存在するGMPLSの文脈では、それは非常に重要です。 GMPLSは、コントロールプレーンとデータプレーン技術の多くの異なる層を含むので、十分に柔軟であることが管理者が簡単にGMPLSを管理できるようにするために、そして標準的な方法で、この領域で管理インターフェイスのために重要です。
The NMS system should maintain the collective information about each device within the system. Note that the NMS system may actually be comprised of several distributed applications (i.e., alarm aggregators, configuration consoles, polling applications, etc.) that collectively comprises the SP's NMS. In this way, it can make provisioning and maintenance decisions with the full knowledge of the entire SP's network. Configuration or provisioning information (i.e., requests for new services) could be entered into the NMS and subsequently distributed via SNMP to the remote devices. Thus, making the SP's task of managing the network much more compact and effortless rather than having to manage each device individually (i.e., via CLI).
NMSシステムは、システム内の各デバイスに関する集合情報を維持しなければなりません。 NMSシステムが実際にまとめSPのNMSを含むいくつかの分散アプリケーション（即ち、アラームアグリゲータ、構成コンソール、ポーリングアプリケーション、等）から構成されてもよいことに留意されたいです。このように、それは全体のSPのネットワークの完全な知識とプロビジョニングとメンテナンス意思決定を行うことができます。設定またはプロビジョニング情報（すなわち、新たなサービスの要求は）NMSを締結し、その後、リモートデバイスにSNMPを介して配布することができます。したがって、よりコンパクトかつ楽ではなく（すなわち、CLIを介して）個々のデバイスを管理するよりも、ネットワークを管理するSPの作業を行います。
Security and access control can be achieved using the SNMPv3 User-based Security Model (USM) [RFC3414] and the View-based Access Control Model (VACM) [RFC3415]. This approach can be very effectively used within a SP's network, since the SP has access to and control over all devices within its domain. Standardized MIBs will need to be developed before this approach can be used ubiquitously to provision, configure and monitor devices in non-heterogeneous networks or across SP's network boundaries.
セキュリティとアクセス制御は、SNMPv3ユーザーベースセキュリティモデル（USM）[RFC3414]とビューベースアクセス制御モデル（VACM）[RFC3415]を使用して達成することができます。 SPがアクセスし、そのドメイン内のすべてのデバイスを制御しているため、このアプローチは非常に効果的に、SPのネットワーク内で使用することができます。このアプローチは規定に普遍的に使用することができます前に、標準化されたMIBは非異種ネットワークやSPのネットワーク境界を越えてデバイスを設定し、監視し、開発する必要があります。
In the context of GMPLS, it is extremely important for standard interfaces to devices to exist due to the nature of the technology itself. Since GMPLS comprises many different layers of control-plane technology, it is important for SNMP MIB modules in this area to be flexible enough to allow the manager to manage the entire control plane. This should be done using MIB modules that may cooperate (i.e., coordinated row-creation on the agent) or through more generalized MIB modules that aggregate some of the desired actions to be taken and push those details down to the devices. It is important to note that in certain circumstances, it may be necessary to duplicate some small subset of manageable objects in new MIB modules for management convenience. Control of some parts of GMPLS may also be achieved using existing MIB interfaces (i.e., existing SONET MIB) or using separate ones, which are yet to be defined. MIB modules may have been previously defined in the IETF or ITU. Current MIB modules may need to be extended to facilitate some of the new functionality desired by GMPLS. In these cases, the working group should work on new versions of these MIB modules so that these extensions can be added.
GMPLSの文脈では、原因技術そのものの性質のために存在するとデバイスへの標準インタフェースのために非常に重要です。 GMPLS制御プレーン技術の多くの異なる層を含むので、この領域におけるSNMP MIBモジュールは、マネージャーは全体制御プレーンを管理することを可能にするのに十分に柔軟であるために重要です。これを採取し、デバイスまでのこれらの詳細をプッシュする所望のアクションの一部を集約（すなわち、協調エージェント上の行の作成）またはより一般MIBモジュールを介して協働することができるMIBモジュールを使用して行われるべきです。特定の状況では、管理の利便性のための新しいMIBモジュールで管理オブジェクトのいくつかの小さなサブセットを複製する必要があるかもしれないことに注意することが重要です。 GMPLSの一部のコントロールは、既存のMIBインターフェースを使用して（すなわち、既存のSONET MIB）または定義するまだある別のものを用いて達成することができます。 MIBモジュールは、以前にIETFやITUで定義されている可能性があります。現在のMIBモジュールは、GMPLSが希望する新機能のいくつかを容易にするために拡張する必要があるかもしれません。これらのケースでは、ワーキンググループは、これらの拡張機能を追加することができるように、これらのMIBモジュールの新しいバージョンで動作するはずです。
As in traditional networks, standard tools such as traceroute [RFC1393] and ping [RFC2151] are needed for debugging and performance monitoring of GMPLS networks, and mainly for the control plane topology, that will mimic the data plane topology. Furthermore, such tools provide network reachability information. The GMPLS control protocols will need to expose certain pieces of information in order for these tools to function properly and to provide information germane to GMPLS. These tools should be made available via the CLI. These tools should also be made available for remote invocation via the SNMP interface [RFC2925].
従来のネットワークと同様に、そのようなトレースルート[RFC1393]およびping [RFC2151]などの標準的なツールは、GMPLSネットワークのデバッグおよびパフォーマンス監視のために必要とされ、主としてデータ・プレーン・トポロジーを模倣する制御プレーン・トポロジーのため。さらに、そのようなツールは、ネットワーク到達可能性情報を提供します。 GMPLS制御プロトコルは、これらのツールは正常に機能するとGMPLSに密接な情報を提供するために特定の情報を公開する必要があります。これらのツールは、CLI経由で利用できるようにすべきです。これらのツールはまた、SNMPインタフェース[RFC2925]を経由してリモート呼び出しのために利用できるようにすべきです。
Due to the nature of GMPLS, and that potential layers may be involved in the control and transmission of GMPLS data and control information, it is required that a fault in one layer be passed to the adjacent higher and lower layers to notify them of the fault. However, due to nature of these many layers, it is possible and even probable, that hundreds or even thousands of notifications may need to transpire between layers. This is undesirable for several reasons. First, these notifications will overwhelm the device. Second, if the device(s) are programmed to emit SNMP Notifications [RFC3417] then the large number of notifications the device may attempt to emit may overwhelm the network with a storm of notifications. Furthermore, even if the device emits the notifications, the NMS that must process these notifications either will be overwhelmed or will be processing redundant information. That is, if 1000 interfaces at layer B are stacked above a single interface below it at layer A, and the interface at A goes down, the interfaces at layer B should not emit notifications. Instead, the interface at layer A should emit a single notification. The NMS receiving this notification should be able to correlate the fact that this interface has many others stacked above it and take appropriate action, if necessary.
GMPLSの性質、および潜在的な層は、GMPLSデータの制御及び伝達に関与し、情報を制御することができること、障害を通知するために、1つの層中に故障が隣接するより高いおよびより低いレイヤに渡されることが必要です。しかし、これらの多くの層の性質のために、それは、通知の数百または数千もの層の間に蒸散する必要があるかもしれないことを、可能性も考えられます。これは、いくつかの理由で望ましくありません。まず、これらの通知は、デバイスを圧倒します。デバイス（複数可）は[RFC3417]をSNMP通知を発するようにプログラムされている場合には、第2、次にデバイスが放出するように試みることができる通知の多数は、通知の嵐とネットワークを圧倒することができます。さらに、デバイスが通知を発した場合でも、いずれかのこれらの通知を処理しなければならないNMSを圧倒するか、冗長な情報を処理します。層Bで1000のインタフェースはA層でその下単一のインタフェース上に積層されている場合には、であり、そしてAのインタフェースがダウンし、層Bのインターフェイスは、通知を発するべきではありません。代わりに、層Aのインタフェースは、単一の通知を発しなければなりません。この通知を受けたNMSは、このインタフェースは、多くの人がその上に積み重ねられた事実を相関し、必要に応じて、適切な行動を取ることができるはずです。
Devices that support GMPLS should provide mechanisms for aggregating, summarizing, enabling and disabling of inter-layer notifications for the reasons described above. In the context of SNMP MIB modules, all MIB modules that are used by GMPLS must provide enable/disable objects for all notification objects. Furthermore, these MIBs must also provide notification summarization objects or functionality (as described above) as well. NMS systems and standard tools which process notifications or keep track of the many layers on any given devices must be capable of processing the vast amount of information which may potentially be emitted by network devices running GMPLS at any point in time.
GMPLSをサポートするデバイスは、凝集要約、可能と上記理由により層間通知の無効化するためのメカニズムを提供しなければなりません。 SNMP MIBモジュールのコンテキストでは、GMPLSで使用されているすべてのMIBモジュールは、すべての通知オブジェクトの有効/無効のオブジェクトを提供しなければなりません。さらに、これらのMIBはまた、同様に（上記のように）通知集計オブジェクトまたは機能を提供しなければなりません。 NMSシステム及び潜在的に任意の時点でGMPLSを実行しているネットワークデバイスによって放出される大量の情報を処理することができなければならないプロセスの通知または任意のデバイス上に多数の層を追跡する標準的なツール。
GMPLS defines a control plane architecture for multiple technologies and types of network elements. In general, since LSPs established using GMPLS may carry high volumes of data and consume significant network resources, security mechanisms are required to safeguard the underlying network against attacks on the control plane and/or unauthorized usage of data transport resources. The GMPLS control plane should therefore include mechanisms that prevent or minimize the risk of attackers being able to inject and/or snoop on control traffic. These risks depend on the level of trust between nodes that exchange GMPLS control messages, as well as the realization and physical characteristics of the control channel. For example, an in-band, in-fiber control channel over SONET/SDH overhead bytes is, in general, considered less vulnerable than a control channel realized over an out-of-band IP network.
GMPLSは、複数の技術及びネットワーク要素のタイプの制御プレーン・アーキテクチャを定義します。 LSPは、大量のデータを携帯し、大量のネットワークリソースを消費するGMPLSを使用して確立するので、一般的に、セキュリティメカニズムは、制御プレーンおよび/またはデータ転送リソースの不正使用に対する攻撃に対する基本的なネットワークを保護するために必要とされます。 GMPLS制御プレーンは、従って、予防または制御トラフィック及び/又はスヌープを注入することができるという攻撃のリスクを最小化メカニズムを含むべきです。これらのリスクは、GMPLS制御メッセージを交換ノード、ならびに実現および制御チャネルの物理的特性との間の信頼のレベルに依存します。例えば、SONET / SDHオーバーヘッドオーバー帯域内でファイバの制御チャネルは、一般的に、制御チャネルは、帯域外IPネットワークを介して実現さよりも脆弱であると考えられるバイト。
Security mechanisms can provide authentication and confidentiality. Authentication can provide origin verification, message integrity and replay protection, while confidentiality ensures that a third party cannot decipher the contents of a message. In situations where GMPLS deployment requires primarily authentication, the respective authentication mechanisms of the GMPLS component protocols may be used (see [RFC2747], [RFC3036], [RFC2385] and [LMP]). Additionally, the IPsec suite of protocols (see [RFC2402], [RFC2406] and [RFC2409]) may be used to provide authentication, confidentiality or both, for a GMPLS control channel. IPsec thus offers the benefits of combined protection for all GMPLS component protocols as well as key management.
セキュリティ・メカニズムは、認証と機密性を提供することができます。守秘義務は、第三者がメッセージの内容を解読することができないことを保証しながら、認証は、原点検証、メッセージの整合性とリプレイ保護を提供することができます。 GMPLSの展開は、主に認証を必要とする状況では、GMPLS成分プロトコルのそれぞれの認証メカニズムは、（[RFC2747]、[RFC3036]、[RFC2385]と[LMP]を参照）を使用することができます。また、プロトコルのIPsecのスイートはGMPLS制御チャネルのために、認証、機密性、または両方を提供するために使用することができる（[RFC2406]及び[RFC2409]は、[RFC2402]を参照します）。 IPsecは、したがって、すべてのGMPLSコンポーネントプロトコルの組み合わせの保護だけでなく、鍵管理のメリットを提供しています。
A related issue is that of the authorization of requests for resources by GMPLS-capable nodes. Authorization determines whether a given party, presumable already authenticated, has a right to access the requested resources. This determination is typically a matter of local policy control [RFC2753], for example by setting limits on the total bandwidth available to some party in the presence of resource contention. Such policies may become quite complex as the number of users, types of resources and sophistication of authorization rules increases.
関連する問題は、GMPLS対応のノードによるリソースに対する要求の許可のことです。承認は与えられたパーティー、推測既に認証は、要求されたリソースにアクセスする権利を有しているか否かを判定する。この決意は、リソースの競合の存在下で、いくつかのパーティに利用可能な総帯域幅に制限を設定することによって、例えば、典型的には、ローカルポリシー制御[RFC2753]の問題です。このような政策は、ユーザー数、リソースの種類と許可規則が増加の高度化など、非常に複雑になることがあります。
After authenticating requests, control elements should match them against the local authorization policy. These control elements must be capable of making decisions based on the identity of the requester, as verified cryptographically and/or topologically. For example, decisions may depend on whether the interface through which the request is made is an inter- or intra-domain one. The use of appropriate local authorization policies may help in limiting the impact of security breaches in remote parts of a network.
リクエストを認証した後、制御要素は、ローカル承認ポリシーに対してそれらを一致させる必要があります。暗号的および/または位相幾何学的に確認されるようにこれらの制御要素は、要求者のアイデンティティに基づいて意思決定を行うことが可能でなければなりません。例えば、決定は、要求が行われ、それを通してインタフェースが間またはドメイン内であるか否かに依存し得ます。適切なローカル許可ポリシーを使用すると、ネットワークのリモート部分でセキュリティ侵害の影響を制限することに役立つかもしれません。
Finally, it should be noted that GMPLS itself introduces no new security considerations to the current MPLS-TE signaling (RSVP-TE, CR-LDP), routing protocols (OSPF-TE, IS-IS-TE) or network management protocols (SNMP).
最後に、GMPLS自体が（現在のMPLS-TEシグナリング（RSVP-TE、CR-LDP）、ルーティングプロトコル（OSPF-TE、IS-IS-TE）またはネットワーク管理プロトコルSNMPを新たなセキュリティ問題を導入しないことに留意すべきです）。
This document is the work of numerous authors and consists of a composition of a number of previous documents in this area.
この文書は、多くの作家の作品であり、この分野における以前の文書数の組成物で構成されています。
Many thanks to Ben Mack-Crane (Tellabs) for all the useful SONET/SDH discussions we had together. Thanks also to Pedro Falcao, Alexandre Geyssens, Michael Moelants, Xavier Neerdaels, and Philippe Noel from Ebone for their SONET/SDH and optical technical advice and support. Finally, many thanks also to Krishna Mitra (Consultant), Curtis Villamizar (Avici), Ron Bonica (WorldCom), and Bert Wijnen (Lucent) for their revision effort on Section 12.
私たちは一緒に持っていたすべての有用なSONET / SDHの議論のためのベン・マック・クレーン（テラブス）に感謝します。また、彼らのSONET / SDH、光技術的なアドバイスやサポートのためのEboneからペドロ・ファルカン、アレクサンドルGeyssens、マイケルMoelants、ザビエルNeerdaels、そしてフィリップ・ノエルに感謝します。最後に、第12節にその改訂の努力にもクリシュナミトラ（コンサルタント）、カーティスVillamizar（Avici）、ロン・Bonica（ワールドコム）、およびバートWijnen（ルーセント）に感謝します。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、RFC 3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "RSVP-TE：LSPトンネルのためのRSVPの拡張"、RFC 3209年12月2001。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、アンダーソン、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、Worster、T.、フェルドマン、N.、Fredette、A.、Girish、 M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA. Malis、 "LDPを使用して、制約ベースLSPセットアップ"、RFC 3212、2002年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471]バーガー、L.、 "一般化されたマルチプロトコルラベルスイッチング（GMPLS）機能説明シグナリング"、RFC 3471、2003年1月。
[RFC3472] Ashwood-Smith, P. and L. Berger, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, January 2003.
[RFC3472]アッシュウッド・スミス、P。およびL.バーガー、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング制約ベースルーティングのラベル配布プロトコル（CR-LDP）の拡張"、RFC 3472、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473]バーガー、L.、 "一般化マルチプロトコルラベルスイッチング（GMPLS）シグナリング資源予約プロトコル - トラフィックエンジニアリング（RSVP-TE）を拡張"、RFC 3473、2003年1月。
[ANSI-T1.105] "Synchronous Optical Network (SONET): Basic Description Including Multiplex Structure, Rates, And Formats," ANSI T1.105, 2000.
[ANSI-T1.105] "同期光ネットワーク（SONET）：多重構造、料金、およびフォーマットなど、基本的な説明、" ANSI T1.105、2000。
[BUNDLE] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering", Work in Progress.
[BUNDLE] Kompella、K.、Rekhter、Y.、およびL.バーガー、 "MPLSトラフィックエンジニアリングでのリンクバンドル" が進行中で働いています。
[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[GMPLS-FUNCT]ラング、J.P.、エド。そしてB. Rajagopalan、エド。、「一般化MPLS回復機能の仕様」が進行中で働いています。
[GMPLS-G709] Papadimitriou, D., Ed., "GMPLS Signaling Extensions for G.709 Optical Transport Networks Control", Work in Progress.
[GMPLS-G709] Papadimitriou、D.編、 "G.709光トランスポートネットワーク制御のためのGMPLSシグナリング拡張" が進行中で働いています。
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, "GMPLS UNI: RSVP Support for the Overlay Model", Work in Progress.
[GMPLS-OVERLAY]ツバメ、G.、ドレイク、J.、石松、H.、およびY. Rekhter、 "GMPLS UNI：オーバレイモデルのRSVP支援"、ProgressのWork。
[GMPLS-ROUTING] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress.
[GMPLS-ROUTING] Kompella、K.、エド。そして、Y. Rekhter、エド。、「一般化されたマルチプロトコルラベルスイッチングのサポートでルーティング拡張機能」が進行中で働いています。
[RFC3946] Mannie, E., Ed. and Papadimitriou D., Ed., "Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC3946]マニー、E.、エド。そして、Papadimitriou D.編、 "一般化マルチプロトコルラベルスイッチング（GMPLS）同期光ネットワーク（SONET）および同期デジタル階層（SDH）コントロールのための拡張機能"、RFC 3946、2004年10月。
[HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[HIERARCHY] Kompella、K.、およびY. Rekhter、 "一般化されたMPLS TE LSPと階層"、ProgressのWork。
[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月。
[ISIS-TE-GMPLS] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching", Work in Progress.
[ISIS-TE-GMPLS] Kompella、K.、エド。そして、Y. Rekhterは、エド。、「IS-IS一般マルチプロトコルラベルスイッチングのサポートで機能拡張」が進行中で働いていますが。
[ITUT-G.707] ITU-T, "Network Node Interface for the Synchronous Digital Hierarchy", Recommendation G.707, October 2000.
[ITUT-G.707] ITU-T、 "同期デジタル階層のためのネットワークノードインタフェース"、勧告G.707、2000年10月。
[ITUT-G.709] ITU-T, "Interface for the Optical Transport Network (OTN)," Recommendation G.709 version 1.0 (and Amendment 1), February 2001 (and October 2001).
[ITUT-G.709] ITU-T、 "オプティカルトランスポートネットワーク（OTN）のためのインタフェース、" 勧告G.709バージョン1.0（および修正1）、2001年2月（2001年10月）。
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH Network Protection Architectures," Recommendation G.841, October 1998.
[ITUT-G.841] ITU-T、 "タイプとSDHネットワーク保護アーキテクチャの特性、" 勧告G.841、1998年10月。
[LMP] Lang, J., Ed., "Link Management Protocol (LMP)", Work in Progress.
[LMP]ラング、J.、エド。、 "リンク管理プロトコル（LMP）" が進行中で働いています。
[LMP-WDM] Fredette, A., Ed. and J. Lang Ed., "Link Management Protocol (LMP) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems", Work in Progress.
[LMP-WDM] Fredette、A.編。 、進行中の作業とJ.ラング編、「高密度波長分割多重（DWDM）光回線システムのリンク管理プロトコル（LMP）」。
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications Magazine, August 1999.
[マンチェスター] J.マンチェスター、P. Bonenfant及びC.ニュートン、「トランスポートネットワーク生存性の進化、」IEEEコミュニケーションズマガジン、1999年8月。
[OIF-UNI] The Optical Internetworking Forum, "User Network Interface (UNI) 1.0 Signaling Specification - Implementation Agreement OIF-UNI-01.0," October 2001.
[OIF-UNI]オプティカル・インターネットフォーラム、 "ユーザネットワークインターフェイス（UNI）1.0シグナリング仕様 - 実装規約OIF-UNI-01.0、" 2001年10月。
[OLI-REQ] Fredette, A., Ed., "Optical Link Interface Requirements," Work in Progress.
進行中[OLI-REQ] Fredette、A.編、 "光リンクインタフェース要件、" ワーク。
[OSPF-TE-GMPLS] Kompella, K., Ed. and Y.
Rekhter, Ed., "OSPF Extensions in Support of
Generalized Multi-Protocol Label Switching",
Work in Progress.
[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月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393]マルキン、G.、 "tracerouteのIPオプションの使用"、RFC 1393、1993年1月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/IP Tools and Utilities", RFC 2151, June 1997.
[RFC2151]ケスラー、G.とS.シェパード、 "インターネットとTCP / IPツールおよびユーティリティの手引き"、RFC 2151、1997年6月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1の機能的な仕様"、RFC 2205、1997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernanの、A.、 "TCP MD5署名オプションを使用してBGPセッションの保護"、RFC 2385、1998年8月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]ケント、S.とR.アトキンソン、 "IP認証ヘッダー"、RFC 2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（IKE）"、RFC 2409、1998年11月。
[RFC2702] Awduche, D., Malcolm, J.,
Agogbua, J., O'Dell, M., and J. McManus,
"Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747]ベーカー、F.、リンデル、B.、およびM. Talwar、 "RSVP暗号化認証"、RFC 2747、2000年1月。
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.
[RFC2753] Yavatkar、R.、Pendarakis、D.、およびR.ゲラン、 "ポリシーベースのアドミッション制御のためのフレームワーク"、RFC 2753、2000年1月。
[RFC2925] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000.
[RFC2925]ホワイト、K.、 "リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトの定義"、RFC 2925、2000年9月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036]アンデション、L.、Doolan、P.、フェルドマン、N.、Fredette、A.、およびB.トーマス、 "LDP仕様"、RFC 3036、2001年1月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386]ライ、W.およびD. McDysan、 "ネットワーク階層と多層耐障害"、RFC 3386、2002年11月。
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410]ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、 "インターネット標準の管理フレームワークのための序論と適用性声明"、RFC 3410、2002年12月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]ハリントン、D.、Presuhn、R.、およびB. Wijnenの、 "簡易ネットワーク管理プロトコル（SNMP）管理フレームワークを記述するためのアーキテクチャ"、STD 62、RFC 3411、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
、STD 62、RFC 3414、2002年12月 "簡易ネットワーク管理プロトコル（SNMPv3の）のバージョン3のためのユーザベースセキュリティモデル（USM）" [RFC3414]ブルーメンソール、U.とB. Wijnenの、。
[RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnenの、B.、Presuhn、R.、およびK. McCloghrie、 "簡易ネットワーク管理プロトコルのためのビューベースアクセス制御モデル（VACM）（SNMP）"、STD 62、RFC 3415、2002年12月。
[RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
[RFC3416] Presuhn、R.、STD 62、RFC 3416、2002年12月 "簡易ネットワーク管理プロトコル（SNMP）のためのプロトコル操作のバージョン2"。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、 "簡易ネットワーク管理プロトコルのためのマッピングを輸送します（SNMP）"、STD 62、RFC 3417、2002年12月。
[RFC3469] Sharma, V. and F. Hellstrand, "Framework for Multi-Protocol Label Switching (MPLS)-based Recovery", RFC 3469, February 2003.
[RFC3469]シャルマ、V.とF. Hellstrand、 "マルチプロトコルラベルのためのフレームワーク・スイッチング（MPLS）の回復をベース"、RFC 3469、2003年2月。
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC3477] Kompella、K.とY. Rekhter、 "資源予約プロトコルでアンナンバードリンクシグナリング - トラフィックエンジニアリング（RSVP-TE）"、RFC 3477、2003年1月。
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003.
[RFC3479]、RFC 3479、2003年2月ファレル、A.、 "ラベル配布プロトコル（LDP）のためのフォールトトレランス"。
[RFC3480] Kompella, K., Rekhter, Y., and A. Kullberg, "Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)", RFC 3480, February 2003.
[RFC3480] Kompella、K.、Rekhter、Y.、およびA. Kullberg、 "CR-LDP（制約ルーティングラベル配布プロトコル）シグナリングアンナンバードリンク"、RFC 3480、2003年2月。
[SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma, "Framework for GMPLS-based Control of SDH/SONET Networks", Work in Progress.
[SONET、SDH-GMPLS-FRM]バーンスタイン、G.、マニー、E.、およびV.シャルマ、 "SDH / SONETネットワークのGMPLSベース制御のためのフレームワーク"、ProgressのWork。
Peter Ashwood-Smith Nortel P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
ピーター・アッシュウッド・スミスノーテルの私書箱K1Y 4H7、カナダのボックス3511駅のC、オタワ、
EMail: petera@nortelnetworks.com
メールアドレス：petera@nortelnetworks.com
Eric Mannie Consult Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
エリック・マニー相談ください電話：+32 2 648-5023モバイル：+32（0）495から221775
EMail: eric_mannie@hotmail.com
メールアドレス：eric_mannie@hotmail.com
Daniel O. Awduche Consult
ダニエルO. Awducheご相談ください
EMail: awduche@awduche.com
メールアドレス：awduche@awduche.com
Thomas D. Nadeau Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
トーマスD.ナドーのCisco 250アポロドライブチェルムズフォード、MA 01824、USA
EMail: tnadeau@cisco.com
メールアドレス：tnadeau@cisco.com
Ayan Banerjee Calient 5853 Rue Ferrari San Jose, CA 95138, USA
アヤンバネルジーCalient 5853ルーフェラーリカリフォルニア州サンノゼ95138、USA
EMail: abanerjee@calient.net
メールアドレス：abanerjee@calient.net
Lyndon Ong Ciena 10480 Ridgeview Ct Cupertino, CA 95014, USA
リンドン・オングシエナ10480 RidgeviewのCtクパチーノ、CA 95014、USA
EMail: lyong@ciena.com
メールアドレス：lyong@ciena.com
Debashis Basak Accelight 70 Abele Road, Bldg.1200 Bridgeville, PA 15017, USA
Debashishバスクは、私たちをbaladaga 0.1 0 brijabhilleトウ、足15017 70 abele道を、esisielaita
EMail: dbasak@accelight.com
メールアドレス：dbasak@accelight.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリスPapadimitriouアルカテルフランシスVellesplein、1 B-2018アントワープ、Velgiom
EMail: dimitri.papadimitriou@alcatel.be
メールアドレス：dimitri.papadimitriou@alcatel.be
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA, 22102, USA
ルー・バーガーMovaz 7926ジョーンズ支店ドライブマクリーンVA、22102、USA
EMail: lberger@movaz.com
メールアドレス：lberger@movaz.com
Dimitrios Pendarakis Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
ディミトリオスPendarakis Tellium 2クレセントプレイス、P。ボックス901 Oceanport、NJ 07757から0901、USA
EMail: dpendarakis@tellium.com
メールアドレス：dpendarakis@tellium.com
Greg Bernstein Grotto
グレッグ・バーンスタインの洞窟
EMail: gregb@grotto-networking.com
メールアドレス：gregb@grotto-networking.com
Bala Rajagopalan Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
バラRajagopalan Tellium 2クレセントプレイス、P。ボックス901 Oceanport、NJ 07757から0901、USA
EMail: braja@tellium.com
メールアドレス：braja@tellium.com
Sudheer Dharanikota Consult
Sudhir dharanikota konsulata
EMail: sudheer@ieee.org
メールアドレス：sudheer@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
ヤコフ・レックタージュニパー1194 N.マチルダアベニュー。サニーベール、CA 94089、USA
EMail: yakov@juniper.net
メールアドレス：yakov@juniper.net
John Drake Calient 5853 Rue Ferrari San Jose, CA 95138, USA
ジョン・ドレイクCalient 5853ルーフェラーリカリフォルニア州サンノゼ95138、USA
EMail: jdrake@calient.net
メールアドレス：jdrake@calient.net
Debanjan Saha Tellium 2 Crescent Place Oceanport, NJ 07757-0901, USA
DebanjanサハTellium 2クレセント置きOceanport、NJ 07757から0901、USA
EMail: dsaha@tellium.com
メールアドレス：dsaha@tellium.com
Yanhe Fan Axiowave 200 Nickerson Road Marlborough, MA 01752, USA
YanheファンAxiowave 200ニッカーソン道路マールボロ、MA 01752、USA
EMail: yfan@axiowave.com
メールアドレス：yfan@axiowave.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705, USA
ハルSandickシェパードM.S. 2401ダコタ・ストリートダーラム、NC 27705、USA
EMail: sandick@nc.rr.com
メールアドレス：sandick@nc.rr.com
Don Fedyk Nortel 600 Technology Park Drive Billerica, MA 01821, USA
ドン・ルブランノーテル600テクノロジーパークドライブビレリカ、MA 01821、USA
EMail: dwfedyk@nortelnetworks.com
メールアドレス：dwfedyk@nortelnetworks.com
Vishal Sharma Metanoia 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA
ヴィシャル・シャルマMetanoia 1600ヴィラ・ストリート、ユニット352マウンテンビュー、CA 94041、USA
EMail: v.sharma@ieee.org
メールアドレス：v.sharma@ieee.org
Gert Grammel Alcatel Lorenzstrasse, 10 70435 Stuttgart, Germany
ゲルトGrammelアルカテル・ローレンス・ストリート、10 70435シュトゥットガルト、ドイツ
EMail: gert.grammel@alcatel.de
メールアドレス：gert.grammel@alcatel.de
George Swallow Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
ジョージ・ツバメのCisco 250アポロドライブチェルムズフォード、MA 01824、USA
EMail: swallow@cisco.com
メールアドレス：swallow@cisco.com
Dan Guo Turin 1415 N. McDowell Blvd, Petaluma, CA 95454, USA
そして、郭トリノ1415 N.マクダウェルブルバード、ペタルマ、CA 95454、USA
EMail: dguo@turinnetworks.com
メールアドレス：dguo@turinnetworks.com
Z. Bo Tang Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z.ボー唐Tellium 2クレセントプレイス、P。ボックス901 Oceanport、NJ 07757から0901、USA
EMail: btang@tellium.com
メールアドレス：btang@tellium.com
Kireeti Kompella Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompellaジュニパー1194 N.マチルダアベニュー。サニーベール、CA 94089、USA
EMail: kireeti@juniper.net
メールアドレス：kireeti@juniper.net
Jennifer Yates AT&T 180 Park Avenue Florham Park, NJ 07932, USA
ジェニファー・イエーツAT＆T 180パークアベニューフローラムパーク、NJ 07932、USA
EMail: jyates@research.att.com
メールアドレス：jyates@research.att.com
Alan Kullberg NetPlane 888 Washington St.Dedham, MA 02026, USA
アランKullberg網面888ワシントンSt.Dedham、MA 02026、USA
EMail: akullber@netplane.com
メールアドレス：akullber@netplane.com
George R. Young Edgeflow 329 March Road Ottawa, Ontario, K2K 2E1, Canada
ジョージR.ヤングEdgeflow 329マーチロードオタワ、オンタリオ、K2K 2E1、カナダ
EMail: george.young@edgeflow.com
メールアドレス：george.young@edgeflow.com
Jonathan P. Lang Rincon Networks
ジョナサンP.ラングリンコンネットワーク
EMail: jplang@ieee.org
メールアドレス：jplang@ieee.org
John Yu Hammerhead Systems 640 Clyde Court Mountain View, CA 94043, USA
ジョン・ユーハンマーシステム640クライド法廷マウンテンビュー、CA 94043、USA
EMail: john@hammerheadsystems.com
メールアドレス：john@hammerheadsystems.com
Fong Liaw Solas Research Solas Research, LLC
フォンLiawソラス研究ソラス研究、LLC
EMail: fongliaw@yahoo.com
メールアドレス：fongliaw@yahoo.com
Alex Zinin Alcatel 1420 North McDowell Ave Petaluma, CA 94954, USA
アレックスジニンアルカテル1420北マクダウェルアベニューペタルマ、CA 94954、USA
EMail: alex.zinin@alcatel.com
メールアドレス：alex.zinin@alcatel.com
Eric Mannie (Consultant) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
エリックマニー（コンサルタント）マッド歌の通り、2 B-1050ブリュッセル、ベルギー電話：+32 2 648から5023携帯：+32（0）495から221775
EMail: eric_mannie@hotmail.com
メールアドレス：eric_mannie@hotmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、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機能のための基金は現在、インターネット協会によって提供されます。