[要約] RFC 3945は、GMPLSアーキテクチャに関する標準化ドキュメントであり、光通信ネットワークやパケットネットワークなどの異なるプロトコルを統合するための枠組みを提供します。その目的は、ネットワークの効率性と柔軟性を向上させ、異なるネットワーク技術を統一的に管理することです。
Network Working Group E. Mannie, Ed.
Request for Comments: 3945 October 2004
Category: Standards Track
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
汎用マルチプロトコル ラベル スイッチング (GMPLS) アーキテクチャ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (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)、光クロスコネクト (PXC)、光クロスコネクト (OXC) などの要素で構成されます。これは、Generalized Multi-Protocol Label Switching (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.
このアーキテクチャは、コントロール プレーンとフォワーディング プレーンを明確に分離します。さらに、コントロール プレーンを、シグナリング プロトコルを含むシグナリング プレーンとルーティング プロトコルを含むルーティング プレーンの 2 つの部分に明確に分離します。
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 アーキテクチャですでに説明されている概念を説明することではありません。目標は、Generalized 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
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
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.
一般化 MPLS (GMPLS) は、複数のタイプのスイッチングをサポートする点で従来の MPLS とは異なります。つまり、TDM、ラムダ、およびファイバー (ポート) スイッチングのサポートが追加されています。追加タイプのスイッチングのサポートにより、GMPLS は従来の MPLS の特定の基本機能を拡張し、場合によっては機能を追加するようになりました。これらの変更と追加は、ラベルの要求と伝達の方法、LSP の一方向性の性質、エラーの伝播方法、入力 LSR と出力 LSR を同期するために提供される情報など、基本的な LSP プロパティに影響を与えます。
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: 1. Packet Switch Capable (PSC) interfaces:
ここでは、元の MPLS アーキテクチャが拡張され、転送プレーンがパケットもセル境界も認識しないため、パケットまたはセルのヘッダーで伝送される情報に基づいてデータを転送できない LSR が含まれます。具体的には、このような LSR には、スイッチングの決定がタイム スロット、波長、または物理ポートに基づいて行われるデバイスが含まれます。したがって、新しい LSR セット、より正確にはこれらの LSR 上のインターフェイスは、次のクラスに細分化できます。 1. パケット交換対応 (PSC) インターフェイス:
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.
パケット境界を認識し、パケット ヘッダーの内容に基づいてデータを転送できるインターフェイス。例には、IP ヘッダーの内容に基づいてデータを転送するルーター上のインターフェイスや、MPLS「シム」ヘッダーの内容に基づいてデータを切り替えるルーター上のインターフェイスが含まれます。
2. Layer-2 Switch Capable (L2SC) interfaces:
2. レイヤ 2 スイッチ対応 (L2SC) インターフェイス:
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.
フレーム/セル境界を認識し、フレーム/セル ヘッダーの内容に基づいてデータを切り替えることができるインターフェイス。例には、MAC ヘッダーの内容に基づいてデータをスイッチングするイーサネット ブリッジ上のインターフェイスや、ATM VPI/VCI に基づいてデータを転送する ATM-LSR 上のインターフェイスが含まれます。
3. Time-Division Multiplex Capable (TDM) interfaces:
3. 時分割多重対応 (TDM) インターフェイス:
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 インターフェイスが含まれます。
4. Lambda Switch Capable (LSC) interfaces:
4. ラムダ スイッチ対応 (LSC) インターフェイス:
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 インターフェイスが含まれます。
5. Fiber-Switch Capable (FSC) interfaces:
5. ファイバースイッチ対応 (FSC) インターフェイス:
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 にネストされた下位の SONET/SDH LSP (VT2/VC-12 など) を多重化できる場合、階層を構築できます。SDH LSP (例: STS-3c/VC-4)。SONET/SDH 多重化階層では、いくつかのレベルの信号 (LSP) ネストが定義されています。
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.
ネストはインターフェイス タイプ間でも発生する可能性があります。階層の最上位は FSC インターフェイス、次に LSC インターフェイス、その次が TDM インターフェイス、その次が L2SC、その次が PSC インターフェイスです。このようにして、PSC インターフェイスで開始および終了する LSP を、L2SC インターフェイスで開始および終了する LSP に (他の LSP と一緒に) ネストすることができます。この LSP は、(他の LSP と一緒に) TDM インターフェイス上で開始および終了する LSP にネストできます。次に、この LSP は、LSC インターフェイスで開始および終了する LSP に (他の LSP と一緒に) ネストすることができ、さらに、その LSP を、FSC インターフェイスで開始および終了する 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.
パケット スイッチ対応 (PSC) またはレイヤ 2 スイッチ対応 (L2SC) インターフェイスのみにまたがる LSP の確立は、元の 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]) の動作をサポートするには、新しい専用プロトコルが 1 つだけ必要です。
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 を配置するには、一般に、いくつかの制約 (フレーミング、帯域幅、保護機能など) を考慮し、従来の Shortest-Path First (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 リンクは、2 つの GMPLS ノード間の特定の物理リソースとそのプロパティの、IS-IS/OSPF リンク状態アドバタイズメントおよびリンク状態データベース内の表現です。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 シグナリング用に定義された 2 つのシグナリング プロトコル、つまり RSVP-TE [RFC3209] と CR-LDP [RFC3212] を拡張します。ただし、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 目的ですでに拡張されている 2 つの従来のドメイン内リンクステート ルーティング プロトコル、つまり OSPF-TE [OSPF-TE] と IS-IS-TE [ISIS-TE] も拡張します。ただし、明示的 (ソース) ルーティングが使用される場合、これらのプロトコルで使用されるルーティング アルゴリズムを標準化する必要はなくなります。ドメイン間ルーティングの拡張機能 (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 つの隣接するノードを接続する各リンク上でルーティング隣接関係が確立されることを前提としています。このように多数の隣接関係があると、適切に拡張できません。各ノードはそれぞれの隣接関係を 1 つずつ維持する必要があり、リンク状態のルーティング情報をネットワーク全体にフラッディングする必要があります。
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.
GMPLS によって MPLS-TE に導入されたいくつかの重要な拡張機能を以下に示します。それらのいくつかは、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 では、LSP が通過するリンクに、異種ラベル エンコードを使用したリンクが混在する可能性があります (たとえば、ルータ間のリンク、ルータと ATM-LSR 間のリンク、ATM-LSR 間のリンクなど)。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 または 10Gb イーサネットなどのペイロードが可能になりました。
- 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.
- TDM、LSC、または FSC リンクでは、PSC または L2SC リンクよりもラベルの数が (大幅に) 少なくなることが予想されます。これは、前者が論理ラベルではなく物理ラベルであるためです。
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 学習ネイバー) はデータ プレーンのネイバーではない可能性があります。したがって、TE リンクを隣接ノードに関連付けるには、LMP のようなメカニズムが必要です。
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 ルーティング プロトコルを再利用することで、非 PSC 層で、特にドメイン内ルーティング (リンクステート ルーティング) およびドメイン間ルーティングのコンテキストにおいて、IP ルーティングに関して長年にわたって行われてきた貴重な開発をすべて活用できるようになります。ルーティング (ポリシー ルーティング)。
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 などのドメイン間ルーティング プロトコルを介して行うことができます。BGP によって提供されるよく知られたポリシー ルーティング機能を非 PSC コンテキストで再利用することには明らかに大きな価値があります。非 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、または出力 LSR) または内部 LSR のいずれかになります。非 PSC ホストの例としては、SONET/SDH Terminal Multiplexer (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 アドレスが必要です。もちろん、統合モデルが使用される場合は、2 つの層が同じアドレス空間を共有できます。最後に、IP アドレスが利用できない場合、または IP アドレスを管理するオーバーヘッドが高すぎると考えられる場合、TE リンクは「番号なし」、つまり 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 層に対応するには十分すぎるほどです。非 PSC デバイス (SONET/SDH ノードなど) の数は、現在の IP ホストやルーターよりもはるかに少ないと予想できます。
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 層では、数百の並列物理リンク (波長など) が 2 つのノードを接続できるようになるため、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-IS リンクの付属物としてアドバタイズされます。つまり、リンク上で隣接関係が確立されます。リンクが稼働している場合、リンクの通常の IGP プロパティ (基本的には SPF メトリック) とリンクの TE プロパティの両方がアドバタイズされます。
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.
- 第 2 に、LSP はルーティング プロトコルのポイントツーポイント TE リンク、つまり転送隣接関係 (FA) としてアドバタイズできます。したがって、アドバタイズされる 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 リンクの 1 対 1 の関連付けは存在しません。
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 で設定でき、その他は何らかのプロトコルによって他の LSR から取得でき、さらに他のプロパティは TE リンクのコンポーネントから推定できます。
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 レイヤに対して異なるアカウンティング ルールを定義します。ただし、予約されていない帯域幅、予約可能な最大帯域幅、最大 LSP 帯域幅などの一般的な帯域幅属性は、TE ルーティング拡張機能および 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 は、TE オブジェクト/TLV を使用して、そのリンクを GMPLS 拡張 OSPF または IS-IS ネイバーにアドバタイズできます。GMPLS 拡張 OSPF または 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 アドレスを持たないリンク (またはインターフェイス) です。このようなリンクの使用には 2 つの機能が含まれます。1 つは MPLS TE シグナリングで番号なしリンクを指定する機能、もう 1 つは IS-IS-TE および OSPF-TE の IGP TE 拡張で番号なしリンクに関する番号なしリンクに関する (TE) 情報を伝送する機能です。
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 シグナリングで番号なしリンクを指定するには、RSVP-TE [RFC3477] および CR-LDP [RFC3480] の拡張が必要です。MPLS-TE シグナリングは、明示的ルート オブジェクト/TLV およびレコード ルート オブジェクトで番号なしリンクを示す方法を提供しないため、番号なしリンクのサポートを提供しません (CR-LDP にはそのような TLV はありません)。GMPLS は、新しい番号なしインターフェイス ID サブオブジェクト/サブ TLV を使用して、これら 2 つのオブジェクト/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 (特にリンクが転送隣接の場合、以下を参照) などの設定によって実行できます。または、IS-IS または 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 と LSR B の間の (番号なし) リンクを考えてみましょう。LSR A は、そのリンクの識別子を選択します。LSR Bも同様です。Aの観点から、Aがリンクに割り当てた識別子を「リンクローカル識別子」（または単に「ローカル識別子」）と呼び、Bがリンクに割り当てた識別子を「リンクリモート識別子」と呼びます。識別子」（または単に「リモート識別子」）。同様に、B の観点からは、B がリンクに割り当てた識別子はローカル識別子であり、A がリンクに割り当てた識別子はリモート識別子です。
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.
ER オブジェクト/TLV の新しい番号なしインターフェイス ID サブオブジェクト/サブ 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) 情報の機能には、IS-IS-TE で定義された拡張 IS 到達可能性 TLV および OSPF で定義された TE LSA (不透明な LSA) 用の新しいサブ TLV が必要です。-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 がこの LSP を IS-IS または OSPF の番号なし FA としてアドバタイズする場合、または LSR がこの FA をバンドル リンクの番号なしコンポーネント リンクとして使用する場合、LSR はその FA にインターフェイス ID を割り当てる必要があります。LSP が双方向の場合、テールエンドも同様のことを行い、インターフェイス ID を逆方向 FA に割り当てます。
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 には、ルーター ID (それを生成する LSR の) とインターフェイス ID が含まれています。これは、Path/REQUEST メッセージに表示される場合は Forward Interface ID と呼ばれ、Resv/MAPPING メッセージに表示される場合は Reverse Interface 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.
リンク バンドリングの概念は、[BUNDLE] で定義されている 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 のペアが複数のリンクで接続されている場合、これらのリンクのいくつか (またはすべて) を 1 つのリンクとして 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.
その結果、LSP が使用する適切なリソースを明確に識別するには、3 つの識別子 ((バンドル) リンク識別子、コンポーネント リンク識別子、ラベル) の組み合わせで十分です。
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 や IS-IS で処理する必要がある情報の量を削減することにより、ルーティングのスケーラビリティを向上させることです。この削減は、情報の集約/抽象化を実行することによって実現されます。他の情報の集約/抽象化と同様に、これにより情報の一部が失われます。損失の量を制限するには、集約/抽象化できる情報の種類を制限する必要があります。
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 リンクの別の種類にすぎません。バンドルされたリンクの活性度は、その各コンポーネント リンクの活性度によって決まります。バンドルされたリンクは、そのコンポーネント リンクの少なくとも 1 つが生きているときに生きています。コンポーネント リンクの活性度は、コンポーネント リンク上の IS-IS または OSPF hello、RSVP Hello (ホップ ローカル)、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 Hello メカニズムは、リンク層障害の通知が利用できず番号なしリンクが使用されない場合、またはリンク層によって提供される障害検出メカニズムが使用されない場合に使用されることを目的としていることに注意してください。ノード障害をタイムリーに検出するには不十分です。
Once a bundled link is determined to be alive, it can be advertised as a TE link and the TE information can be flooded. If IS-IS/OSPF hellos are run over the component links, IS-IS/OSPF flooding can be restricted to just one of the component links.
バンドルされたリンクが生きていると判断されると、そのリンクを TE リンクとしてアドバタイズでき、TE 情報をフラッディングできます。IS-IS/OSPF hello がコンポーネント リンク上で実行される場合、IS-IS/OSPF フラッディングはコンポーネント リンクの 1 つだけに制限できます。
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 隣接関係があることを意味するわけではないことに注意してください。実際、場合によっては、LSR 間に IGP 隣接関係がまったくない場合でも、LSR ペア間の TE リンクがアドバタイズされる可能性があります (たとえば、TE リンクが FA である場合)。
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.
通常、LSP の明示的なルート (たとえば、明示的なルート オブジェクト/TLV に含まれる) は、コンポーネント リンクではなく、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 アドレスが必要です。上流ノードは、パス/ラベル要求メッセージに IPv4 または IPv6 アドレスを運ぶ新しい IF_ID RSVP_HOP オブジェクト/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 は、これらの識別子を交換します。識別子の交換は、設定、LMP (推奨ソリューション) などのプロトコル、RSVP-TE/CR-LDP (特にコンポーネント リンクが転送隣接関係である場合)、またはその他の手段によって実行できます。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 ERO の形式に影響します。さらに、特定の 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.
コンポーネント リンクをバンドルするための一般的なルールは、何らかの方法で相関しているリンクを同じバンドルに配置することです。リンクが複数のプロパティに基づいて関連付けられる場合、バンドルはこれらのプロパティに基づいて順番に適用されます。たとえば、最初にリンクを最初のプロパティに基づいてグループ化することができます。これらのグループのそれぞれは、2 番目の特性などに基づいて、より小さなグループに分割できます。このプロセスで従う主な原則は、結果として得られるバンドルのプロパティが簡潔に要約可能である必要があるということです。リンクのバンドルは自動的に、または構成によって実行できます。自動リンク バンドルでは、バンドル ルールを順番に適用してバンドルを作成できます。
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]、2 番目のプロパティはエンコーディング [GMPLS-ROUTING]、3 番目のプロパティは管理上の重み (コスト) です。4 番目のプロパティはリソース クラスで、最後に 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 に属するリンクを介してルーティングされないということです。したがって、従うべきルールは、まったく同じ SRLG セットに属するリンクをグループ化することです。
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).
エッジ GMPLS ノードとネットワーク側の GMPLS LSR 間のインターフェイスは、ユーザー対ネットワーク インターフェイス (UNI) と呼ばれる場合がありますが、2 つのネットワーク側 LSR 間のインターフェイスは、ネットワーク間インターフェイス (NNI) と呼ばれる場合があります。）。
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 アプローチは、UNI インターフェイスと NNI インターフェイスの両方を同時に考慮して、一貫したモデルを初日から構築することで構成されていました [GMPLS-OVERLAY]。その目的のために、ごく少数の特定の 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 では、構成ベース、部分ピアリング、サイレント リスニング、完全ピアリングの 4 つの異なるルーティング モデルをサポートできます。
- 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 を使用して実現できます。UNI では、LSR の順序付きリストを除いて、ルーティング情報は交換されません。エッジ ノードによって使用される唯一のルーティング情報はそのリストです。エッジ ノードは、デフォルトで LSP リクエストを優先 LSR に送信します。この LSR によって ICMP リダイレクトが送信され、一部の 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.
- サイレント リスニング: エッジ ノードはサイレントにルーティング プロトコルをリッスンし、取得した情報に基づいてルーティングを決定できます。エッジ ノードは、トラフィック エンジニアリング拡張を含む完全なルーティング情報を受け取ります。1 つの 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 の Hello プロトコルは、IGP Hello が失われず、関連するリンクステート隣接関係が無駄に削除されないように、制御チャネルの障害に迅速に反応する軽量のキープアライブ メカニズムであることを目的としています。
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.
Hello プロトコルは、ネゴシエーション フェーズとキープアライブ フェーズの 2 つのフェーズで構成されます。ネゴシエーション フェーズでは、Hello 周波数などのいくつかの基本的な Hello プロトコル パラメータのネゴシエーションが可能になります。キープアライブ フェーズは、高速で軽量な双方向の 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 制御チャネル メッセージ (構成メッセージと Hello メッセージを除く) は、ローカル ノードとリモート ノードの間で調整することなく、アクティブな制御チャネルのいずれかを介して送信される可能性があります。
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 の一部として、リンク プロパティ相関交換が定義されています。この交換は、複数のデータを含むリンク (コンポーネント リンク) を 1 つのバンドル リンクに集約し、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) を使用している場合、障害検出は特に問題になります。接続が確立されると、PXC は接続の状態を限定的にしか把握できなくなります。PXC はすべて光ですが、長距離 OLS は通常、チャネルを電気的に終端し、光的に再生成します。これにより、PXC 間のチャネルの健全性を監視する機会が得られます。OLS は LMP-WDM を使用して、この情報を PXC に提供できます。
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 に知られている接続の管理状態 (たとえば、この情報は GMPLS シグナリング [RFC3471] の Admin Status オブジェクトを通じて学習できる) を使用して偽のアラームを抑制できるため、アラーム管理は重要です。たとえば、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 つ以上の OLS とピアリングでき、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-OLS LMP セッションを介して交換される情報を OXC-OXC セッションで使用するには、情報が OXC によって調整される必要があります。ただし、OXC-OXC および OXC-OLS LMP セッションは独立して実行されるため、個別に維持する必要があります。OXC-OLS LMP セッションを実行するときの重要な要件の 1 つは、検証手順を実行していないときにデータ リンクを透過的にできる OLS の機能です。これは、OXC-OLS 間と OXC-OXC 間で同じデータ リンクが検証される可能性があるためです。LMP の検証手順は、テスト手順 (したがって、データ リンクの透明性/不透明性) を調整するために使用されます。セッション間の独立性を維持するには、LMP セッションが任意の順序で起動できる必要があります。特に、OXC-OLS LMP セッションが開始されずに OXC-OXC 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. シグナリング機能の説明 [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].
1. SONET および SDH 制御用の GMPLS 拡張 [RFC3946]。2. G.709 制御用の GMPLS 拡張 [GMPLS-G709]。
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.
- Ingress により順序付けられた制御が開始されました。
- 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. 新しい汎用ラベル リクエスト形式。2. TDM、LSC、および FSC インターフェイスのラベル。一般に一般化ラベルとして知られています。3. 波長帯切り替えのサポート。4. 最適化を目的としたアップストリームによるラベルの提案 (レイテンシーなど)。5. いくつかの光学的制約をサポートするために、アップストリームによるラベル制限。6. 競合解決を伴う双方向 LSP の確立。7. 急速な障害通知の拡張機能。8. 現在リンク保護に焦点を当てている保護情報と、プライマリおよびセカンダリ LSP 表示。9. 明示的なラベル制御による明示的なルーティングにより、細かい制御が可能。10. テクノロジーごとの特定のトラフィック パラメーター。11. LSP 管理ステータスの処理。12. チャンネル分離を制御します。
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 のタイプ (つまり、関係する層) とそのペイロード タイプを含む一般化ラベル要求が含まれています。通常、Explicit Route Object (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 の場合、アップストリーム ラベルもパス/ラベル要求メッセージで指定されます。このラベルは、アップストリーム方向で使用されるラベルになります。
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 バーチャル コンカチネーションの場合、ラベルのリストが返されます。各ラベルは、仮想連結信号の 1 つの要素を識別します。これにより、仮想連結が単一 (コンポーネント) リンク内に留まるように制限されます。
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 連続連結の場合でも、ラベルは 1 つだけ返されます。そのラベルは、([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 パス メッセージに追加されるか、既存の TLV に加えて CR-LDP 要求メッセージに追加される新しいオブジェクト/TLV です。メッセージごとに使用できるラベル要求は 1 つだけであるため、シグナリング メッセージごとに一度に 1 つの 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 をサポートするために必要な 3 つの主要な特性 (パラメータ)、つまり LSP エンコーディング タイプ、使用する必要があるスイッチング タイプ、および一般化 PID (G-PID) と呼ばれる LSP ペイロード タイプを提供します。
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 に関連付けられたデータで使用されるエンコーディング タイプ、つまり、考慮されているテクノロジーのタイプを示します。たとえば、SDH、SONET、イーサネット、ANSI PDH などが考えられます。これは LSP の性質を表し、LSP が通過するリンクの性質を表しません。これは各ノードによってホップバイホップで使用されます。
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 のエンドポイントにあるノードによって、リクエストの宛先がどのクライアント層であるかを知るために使用され、場合によっては最後から 2 番目のホップによって使用されます。
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 セットのトラフィック パラメータが定義されています。1 つは SONET/SDH 用、もう 1 つは G.709 用です。
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.
- 第 2 に、仮想連結はオプションで基本信号に直接適用することも、前のフェーズから取得した連続的に連結された信号に適用することもできます。
- Third, some transparency can be optionally specified when requesting a frame as signal rather than a container. Several transparency packages are defined.
- 3 番目に、コンテナではなく信号としてフレームをリクエストするときに、オプションである程度の透明度を指定できます。いくつかの透明性パッケージが定義されています。
- 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.
- 第 4 に、乗算は、基本信号に直接、または最初のフェーズから取得された連続的に連結された信号に、または 2 番目のフェーズから取得された仮想的に連結された信号に、または何らかの透明性と組み合わせられたこれらの信号に、オプションで適用できます。
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 つの主要な層に分解されます。これら 2 つの層はサブ層に分割され、スイッチングは 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.
最初のトラフィック パラメータは、要求された LSP を構成する基本的な G.709 信号のタイプ（たとえば、ODU1、40 Gbps の OCh など）を指定します。その後、いくつかの変換を基本信号に連続して適用して、実際に要求されている最終信号を構築できます。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.
- 第 2 に、基本信号に直接、または最初のフェーズから得られた仮想的に連結された信号に乗算をオプションで適用できます。
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 マッピング (ODUj から ODUk) を示すことができます。G.709 は、ODUj から ODUk (k > j) への多重化機能、および ODU1 と ODU2 を ODU3 へ多重化する多重化機能をサポートしています。
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 トラフィック パラメータは新しい SENDER-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.
Generalized Label は、関連するデータ パケットとともに帯域内を通過するラベルだけでなく、タイムスロット、波長、または空間分割多重位置を識別する (仮想) ラベルの表現も可能にすることで、従来の 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 はそれぞれ多重化構造を定義します。これらの多重化構造は、一意のラベルを作成するための名前付けツリーとして使用されます。このようなラベルは、多重化構造内の信号の正確な位置 (タイムロット) を識別します。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 ラベルは、この特殊なケースをサポートするために定義されています。
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、開始ラベル、および終了ラベルの 3 つのフィールドが含まれます。開始ラベルと終了ラベルは、波長帯を構成する最低値の波長と最高値の波長をそれぞれ識別する、送信側の観点からのチャネル識別子です。
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/MAPPING メッセージをホップごとに数十ミリ秒遅延させる必要がある場合があります。これは、ネットワーク障害の結果として代替 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.
ラベル セットの受信者は、ラベルの選択をラベル セット内のラベルに制限する必要があります。ラベル セットは複数のホップにわたって存在する場合があります。この場合、各ノードは、おそらく受信ラベル セットとノードのハードウェア機能に基づいて、独自の送信ラベル セットを生成します。このケースは、変換不可能なインターフェイスを持つノードでは標準的なものであると予想されます。
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 往復シグナリング時間に 1 つのイニシエータとターミネータのシグナリング通過遅延を加えたものに等しくなります。これにより、LSP 確立が成功するまでのセットアップ レイテンシが延長されるだけでなく、失敗した LSP を検出するための最悪の場合のレイテンシも、イニシエータとターミネータの通過遅延の 2 倍まで延長されます。これらの遅延は、復元目的で確立された 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 の 2 倍です。これは、双方向 LSP の両方のセグメントに対して個別の制御メッセージ (Path と Resv など) を生成する必要があるためです。
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.
5. 双方向光 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 の復元とエラー処理を担当するノードへの障害やその他のイベントの迅速な通知を可能にする、いくつかのシグナリング拡張機能を定義します。
1. Acceptable Label Set for notification on Label Error:
1. ラベル エラーの通知に使用できるラベル セット:
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 では、「許容ラベル セット」を介してそのような情報を伝達する機能が導入されています。許容可能なラベル セットは、適切なプロトコル固有のエラー メッセージで伝えられます。許容可能なラベル セットの形式はラベル セットと同じです。
2. Expedited notification:
2. 迅速な通知:
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 には、現在同様のメカニズムがありません。最初の拡張子は、イベント通知の送信先を識別します。2 つ目は、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.
通知メッセージは、直上流または下流の隣接ノード以外のノードを「対象とする」ことができるという点で、現在定義されているエラー メッセージとは異なる一般化された通知メカニズムです。通知メッセージは既存のエラー メッセージを置き換えるものではありません。Notify メッセージは、次のいずれかで送信できます。(a) 通常、[RFC2205] の ResvConf 処理と同様に、非ターゲット ノードが Notify メッセージをターゲット ノードに転送するだけです。または (b) 宛先がターゲット IP アドレスと等しい新しい IP ヘッダーにカプセル化されます。
3. Faster removal of intermediate states:
3. 中間状態の高速な削除:
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 のリソースを使用している 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、共有、非保護、追加トラフィックの 6 つのリンク保護タイプが個別のフラグとして定義されており、組み合わせることができます。それぞれの正確な定義については、[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.
これは、2 つの 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.
- 2 番目に、ルート記録メカニズムは、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".
- 3 番目に、記録されたルートを明示的なルートの入力として使用できます。これは、送信元ノードが宛先ノードから記録されたルートを受信し、「パスを特定する」ためにそれを明示的なルートとして適用する場合に便利です。
Within the GMPLS architecture, only the second and third functions are mainly applicable for TDM, LSC and FSC layers.
GMPLS アーキテクチャ内では、主に 2 番目と 3 番目の機能のみが 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 変更のセマンティクスはテクノロジーごとに異なります。たとえば、帯域幅、保護タイプ、透過性、連結など、一部の 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.
最初の使用法では、Admin Status オブジェクト/TLV は、LSP の管理状態を示すために、Path/Label Request または 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 を破棄する前に LSP の管理ステータスを「削除中」に設定すると便利です。入力 LSR は、適切な管理ステータス オブジェクト/TLV をパス/ラベル要求 (変更に設定された変更アクション インジケーター フラグを含む) メッセージに挿入することにより、LSP の削除に先立ちます。トランジット LSR は、管理ステータス オブジェクト/TLV を処理して転送します。出力 LSR は、Admin Status オブジェクトを含む Resv/Label Mapping (変更アクション インジケーター フラグが変更に設定された) メッセージで応答します。このメッセージとオブジェクトを受信すると、入力ノードは PathTear/Release メッセージをダウンストリームに送信して LSP を削除し、通常の 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.
2 番目の使用法では、管理ステータス オブジェクト/TLV が通知/ラベル マッピング (変更アクション インジケータ フラグが変更に設定されている) メッセージで伝送され、入力ノードが LSP の管理状態を変更するように要求します。これにより、中間ノードと出力ノードが管理ステータスの設定をトリガーできるようになります。特に、これにより、入力ノードによって開始された LSP の解放を要求する中間または出力 LSR が可能になります。
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 では、制御チャネルとデータ チャネルの暗黙的な 1 対 1 の関連付けが存在します。このような関連付けが存在する場合、特定の 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 にすることができます。最後の 3 つのケースでは、埋め込み TLV 自体に IP アドレスとインターフェイス ID が含まれており、IP アドレスはインターフェイス ID (たとえばルーター 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) TE LSP を作成する LSR、(b) その LSP から転送隣接関係を形成する LSR (この LSP をトラフィック エンジニアリング (TE) リンクとして IS-IS/OSPF にアドバタイズします)、(c) によって実行されます。）他の LSR がパス計算に転送隣接関係を使用できるようにすること、および（d）他の LSR によって生成された LSP をその LSP にネストすること（たとえば、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 を使用して、パスに沿ったラベル バインディングを確立します。FA には、シグナリングおよびルーティング プロトコルの単純な拡張が必要です。
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 および IS-IS でアドバタイズされます。これらの最後の 2 つの仕様は、ベース TE リンクを定義する [OSPF-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 から継承されます。[HIERARCHY] は、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 はこの情報をパス計算に使用する場合があります。この情報は、パス TLV と呼ばれる新しい OSPF および IS-IS 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 階層は FA を介して実現され、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
新しい OSPF および IS-IS サブ TLV は、PSC、L2SC、TDM、LSC、または FSC の各インターフェイスの多重化機能をアドバタイズするために定義されました。このサブ 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 のパスを計算するときに領域境界が考慮される場合があります。たとえば、パス計算では、LSP が選択するパスを、多重化/逆多重化機能が PSC であるリンクのみに制限できます。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.
定義により、2 つのノードは、IS-IS/OSPF の意味で隣接している場合、ルーティング (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.
定義により、2 つのノードは、RSVP-TE/CR-LDP の意味で隣接している場合、シグナリング (RSVP-TE/CR-LDP) 隣接関係を持ちます。ノード A および B は、(たとえば、[HIERARCHY] のセクション 7.1.1 および 7.1.2 で説明されているように) RSVP-TE メッセージ (Path/Resv) を直接交換する場合、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 つのノードにはルーティング隣接関係があることが期待されます (必須ではありません)。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).
2 つのノード間にルーティングやシグナリングの隣接関係を確立したい場合は、それらの間に IP パスが存在する必要があります。この IP パスは、たとえば、PSC のインターフェイス スイッチング機能を備えた TE リンク、IP リンクに似たもの（たとえば、GRE トンネル、または PSC のインターフェイス スイッチング機能を備えた（双方向）LSP）にすることができます。。
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 リンクがある場合があります。当然のことながら、TE リンクをアドバタイズするには、各ノードで GMPLS 拡張機能を備えた OSPF/IS-IS を実行する必要があります。より正確には、ノードは PSC 以外のインターフェイス スイッチング機能 ([GMPLS-ROUTING] を参照) を備えた 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 を確立するときに、Interface_ID (IF_ID) オブジェクトを使用して特定の TE リンクを指定する必要があります。
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 種類あります。1 つ目は、制御チャネル障害と呼ばれるもので、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.
2 つ目はノード障害と呼ばれ、ノードが制御状態を失っても (再起動後など)、データ転送状態は失われない場合に関連します。
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.
これらの問題はプロトコル固有の方法で対処されています。[RFC3473]、[RFC3472]、[OSPF-TE-GMPLS]、および [ISIS-TE-GMPLS] を参照してください。これらのケースは、制御チャネルの障害とは独立してデータ チャネルの障害を検出するメカニズムがある場合にのみ適用されることに注意してください。
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 に影響を与える障害がデータ/トランスポート プレーンで発生した場合にのみ適用されます。セクション 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 は、1 つのルーティング エリア内の同様の顧客機器の集合、または同様の機能を持つ機器の集合など、さらに制限できることに注意してください。
- 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] の 2 つの次元を考慮する必要があります。
- 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.
- 複数の P&R ドメインで構成される水平階層。これは LSP ベースの保護スキームで重要です。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).
- さまざまな粒度（パケット フロー、STS トレイル、ライトパス、ファイバーなど）を持つ P&R の複数の層で構成される垂直階層。
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 階層内のあるレベルから次のレベルに伝播する可能性があります。これは「衝突」を引き起こす可能性があり、同時に回復アクションを実行すると、競合状態、リソース使用率の低下、または不安定性が発生する可能性があります [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.
各層および各ドメインでの P&R に必要な時間スケールを決定するには、ネットワーク オペレータとそのクライアントの間のサービス レベル アグリーメント (SLA) が必要です。
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 は、小さなサービス レベルのセットの 1 つに分類できます。とりわけ、これらのサービス レベルは 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 の可能なプロビジョニング タイプと、それらのリカバリ LSP で発生する可能性のあるオーバーブッキングのレベルの分類を示しています。
+-Computed on +-Established +-Resources pre-
| demand | on demand | allocated
| | |
Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand
+--- 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 または新しいものに)。
- 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、Loss-of-Light (LOL) など) によって検出されます。ノードが障害を検出すると、GMPLS エンティティにアラームが渡され、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).
- 障害の位置特定は、GMPLS を利用して行うことができます。たとえば、障害の位置特定に LMP を使用します (セクション 6.4 を参照)。
- 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 通知など、GMPLS を通じて実現することもできます (セクション 7.12 を参照)。
- 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 つのリソースが並行して使用されます。たとえば、データは 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 と保護 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 のような分散コントロール プレーンの使用により、10 分の 1 ミリ秒の倍数で復旧が可能です。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 確立中に) 事前に計算されることもあります。重要なのは、障害が発生する前に復元パスに沿ってシグナリングが使用されず、復元帯域幅が予約されていないことです。したがって、障害が発生したときに特定の復元パスが使用できるという保証はありません。したがって、利用可能なパスを検索するためにクランクバックする必要がある場合があります。
- 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 つのパスに障害が発生するたびに復旧パスを再計算することで、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 に影響を及ぼす障害が発生した場合、ラベルの割り当てが変更されない限り、これらの LSP のうち 1 つだけを回復できます。
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 障害、任意の 2 つの 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 保護スイッチングの目標復旧時間 (障害を検出する時間を含まない) は、距離、関係する接続数、およびリング拡張の場合の制約を考慮して、[ITUT-G.841] で 50 ミリ秒と規定されています。保護、リング内のノードの数。
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 では共有なしが許可されますが、1:N では保護リソースの一部の共有と追加 (プリエンプタブル) トラフィックのサポートが許可されます。従来の強化された保護方式の固定リング トポロジなど、トポロジの制限により柔軟性が制限されます。
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.
復元スキームが複数の独立した障害間での共有をどの程度許可するかは、復元プールのサイズによって直接決まります。再プロビジョニングを伴う復元スキームでは、障害後にすべての復元ルートが選択される復元容量のプールを定義できます。したがって、共有の程度は、利用可能な復元容量の量によって定義されます。事前に通知された帯域幅予約による復元では、予約された復元容量の量はローカル帯域幅予約ポリシーによって決まります。すべての復元スキームにおいて、プリエンプタブル リソースは、予備の復元容量が障害回復に使用されていない場合に使用できます。
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 の機器は地理的に離れたサイトに分散されている可能性があるため、分散管理がさらに重要になることに注意することが重要です。サービスプロバイダーは、NMS システムと SNMP ([RFC3410]、[RFC3411]、[RFC3416] を参照) などの標準管理プロトコル、および関連する MIB モジュールを標準インターフェイスとして利用して、さまざまな場所でデバイスを設定、監視、プロビジョニングする必要があります。サービス プロバイダーは、ベンダーが自社のデバイスで提供するコマンド ライン インターフェイス (CLI) を使用したい場合もあります。ただし、これは標準または推奨のソリューションではありません。標準の CLI 言語またはインターフェイスがないため、N 個の異なるベンダーのデバイスを備えたネットワーク内に N 個の異なる CLI が存在することになります。GMPLS のコンテキストでは、テクノロジー自体の性質により、SP のデバイスへの標準インターフェイス (SNMP など) が存在することが非常に重要です。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 経由でリモート デバイスに配布できます。したがって、SP のネットワーク管理タスクは、各デバイスを個別に (つまり CLI 経由で) 管理する必要がなくなり、はるかにコンパクトかつ楽になります。
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 のネットワーク内で非常に効果的に使用できます。このアプローチをユビキタスに使用して、非異種ネットワーク内または SP のネットワーク境界を越えてデバイスをプロビジョニング、構成、監視できるようにするには、標準化された MIB を開発する必要があります。
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 インターフェイスを使用して実現することもできます。MIB モジュールは、IETF または ITU で事前に定義されている場合があります。GMPLS が必要とする新しい機能の一部を容易にするために、現在の MIB モジュールを拡張する必要がある場合があります。このような場合、作業グループは、これらの拡張機能を追加できるように、これらの 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].
従来のネットワークと同様、GMPLS ネットワークのデバッグとパフォーマンス監視には、traceroute [RFC1393] や ping [RFC2151] などの標準ツールが必要ですが、主にデータ プレーン トポロジを模倣するコントロール プレーン トポロジに必要です。さらに、このようなツールはネットワーク到達可能性情報を提供します。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 データと制御情報の制御と送信に関与する可能性があるため、ある層の障害を隣接する上位層と下位層に渡して障害を通知する必要があります。。ただし、これらの多くのレイヤーの性質上、レイヤー間で数百、さらには数千の通知が発生する必要がある可能性があり、おそらくその可能性さえあります。これはいくつかの理由から望ましくないです。まず、これらの通知によりデバイスに負荷がかかります。第 2 に、デバイスが SNMP 通知 [RFC3417] を発行するようにプログラムされている場合、デバイスが発行しようとする大量の通知により、通知の嵐でネットワークが圧倒される可能性があります。さらに、デバイスが通知を発行したとしても、これらの通知を処理する必要がある NMS は負荷が高くなるか、冗長な情報を処理することになります。つまり、レイヤー B の 1000 個のインターフェイスがその下のレイヤー A の 1 つのインターフェイスの上にスタックされており、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 は、複数のテクノロジーおよびタイプのネットワーク要素のコントロール プレーン アーキテクチャを定義します。一般に、GMPLS を使用して確立された LSP は大量のデータを伝送し、大量のネットワーク リソースを消費する可能性があるため、コントロール プレーンに対する攻撃やデータ トランスポート リソースの不正使用から基盤となるネットワークを保護するセキュリティ メカニズムが必要です。したがって、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 プロトコル スイート ([RFC2402]、[RFC2406]、および [RFC2409] を参照) を使用して、GMPLS 制御チャネルに認証、機密性、またはその両方を提供することもできます。したがって、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.
リクエストを認証した後、制御要素はリクエストをローカル認可ポリシーと照合する必要があります。これらの制御要素は、暗号学的および/またはトポロジー的に検証された要求者の ID に基づいて決定を下すことができなければなりません。たとえば、要求が行われるインターフェイスがドメイン間インターフェイスであるかドメイン内インターフェイスであるかによって決定が異なる場合があります。適切なローカル認証ポリシーを使用すると、ネットワークのリモート部分でのセキュリティ侵害の影響を制限するのに役立ちます。
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 ディスカッションを一緒に行ってくれた Ben Mack-Crane (Tellabs) に感謝します。また、SONET/SDH および光技術的なアドバイスとサポートを提供してくれた Ebone の Pedro Falcao、Alexandre Geyssens、Michael Moelants、Xavier Neerdaels、および Philippe Noel にも感謝します。最後に、セクション 12 の改訂作業に尽力いただいた Krishna Mitra (コンサルタント)、Curtis Villamizar (Avici)、Ron Bonica (WorldCom)、および Bert Wijnen (Lucent) にも多大な感謝を申し上げます。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen, 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.、Berger, L.、Gan, D.、Li, T.、Srinivasan, V.、および G. Swallow、「RSVP-TE: LSP トンネルのための RSVP の拡張」、RFC 3209、12 月2001年。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
[RFC3212] Jamoussi、B.、Andersson、L.、Callon、R.、Dantu、R.、Wu、L.、Doolan、P.、Worster、T.、Feldman、N.、Fredette、A.、Girish、M.、Gray、E.、Heinanen、J.、Kilty、T.、および A. Malis、「LDP を使用した制約ベースの LSP セットアップ」、RFC 3212、2002 年 1 月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
[RFC3471] Berger, L.、「Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional description」、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] Ashwood-Smith、P.、L. Berger、「Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions」、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] Berger, L.、「Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource Reservation Protocol-Traffic Engineering (RSVP-TE) Extensions」、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.
[バンドル] Kompella, K.、Rekhter, Y.、L. Berger、「MPLS トラフィック エンジニアリングにおけるリンク バンドリング」、進行中。
[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed., "Generalized MPLS Recovery Functional Specification", Work in Progress.
[GMPLS-FUNCT] Lang、JP、編。および B. Rajagopalan 編、「Generalized MPLS Recovery Functional 仕 様」、進行中の作業。
[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] Swallow, G.、Drake, J.、Ishimatsu, H.、および Y. Rekhter、「GMPLS UNI: オーバーレイ モデルの RSVP サポート」、作業中。
[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. 編、「同期光ネットワーク (SONET) および同期デジタル階層 (SDH) 制御のための汎用マルチプロトコル ラベル スイッチング (GMPLS) 拡張」、RFC 3946、2004 年 10 月。
[HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy with Generalized MPLS TE", Work in Progress.
[階層] Kompella、K.、Y. Rekhter、「汎用 MPLS TE を使用した LSP 階層」、進行中。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[ISIS-TE] Smit、H.、および T. Li、「トラフィック エンジニアリング (TE) のための中間システム間 (IS-IS) 拡張」、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] コンペラ、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] Lang, 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] フレデット、A. 編および J. Lang 編、「高密度波長分割多重 (DWDM) 光回線システム用のリンク管理プロトコル (LMP)」、進行中。
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The Evolution of Transport Network Survivability," IEEE Communications Magazine, August 1999.
[マンチェスター] J. マンチェスター、P. ボネファン、C. ニュートン、「トランスポート ネットワークの生存可能性の進化」、IEEE Communications Magazine、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-GMPLS] Kompella、K. 編および Y. Rekhter 編、「汎用マルチプロトコル ラベル スイッチングをサポートする OSPF 拡張機能」、進行中。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[OSPF-TE] Katz, D.、Kompella, K.、および D. Yeung、「OSPF バージョン 2 へのトラフィック エンジニアリング (TE) 拡張」、RFC 3630、2003 年 9 月。
[RFC1393] Malkin, G., "Traceroute Using an IP Option", RFC 1393, January 1993.
[RFC1393] Malkin, G.、「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] Kessler, G. および S. Shepard、「インターネットと 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] Braden, R.、Zhang, L.、Berson, S.、Herzog, S.、および S. Jamin、「リソース予約プロトコル (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] Kent, S. および R. Atkinson、「IP 認証ヘッダー」、RFC 2402、1998 年 11 月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent, S. および R. Atkinson、「IP カプセル化セキュリティ ペイロード (ESP)」、RFC 2406、1998 年 11 月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. および D. Carrel、「インターネット鍵交換 (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.
[RFC2702] Awduche, D.、Malcolm, J.、Agogbua, J.、O'Dell, M.、および J. McManus、「MPLS 上のトラフィック エンジニアリングの要件」、RFC 2702、1999 年 9 月。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.
[RFC2747] Baker, F.、Lindell, 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. Guerin、「ポリシーベースのアドミッション コントロールのフレームワーク」、RFC 2753、2000 年 1 月。
[RFC2925] White, K., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 2925, September 2000.
[RFC2925] White, K.、「リモート ping、トレースルート、およびルックアップ操作のための管理対象オブジェクトの定義」、RFC 2925、2000 年 9 月。
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A., and B. Thomas, "LDP Specification", RFC 3036, January 2001.
[RFC3036] Andersson, L.、Doolan, P.、Feldman, N.、Fredette, A.、および B. Thomas、「LDP 仕様」、RFC 3036、2001 年 1 月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
[RFC3386] Lai、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] Case, J.、Mundy, R.、Partin, D.、および B. Stewart、「インターネット標準管理フレームワークの概要と適用性に関する声明」、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] Harrington, 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.
[RFC3414] Blumenthal, U. および B. Wijnen、「簡易ネットワーク管理プロトコル (SNMPv3) バージョン 3 のユーザーベースのセキュリティ モデル (USM)」、STD 62、RFC 3414、2002 年 12 月。
[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、「簡易ネットワーク管理プロトコル (SNMP) のビューベースのアクセス制御モデル (VACM)」、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.、「簡易ネットワーク管理プロトコル (SNMP) のプロトコル操作のバージョン 2」、STD 62、RFC 3416、2002 年 12 月。
[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] Sharma, V. および F. Hellstruct、「マルチプロトコル ラベル スイッチング (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] Farrel, A.、「ラベル配布プロトコル (LDP) のフォールト トレランス」、RFC 3479、2003 年 2 月。
[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] Bernstein, G.、Mannie, E.、および V. Sharma、「SDH/SONET ネットワークの GMPLS ベース制御のフレームワーク」、進行中。
Peter Ashwood-Smith Nortel P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
ピーター・アッシュウッド＝スミス・ノーテル P.O.Box 3511 Station C、オタワ、ON K1Y 4H7、カナダ
EMail: 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
Daniel O. Awduche Consult
ダニエル・O・オーデューシュ コンサルティング
EMail: awduche@awduche.com
Thomas D. Nadeau Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
Thomas D. Nadeau Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
EMail: tnadeau@cisco.com
Ayan Banerjee
Calient
5853 Rue Ferrari
San Jose, CA 95138, USA
EMail: abanerjee@calient.net
Lyndon Ong Ciena 10480 Ridgeview Ct Cupertino, CA 95014, USA
Lyndon Ong Ciena 10480 Ridgeview Ct Cupertino, CA 95014, USA
EMail: lyong@ciena.com
Debashis Basak Accelight 70 Abele Road, Bldg.1200 Bridgeville, PA 15017, USA
Debashis Basak Accelight 70 Abele Road、Bldg.1200 Bridgeville、PA 15017、USA
EMail: dbasak@accelight.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
Dimitri Papadimitriou Alcatel Francis Wellesplein、1 B-2018 アントワープ、ベルギー
EMail: dimitri.papadimitriou@alcatel.be
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA, 22102, USA
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA、22102、米国
EMail: lberger@movaz.com
Dimitrios Pendarakis Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
ディミトリオス・ペンダラキス・テリウム 2 Crescent Place, P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: dpendarakis@tellium.com
Greg Bernstein
Grotto
EMail: gregb@grotto-networking.com
Bala Rajagopalan Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Bala Rajagopalan Tellium 2 Crescent Place、P.O.Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: braja@tellium.com
Sudheer Dharanikota Consult
スディール ダラニコタ コンサルト
EMail: sudheer@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Yakov Rekhter Juniper 1194 N. Mathilda Ave. サニーベール、CA 94089、米国
EMail: yakov@juniper.net
John Drake Calient 5853 Rue Ferrari San Jose, CA 95138, USA
ジョン・ドレイク・カリエント 5853 Rue Ferrari San Jose, CA 95138, USA
EMail: jdrake@calient.net
Debanjan Saha Tellium 2 Crescent Place Oceanport, NJ 07757-0901, USA
Debanjan Saha Tellium 2 Crescent Place Oceanport、NJ 07757-0901、USA
EMail: dsaha@tellium.com
Yanhe Fan
Axiowave
200 Nickerson Road
Marlborough, MA 01752, USA
EMail: yfan@axiowave.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705, USA
ハル・サンディック・シェパード M.S.2401 Dakota Street ダーラム、NC 27705、米国
EMail: sandick@nc.rr.com
Don Fedyk Nortel 600 Technology Park Drive Billerica, MA 01821, USA
Don Fedyk Nortel 600 Technology Park Drive Billerica, MA 01821, USA
EMail: dwfedyk@nortelnetworks.com
Vishal Sharma Metanoia 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA
Vishal Sharma Metanoia 1600 Villa Street、Unit 352 Mountain View、CA 94041、USA
EMail: v.sharma@ieee.org
Gert Grammel Alcatel Lorenzstrasse, 10 70435 Stuttgart, Germany
Gert Grammel Alcatel Lorenzstrasse、10 70435 シュトゥットガルト、ドイツ
EMail: gert.grammel@alcatel.de
George Swallow Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
George Swallow Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
EMail: swallow@cisco.com
Dan Guo
Turin
1415 N. McDowell Blvd,
Petaluma, CA 95454, USA
EMail: dguo@turinnetworks.com
Z. Bo Tang Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z. Bo Tang Tellium 2 Crescent Place、私書箱Box 901 オーシャンポート、ニュージャージー州 07757-0901、米国
EMail: btang@tellium.com
Kireeti Kompella Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompella Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
EMail: kireeti@juniper.net
Jennifer Yates AT&T 180 Park Avenue Florham Park, NJ 07932, USA
ジェニファー・イェーツ AT&T 180 Park Avenue Florham Park, NJ 07932, USA
EMail: jyates@research.att.com
Alan Kullberg NetPlane 888 Washington St.Dedham, MA 02026, USA
Alan Kullberg NetPlane 888 Washington St.Dedham, MA 02026, USA
EMail: akullber@netplane.com
George R. Young Edgeflow 329 March Road Ottawa, Ontario, K2K 2E1, Canada
George R. Young Edgeflow 329 March Road Ottawa、オンタリオ、K2K 2E1、カナダ
EMail: george.young@edgeflow.com
Jonathan P. Lang
Rincon Networks
EMail: jplang@ieee.org
John Yu Hammerhead Systems 640 Clyde Court Mountain View, CA 94043, USA
John Yu Hammerhead Systems 640 Clyde Court Mountain View, CA 94043, USA
EMail: john@hammerheadsystems.com
Fong Liaw Solas Research Solas Research, LLC
フォン・リャウ ソラス・リサーチ Solas Research, LLC
EMail: fongliaw@yahoo.com
Alex Zinin Alcatel 1420 North McDowell Ave Petaluma, CA 94954, USA
Alex Zinin Alcatel 1420 North McDowell Ave Petaluma、CA 94954、USA
EMail: 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
Eric Mannie (コンサルタント) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium 電話: 32 2 648-5023 携帯電話: 32 (0)495-221775
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。