RFC3945 日本語訳
3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture.E. Mannie, Ed.. October 2004. (Format: TXT=166700 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Mannie, Ed. Request for Comments: 3945 October 2004 Category: Standards Track
ワーキンググループのE.マニー、エドをネットワークでつないでください。コメントのために以下を要求してください。 3945 2004年10月のカテゴリ: 標準化過程
Generalized Multi-Protocol Label Switching (GMPLS) Architecture
一般化されたマルチプロトコルラベルスイッチング(GMPLS)構造
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
将来のデータと送電網は、ダイナミックにリソースに食糧を供給して、保護と回復のテクニックを使用することでネットワークの生存性を提供するためにルータ、スイッチ、Dense Wavelength事業部Multiplexing(DWDM)システム、Add-低下Multiplexors(ADMs)、フォトニック十字接続(PXCs)、Generalized Multi-プロトコルLabel Switchingを使用する光学十字接続(OXCs)(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の焦点があります。 意志はその制御飛行機の両方のシグナリングとルーティング部分を含むことです。
Mannie Standards Track [Page 1] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[1ページ]。
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 頭文字語と略語。 . . . . . . . . . . . . . . . 4 1.2. 複数のタイプについて階層構造を切り換えて、進めること。 5 1.3. MPLS制御飛行機. . . . . . . . . . 7 1.4の拡大。 MPLS-Te.102へのGMPLSの主要な拡張子。 ルート設定とアドレシングはモデル化されます。 . . . . . . . . . . . . . . . . 11 2.1. PSCと非PSCのアドレシングは層にされます。 . . . . . . . . . 13 2.2. GMPLSスケーラビリティ増進。 . . . . . . . . . . . . 13 2.3. IPルーティング・プロトコル. . . . . . . . . 14 3へのTe拡大。 無数のリンク。 . . . . . . . . . . . . . . . . . . . . . . 15 3.1. 無数の推進隣接番組. . . . . . . . . . . 16 4。 バンドリング. . . . . . . . . . . . . . . . . . . . . . . . 16 4.1をリンクしてください。 バンドリングの制限。 . . . . . . . . . . . . . . . 17 4.2. バンドリング. . . . . . . . . . 17 4.3のために問題を発送します。 問題に合図します。 . . . . . . . . . . . . . . . 18 4.3.1. メカニズム1: 暗黙の指示。 . . . . . . . 18 4.3.2. メカニズム2: 番号付のインタフェースIDによる明白な指示。 . . . . . . . . . . . . . . . . . 19 4.3.3. メカニズム3: 無数のインタフェースIDによる明白な指示。 . . . . . . . . . . . . . . . . . 19 4.4. 無数の束ねられたリンク. . . . . . . . . . . . . . . . 19 4.5。 形成はリンク. . . . . . . . . . . . . . . . . 20 5を束ねました。 UNI. . . . . . . . . . . . . . . . . . 20 5.1との関係。 OIF UNI. . . . . . . . . . . . . 21 5.2との関係。 UNI. . . . . . . . . . . . . . 21 6の向こう側の可到達性。 管理. . . . . . . . . . . . . . . . . . . . . . . 22 6.1をリンクしてください。 チャンネルとコントロールチャンネル管理を監督してください。 . . . . 23 6.2. 特性の相関関係. . . . . . . . . . . . . . . 24 6.3をリンクしてください。 接続性検証をリンクしてください。 . . . . . . . . . . . . 24 6.4. 障害管理。 . . . . . . . . . . . . . . . . . . . 25 6.5. DWDMの光学回線システム(OLSs)のためのLMP。 . . . . . . . 26 7. シグナリング. . . . . . . . . . . . . . . . . . . . 27 7.1を一般化しました。 概観: LSP. . . . . . . . . . . . 29 7.2を要求する方法。 ラベル要求. . . . . . . . . . . . . . . 30 7.3を広めました。 Sonet/SDH交通パラメタ。 . . . . . . . . . . . . . 31 7.4. G.709交通パラメタ。 . . . . . . . . . . . . . . . 32 7.5. 帯域幅コード化。 . . . . . . . . . . . . . . . . . . 33 7.6. ラベル. . . . . . . . . . . . . . . . . . . 34 7.7を一般化しました。 周波数帯の切り換え。 . . . . . . . . . . . . . . . . . . 34 7.8. 上流のそばを提案をラベルしてください。 . . . . . . . . . . . 35 7.9. 制限を上流の.35 7.10でラベルしてください。 双方向のLSP。 . . . . . . . . . . . . . . . . . . 36 7.11. 双方向のLSP主張解決。 . . . . . . . 37 7.12. 失敗. . . . . . . . . . . . . 37 7.13の急速な通知。 保護. . . . . . . . . . . . . . . . . . . . 38 7.14をリンクしてください。 明白なルート設定と明白なラベルコントロール. . . . . . 39
Mannie Standards Track [Page 2] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[2ページ]。
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
7.15. 録音. . . . . . . . . . . . . . . . . . . . 40 7.16を発送してください。 LSP変更とLSPのコースを変更. . . . . . . . . . 40 7.17すること。 LSPの管理状態取り扱い。 . . . . . . . . . . 41 7.18. チャネルセパレーションを制御してください。 . . . . . . . . . . . . . . 42 8. (ファ). . . . . . . . . . . . . . . . . 43 8.1を隣接番組に送ります。 隣接番組を発送して、進めます。 . . . . . . . . . . 43 8.2. 局面. . . . . . . . . . . . . . . . . . . 44 8.3に合図します。 推進隣接番組. . . . . . . . . . 44 9をどっと落させています。 隣接番組. . . . . . . . . . . . . . 45 10を発送して、合図します。 飛行機欠点取り扱いを制御してください。 . . . . . . . . . . . . . . . . 46 11. LSP保護と王政復古。 . . . . . . . . . . . . . . . 47 11.1. ドメインと層. . . . 48 11.2の向こう側の保護増大。 P&Rリソースに対するサービスのマッピング。 . . . . . . . . . 49 11.3. P&Rメカニズムの特性. . . . 49 11.4の分類。 P&R. . . . . . . . . . . . . . . . 50 11.5の異なったステージ。 回復戦略. . . . . . . . . . . . . . . . . . 50 11.6。 回収機構: 保護は.51 11.7を計画します。 回収機構: 王政復古計画。 . . . . . . . 52 11.8. 図式選択評価基準. . . . . . . . . . . . . . . 53 12。 ネットワークマネージメント。 . . . . . . . . . . . . . . . . . . . . . 54 12.1. ネットワーク管理システム(NMS)。 . . . . . . . . . . . 55 12.2. 管理情報ベース(MIB).55 12.3。 ツール. . . . . . . . . . . . . . . . . . . . . . . . . 56 12.4。 複数の層. . . . . . . 56 13の間の欠点相関関係 セキュリティ問題. . . . . . . . . . . . . . . . . . . 57 14。 承認。 . . . . . . . . . . . . . . . . . . . . . . 58 15. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 58 15.1. 引用規格。 . . . . . . . . . . . . . . . . . 58 15.2. 有益な参照。 . . . . . . . . . . . . . . . . 59 16. 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . 63 17. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . 68 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 69
Mannie Standards Track [Page 3] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[3ページ]。
1. Introduction
1. 序論
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).
このドキュメントは、Multi-プロトコルLabel Switching(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ブロックを提示して、どうそれらを結合できるかを一緒に説明します。 対応するドキュメントで別棟ブロックの特定の細部を見つけることができます。
1.1. Acronyms & Abbreviations
1.1. 頭文字語と略語
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
規制ベースの規制ベースの最短パス最初の自律システムのDWDM高密度波長多重光通信ファ推進隣接番組BGPボーダ・ゲイトウェイ・プロトコルCR-自由民主党ルート設定自由民主党CSPF GMPLSが内部のマルチプロトコルラベルスイッチングのラベル分配プロトコルLMPリンクIGPゲートウェイプロトコル自由民主党管理プロトコルを広めたので
Mannie Standards Track [Page 4] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[4ページ]。
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
LSRラベル切り換えルータLSPが分類するLSAリンク州の広告は光学フォトニック経路の同期式光通信網同期STM(-N)の輸送モジュール(-N)STS(-N)同期輸送信号平らなN(Sonet)TDM時分割多重化Te MIB管理情報ベースMPLSマルチプロトコルラベルスイッチングNMSネットワーク管理システムOXC十字接続PXC十字接続RSVP資源予約プロトコルSDH同期デジタルハイアラーキSonet交通工学を切り換えました。
1.2. Multiple Types of Switching and Forwarding Hierarchies
1.2. 複数のタイプについて階層構造を切り換えて、進めること。
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)は複数のタイプの切り換え(すなわち、TDM、λ、およびファイバー(ポート)の切り換えのサポートの添加)を支持するという点において伝統的なMPLSと異なっています。 そして、切り換えの追加タイプのサポートが、伝統的なMPLSのあるベース機能を広げるようにGMPLSに追い立てた、いくつかの場合、機能性を加えるために。 これらの変化と追加は基本的なLSP資産に影響を与えます: ラベルがどう要求されていて、伝えられるか、そして、LSPsの単方向の自然、誤りがどう伝播されるか、そして、および情報はイングレスを同期させて、出口LSRsに備えました。
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]は、ラベルに基づくデータの推進を支持するために定義されました。 この構造では、パケットのヘッダー(パケット境界を認識できるLSRsのための)かセルヘッダー(セル境界を認識できるLSRsのための)のどちらかを処理できるのでパケットかセル境界、および(b)のどちらかを認識しながら、Label Switching Routers(LSRs)には(a)であることができる推進飛行機があると思われました。
The original MPLS architecture is here being extended to include LSRs whose forwarding plane recognizes neither packet, nor cell boundaries, and therefore, cannot forward data based on the information carried in either packet or cell headers. Specifically, such LSRs include devices where the switching decision is based on time slots, wavelengths, or physical ports. So, the new set of LSRs, or more precisely interfaces on these LSRs, can be subdivided into the following classes:
オリジナルのMPLS構造が推進飛行機がパケットもセル境界も認識しないLSRsを含むように広げられながら、ここにあります、そして、したがって、パケットかセルヘッダーのどちらかで運ばれた情報に基づくデータは転送できません。 明確に、そのようなLSRsは切り換え決定が時間帯、波長、または物理的なポートに基づいている装置を含んでいます。 それで、LSRsの新しいセット、または、より正確にこれらのLSRsの上のインタフェースを以下のクラスに細分できます:
Mannie Standards Track [Page 5] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[5ページ]。
1. Packet Switch Capable (PSC) interfaces:
1. パケットSwitch Capable(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. 層-2Switch Capable(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-LSRsの上の前進のデータがATM VPI/VCIに基礎づけたインタフェースを含んでいます。
3. Time-Division Multiplex Capable (TDM) interfaces:
3. 時間事業部Multiplex Capable(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.
スイッチデータが繰り返しているサイクルにデータの時間帯に基礎づけたインタフェース。 そのようなインタフェースに関する例はSDH Cross Sonet/接続している(XC)ではTerminal Multiplexer(TM)、またはAddがMultiplexer(ADM)を落とすということです。 他の例は能力(「デジタル包装紙」)をG.709 TDMに供給するインタフェースとPDHインタフェースを含んでいます。
4. Lambda Switch Capable (LSC) interfaces:
4. λSwitch Capable(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.
データを切り換えるインタフェースがデータが受信されている波長を基礎づけました。 そのようなインタフェースに関する例は個々の波長のレベルで作動できるPhotonic Cross接続しているか(PXC)、またはOptical Cross接続している(OXC)のものです。 追加例はすなわち、波長のグループ、周波数帯のレベルで作動できるPXCインタフェースを含んでいます、そして、G.709は光学能力を提供しながら、連結します。
5. Fiber-Switch Capable (FSC) interfaces:
5. ファイバースイッチCapable(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)を切り換えました。
Mannie Standards Track [Page 6] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[6ページ]。
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.
入れ子にされたLSP(LSPの中のLSP)の伝統的なMPLSで既に利用可能な概念は、推進階層構造(すなわち、LSPsの階層構造)を築き上げるのを容易にします。 LSPsのこの階層構造は同じインタフェースの上、または、異なったインタフェースの間に起こることができます。
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.
例えば、インタフェースが同じ技術(層)(例えばSonet/SDH LSP(例えば、VT2/VC-12)が、より高いオーダーSonet/SDH LSP(例えば、STS-3c/VC-4)で入れ子にした下層階級)から数個のLSPsを多重送信できるなら、階層構造を築き上げることができます。 信号(LSP)巣篭もりのいくつかのレベルがSonet/SDHマルチプレクシング階層構造で定義されます。
The nesting can also occur between interface types. At the top of the hierarchy are FSC interfaces, followed by LSC interfaces, followed by TDM interfaces, followed by L2SC, and followed by PSC interfaces. This way, an LSP that starts and ends on a PSC interface can be nested (together with other LSPs) into an LSP that starts and ends on a L2SC interface. This LSP, in turn, can be nested (together with other LSPs) into an LSP that starts and ends on a TDM interface. In turn, this LSP can be nested (together with other LSPs) into an LSP that starts and ends on a LSC interface, which in turn can be nested (together with other LSPs) into an LSP that starts and ends on a FSC interface.
また、巣篭もりはインターフェース型の間に起こることができます。 階層構造の最上部に、LSCインタフェースがあとに続いたインタフェースがL2SCによって続かれたTDMインタフェースのそばで続いて、PSCインタフェースで続いたFSCがあります。 この道、PSCインタフェースで始まって、終わるLSPはL2SCインタフェースで始まって、終わるLSPに入れ子にすることができます(他のLSPsと共に)。 順番にTDMインタフェースで始まって、終わるLSPにこのLSPを入れ子にすることができます(他のLSPsと共に)。 順番に、このLSPは始まるLSPに入れ子にすることができて(他のLSPsと共に)、LSCインタフェースで終わって、FSCインタフェースで終わります。(順番に、始まるLSPにそれを入れ子にすることができます(他のLSPsと共に))。
1.3. Extension of the MPLS Control Plane
1.3. MPLS制御飛行機の拡大
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.
その長さPacket Switch Capable(PSC)だけのLSPsかLayer-2 Switch Capable(L2SC)インタフェースの設立はオリジナルのMPLS、そして/または、MPLS-TE制御飛行機のために定義されます。 GMPLSは、前項で定義されたそれぞれの5つのクラスのインタフェース(すなわち、層)を支持するためにこれらの制御飛行機を広げています。
Note that the GMPLS control plane supports an overlay model, an augmented model, and a peer (integrated) model. In the near term, GMPLS appears to be very suitable for controlling each layer independently. This elegant approach will facilitate the future deployment of other models.
GMPLS制御飛行機がオーバレイモデル、増大しているモデル、および同輩(統合)モデルをサポートすることに注意してください。 近いうちに、GMPLSは、独自に各層を制御するのに非常に適当であるように見えます。 この上品なアプローチは他のモデルの今後の展開を容易にするでしょう。
The GMPLS control plane is made of several building blocks as described in more details in the following sections. These building blocks are based on well-known signaling and routing protocols that have been extended and/or modified to support GMPLS. They use IPv4 and/or IPv6 addresses. Only one new specialized protocol is required to support the operations of GMPLS, a signaling protocol for link management [LMP].
GMPLS制御飛行機はその他の詳細で以下のセクションで説明されるようにいくつかのブロックで作られています。 これらのブロックはGMPLSを支持するように広げられる、そして/または、変更された周知のシグナリングとルーティング・プロトコルに基づいています。 彼らはIPv4、そして/または、IPv6アドレスを使用します。 1つの新しい専門化しているプロトコルだけが、リンク管理[LMP]のためにGMPLSの操作、シグナリングプロトコルをサポートするのに必要です。
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
本当に、GMPLSはMPLS、通称MPLS-TE[RFC2702]へのTraffic Engineering(TE)拡張子に基づいています。 これPSCレベルの下に使用できる技術の大部分がいくつかが必要であることで、
Mannie Standards Track [Page 7] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[7ページ]。
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.
交通工学。 一般に、これらのレベルにおけるLSPsのプレースメントは、いくつかの規制(縁どり、帯域幅、保護能力などの)を考えて、遺産Shortest-経路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.
LSPsの抑制ベースのSPFルーティングを容易にするために、LSP設立を実行するノードはネットワークにおけるリンクの標準のイントラドメインルーティング・プロトコルが提供するより多くの情報を必要とします。 これらのTE属性は、IGPs(例えば、氾濫)で既に利用可能な移送機構を使用することで分配されて、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リンクが中の表現である、-、/OSPF Link州広告とリンクでは、ある物理資源に関するデータベース、および2つのGMPLSノードの間の彼らの特性を述べてください。 GMPLS制御飛行機(ルーティングとシグナリング)によってTEリンクスは、LSPsを設立するのに使用されます。
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)パラメタを輸送できなければなりません、特定のマルチプレックスなどにおける位置 これらの拡大の大部分はPSCとL2SC交通工学のためにMPLSと共に既に定義されました。 GMPLSは主としてTDM、LSC、およびFSC交通工学のための追加拡大を定義します。 ほんのわずかな要素は技術特有です。
Thus, GMPLS extends the two signaling protocols defined for MPLS-TE signaling, i.e., RSVP-TE [RFC3209] and CR-LDP [RFC3212]. However, GMPLS does not specify which one of these two signaling protocols must be used. It is the role of manufacturers and operators to evaluate the two possible solutions for their own interest.
したがって、GMPLSはすなわち、MPLS-TEシグナリング、RSVP-TE[RFC3209]のために定義された2つのシグナリングプロトコルとCR-自由民主党[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-自由民主党に基づいているので、川下要求次第のラベル配分と分配を強制します、イングレスの開始している命令されたコントロールで。 寛容なラベル保有は通常使用されましたが、また、保守的なラベル保有モードを使用できました。
Mannie Standards Track [Page 8] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[8ページ]。
Furthermore, there is no restriction on the label allocation strategy, it can be request/signaling driven (obvious for circuit switching technologies), traffic/data driven, or even topology driven. There is also no restriction on the route selection; explicit routing is normally used (strict or loose) but hop-by-hop routing could be used as well.
それは、その上、制限が全くラベル配分戦略にないか、(回線交換技術に明白)であるのに追い立てられた要求/シグナリング、追い立てられた交通/データ、または運転されたトポロジーでさえあるかもしれません。 また、ルート選択には制限が全くありません。 明白なルーティングは通常(厳しいかゆるい)で使用されましたが、また、ホップごとのルーティングを使用できました。
GMPLS also extends two traditional intra-domain link-state routing protocols already extended for TE purposes, i.e., OSPF-TE [OSPF-TE] and IS-IS-TE [ISIS-TE]. However, if explicit (source) routing is used, the routing algorithms used by these protocols no longer need to be standardized. Extensions for inter-domain routing (e.g., BGP) are for further study.
そして、また、GMPLSがすなわち、TE目的、OSPF-TE[OSPF-TE]のために既に広げられた2つの伝統的なイントラドメインLinkState方式プロトコルを広げている、TEである、[イシス-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(濃いWavelength事業部Multiplexing)のような技術の使用が、私たちが現在2つの直接隣接しているノードの間の非常に多くの平行なリンクを持つことができるのを含意する、(何百、波長の波長の、または、同等の数千が複数のファイバーであるなら使用されている、) そのような多くのリンクは元々IPかMPLS制御飛行機のために考えられませんでした、それができましたが。 GMPLS文脈でそれをよりよく再利用したいと思うなら、その制御飛行機のいくつかのわずかな適合がこのようにして必要です。
For instance, the traditional IP routing model assumes the establishment of a routing adjacency over each link connecting two adjacent nodes. Having such a large number of adjacencies does not scale well. Each node needs to maintain each of its adjacencies one by one, and link state routing information must be flooded throughout the network.
例えば、伝統的なIPルーティングモデルは、2つの隣接しているノードを接続しながら、各リンクの上にルーティング隣接番組の設立を仮定します。 そのような多くの隣接番組を持っているのはよく比例しません。 各ノードは、それぞれの隣接番組をひとつずつ維持する必要があります、そして、リンク州のルーティング情報はネットワーク中で水につかっているに違いありません。
To solve this issue the concept of link bundling was introduced. Moreover, the manual configuration and control of these links, even if they are unnumbered, becomes impractical. The Link Management Protocol (LMP) was specified to solve these issues.
この問題を解決するために、リンクバンドリングの概念は紹介されました。 そのうえ、それらが無数であっても、これらのリンクの手動の構成とコントロールは非実用的になります。 Link Managementプロトコル(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 Control Channel Maintenance)を維持して、データを持つリンク(リンクVerification)の物理的な接続性について確かめて、リンク特性の情報(リンクProperty Correlation)を関連させて、リンクの故障(欠点LocalizationとFault Notification)を管理するためにメカニズムを提供します。 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シグナリング仕様の如何にかかわらず指定されます。
Mannie Standards Track [Page 9] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[9ページ]。
Consequently, LMP can be used in other contexts with non-GMPLS signaling protocols.
その結果、他の文脈で非GMPLSシグナリングプロトコルでLMPを使用できます。
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.
2つの隣接しているノードが単方向のリンクによって接続されても、MPLSシグナリングとルーティング・プロトコルは、少なくとも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が、IPがそれらの上でシグナリングとルーティング・プロトコルを輸送するのをどう必要とするかをGMPLSは指定しません。 バンドかバンドの外のどちらかで制御チャンネルはそうであることができます、そして、IPを運ぶのにいくつかの解決策は使用できます。 1つのタイプに関するLMPメッセージ(Testメッセージ)が中古のデータのバンドの飛行機であり、IPの上で輸送されないかもしれないのにもかかわらずの、これが特定のそうであるというメモも、データ飛行機で接続性について確かめる必要がありました。
1.4. GMPLS Key Extensions to MPLS-TE
1.4. MPLS-TeへのGMPLSの主要な拡張子
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にもたらされたいくつかの主要な拡大が以下で強調されます。 それらのいくつかがGMPLSがTDM、LSC、およびFSC層を制御する主要な利点です。
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Mannie Standards Track [Page 10] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 10] RFC 3945 GMPLS Architecture October 2004
- 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 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 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 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.
- While traditional TE-based (and even LDP-based) LSPs are
unidirectional, GMPLS supports the establishment of bi-directional
LSPs.
- While traditional TE-based (and even LDP-based) LSPs are unidirectional, GMPLS supports the establishment of bi-directional LSPs.
- GMPLS supports the termination of an LSP on a specific egress
port, i.e., the port selection at the destination side.
- GMPLS supports the termination of an LSP on a specific egress port, i.e., the port selection at the destination side.
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid
failure notification.
- GMPLS with RSVP-TE supports an RSVP specific mechanism for rapid failure notification.
Note also some other key differences between MPLS-TE and GMPLS:
Note also some other key differences between MPLS-TE and GMPLS:
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP
can be performed only in discrete units.
- For TDM, LSC and FSC interfaces, bandwidth allocation for an LSP can be performed only in discrete units.
- 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.
- 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.
2. Routing and Addressing Model
2. Routing and Addressing Model
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 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.
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.
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.
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 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.
Mannie Standards Track [Page 11] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 11] RFC 3945 GMPLS Architecture October 2004
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.
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.
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).
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).
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.
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.
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.
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.
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.
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.
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.
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.
Note that traffic engineering in the intra-domain requires the use of link-state routing protocols like OSPF or IS-IS.
Note that traffic engineering in the intra-domain requires the use of link-state routing protocols like OSPF or 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
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
Mannie Standards Track [Page 12] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 12] RFC 3945 GMPLS Architecture October 2004
intra-area traffic engineering. However, inter-area traffic engineering is also under investigation.
intra-area traffic engineering. However, inter-area traffic engineering is also under investigation.
2.1. Addressing of PSC and non-PSC Layers
2.1. Addressing of PSC and non-PSC Layers
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.
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.
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.
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.
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.
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.
2.2. GMPLS Scalability Enhancements
2.2. GMPLS Scalability Enhancements
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 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.
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.
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.
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.
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.
Mannie Standards Track [Page 13] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 13] RFC 3945 GMPLS Architecture October 2004
2.3. TE Extensions to IP Routing Protocols
2.3. TE Extensions to IP Routing Protocols
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.
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.
However, GMPLS challenges this notion in three ways:
However, GMPLS challenges this notion in three ways:
- First, links that are non-PSC may yet have TE properties; however,
an OSPF adjacency could not be brought up directly on such links.
- First, links that are non-PSC may yet have TE properties; however, an OSPF adjacency could not be brought up directly on such links.
- 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.
- 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.
- 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.
- 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.
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.
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.
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.
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.
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.
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 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.
Mannie Standards Track [Page 14] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 14] RFC 3945 GMPLS Architecture October 2004
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".
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".
3. Unnumbered Links
3. Unnumbered Links
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.
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.
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. 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.
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]).
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]).
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.
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.
Mannie Standards Track [Page 15] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 15] RFC 3945 GMPLS Architecture October 2004
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.
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.
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.
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.
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. 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.
3.1. Unnumbered Forwarding Adjacencies
3.1. Unnumbered Forwarding Adjacencies
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.
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.
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.
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.
4. Link Bundling
4. Link Bundling
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.
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.
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).
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).
Mannie Standards Track [Page 16] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 16] RFC 3945 GMPLS Architecture October 2004
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.
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.
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.
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.
4.1. Restrictions on Bundling
4.1. Restrictions on Bundling
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:
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:
- 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).
- 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).
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.
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.
4.2. Routing Considerations for Bundling
4.2. Routing Considerations for Bundling
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.
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.
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.
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.
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.
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.
Mannie Standards Track [Page 17] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 17] RFC 3945 GMPLS Architecture October 2004
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).
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).
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.
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.
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.
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.
A GMPLS node with bundled links must apply admission control on a per-component link basis.
4.3. Signaling Considerations
4.3. Signaling Considerations
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.
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.
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.
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.
Three mechanisms for indicating this choice to the downstream node are possible.
Three mechanisms for indicating this choice to the downstream node are possible.
4.3.1. Mechanism 1: Implicit Indication
4.3.1. Mechanism 1: Implicit Indication
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.
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.
Mannie Standards Track [Page 18] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 18] RFC 3945 GMPLS Architecture October 2004
4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID
4.3.2. Mechanism 2: Explicit Indication by Numbered Interface ID
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.
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.
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.
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.
4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID
4.3.3. Mechanism 3: Explicit Indication by Unnumbered Interface ID
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).
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).
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.
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.
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.
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.
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.
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.
4.4. Unnumbered Bundled Link
4.4. Unnumbered Bundled Link
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.
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.
Mannie Standards Track [Page 19] RFC 3945 GMPLS Architecture October 2004
Mannie Standards Track [Page 19] RFC 3945 GMPLS Architecture October 2004
4.5. Forming Bundled Links
4.5. Forming Bundled Links
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.
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.
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).
例えば、コンポーネントリンクが関連するかもしれない最初の所有地はInterface Switching Capabilityであるかもしれません[GMPLS-ルート設定]、そして、2番目の特性はEncodingであるかもしれません[GMPLS-ルート設定]、そして、3番目の特性はAdministrative Weightであるかもしれません(かかる)、そして、4番目の特性はResource Classesであるかもしれません、そして、最終的にリンクはSRLG(共有されたRisk Link Groups)などの他の測定基準に基づいて関連するかもしれません。
When routing an alternate path for protection purposes, the general principle followed is that the alternate path is not routed over any link belonging to an SRLG that belongs to some link of the primary path. Thus, the rule to be followed is to group links belonging to exactly the same set of SRLGs.
保護目的のために代替パスを発送するとき、従われた一般的な原則は代替パスが第一の経路のあるリンクに属すSRLGに属しながらどんなリンクの上にも発送されないということです。 したがって、続くべき規則はSRLGsのまさに同じセットのものリンクを分類することです。
This type of sequential sub-division may result in a number of bundles between two adjacent nodes. In practice, however, the link properties may not be very heterogeneous among component links between two adjacent nodes. Thus, the number of bundles in practice may not be large.
このタイプの連続した下位区分は2つの隣接しているノードの間の多くのバンドルをもたらすかもしれません。 しかしながら、実際には、リンクの特性は2つの隣接しているノードの間のコンポーネントリンクの中でそれほど異種でないかもしれません。 したがって、実際にはバンドルの数は大きくないかもしれません。
5. Relationship with the UNI
5. UNIとの関係
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とのインタフェースはNetwork Interface(UNI)へのUserと呼ばれるかもしれません、2ネットワークのサイドLSRsの間のインタフェースがNetwork Interface(NNI)へのNetworkと呼ばれるかもしれませんが。
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を指定しません。 縁のノードはネットワーク側の上のLSRsに接続されます、そして、これらのLSRsは彼らの間で順番に接続されます。 もちろん、縁のノードの動きはまさにネットワーク側におけるLSRの動きと同じではありません。 しかしながら、縁のノードがルーティング・プロトコルを述べるかもしれなくて、場合の大部分では、そうしないのは予想されないという(また、明白なルートで合図することに関するセクション5.2とセクションを見てください)メモも。
Mannie Standards Track [Page 20] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[20ページ]。
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アプローチは1日目から一貫したモデルを造りながら、存しました、同時にUNIとNNIインタフェースの両方が[GMPLS-OVERLAY]であると考える場合。 そのために、ほんのわずかな特定のUNIの特性は最初の時代に無視されました。 GMPLSは、UNIである他の標準化本体でそのような特性を支持するために高められました(今後見てください)。
5.1. Relationship with the OIF UNI
5.1. OIF 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.709Digital Wrapperなどをカバーしていないので、その見解から、それはUNIのGMPLS Architectureの部分集合です。
5.2. Reachability across the UNI
5.2. UNIの向こう側の可到達性
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.
このセクションは縁のノードで明白なルートの選択について論じます。 複数のLSRsに接続された縁のノードによる最初の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
- 構成を基づかせました: このルーティングモデルは隣人LSRsのリストが好みの命令で分類されている縁のノードの手動の、または、自動である構成を必要とします。 例えばDHCPを使用することで自動構成を達成できます。 どんなルーティング情報もそうではありません。
Mannie Standards Track [Page 21] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[21ページ]。
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.
多分LSRsの規則正しいリストを除いて、UNIと交換します。 縁のノードによって使用される唯一のルーティング情報がそのリストです。 縁のノードはデフォルトでLSP要求を都合のよいLSRに送ります。 ICMPが向け直す、縁のノードに接続された別のLSRにいくつかのLSP要求を向け直すためにこのLSRで発信することであるかもしれません。 GMPLSはそのモデルを排除しません。
- Partial peering: limited routing information (mainly reachability)
can be exchanged across the UNI using some extensions in the
signaling plane. The reachability information exchanged at the
UNI may be used to initiate edge node specific routing decision
over the network. GMPLS does not have any capability to support
this model today.
- 部分的なじっと見ること: UNIの向こう側にシグナリング飛行機のいくつかの拡張子を使用することで限られたルーティング情報(主に可到達性)を交換できます。 UNIと交換された可到達性情報は、ネットワークの上の縁のノード特有のルーティング決定を開始するのに使用されるかもしれません。 GMPLSには、今日このモデルをサポートする少しの能力もありません。
- Silent listening: the edge node can silently listen to routing
protocols and take routing decisions based on the information
obtained. An edge node receives the full routing information,
including traffic engineering extensions. One LSR should forward
transparently all routing PDUs to the edge node. An edge node can
now compute a complete explicit route taking into consideration
all the end-to-end routing information. GMPLS does not preclude
this model.
- 静かな聴取: 縁のノードは、静かにルーティング・プロトコルを聞いて、情報に基づいた決定が得たルーティングを取ることができます。 縁のノードは交通工学拡大を含む完全なルーティング情報を受け取ります。 1LSRが透明にすべてのルーティングPDUsを縁のノードに送るはずです。 縁のノードは現在、終わりから終わりへのルーティングすべての情報を考慮に入れる完全な明白なルートを計算できます。 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.
- 完全なじっと見ること: 静かな聴取に加えて、縁のノードは、ルーティングの中で参加して、隣人と共に隣接番組を確立して、LSAsの広告を出します。 縁のノードが自分たちで交通の設計している情報の広告を出すように利益がある場合にだけ、これは役に立ちます。 GMPLSはこのモデルを排除しません。
6. Link Management
6. リンク管理
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の文脈では、1組のノード(例えば、光子スイッチ)は何十ものファイバーによって接続されるかもしれません、そして、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.
リンク管理はコントロールチャンネル管理や、リンク接続性検証や、リンク特性の相関関係や、障害管理などのローカル・サービスを備える隣接しているノードの間の役に立つ手順の収集です。 Link Managementプロトコル(LMP)[LMP]は、これらの操作を実現させるために定義されました。 LMPはGMPLSの文脈で開始されましたが、また、他の文脈で使用できる一般的な道具箱です。
Mannie Standards Track [Page 22] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[22ページ]。
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単位で義務的です。 リンク接続性検証と障害管理手順は任意です。
6.1. Control Channel and Control Channel Management
6.1. 制御チャンネルとコントロールチャンネル管理
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ビットの非ゼロ整数Control Channel Identifier(CCId)は制御チャンネルの各方向に割り当てられます。
Mannie Standards Track [Page 23] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[23ページ]。
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ハローズと関連リンク州の隣接番組は無益に取り除かれません。
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プロトコルは二相から成ります: 交渉フェーズとaはフェーズを生かします。 交渉フェーズは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コントロールチャンネルメッセージ(Configurationメッセージ、および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個の制御チャンネルがいつも利用可能であることは、不可欠です。 コントロールチャンネルの故障の場合には、コーディネートなしで交互の活発な制御チャンネルを使用するのは可能であるかもしれません。
6.2. Link Property Correlation
6.2. リンク特性の相関関係
As part of LMP, a link property correlation exchange is defined. The exchange is used to aggregate multiple data-bearing links (i.e., component links) into a bundled link and exchange, correlate, or change TE link parameters. The link property correlation exchange may be done at any time a link is up and not in the Verification process (see next section).
LMPの一部と、リンク特性の相関関係交換は定義されます。 交換は、束ねられたリンクと交換への複数のデータを持つリンク(すなわち、コンポーネントリンク)に集めるか、関連するか、またはTEリンクパラメータを変えるのに使用されます。 Verificationの過程ではなく、リンクが上がっている何時でもリンク特性の相関関係交換をするかもしれません(次のセクションを見てください)。
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.
それは例えば、リンクバンドルへのコンポーネントリンクの添加、リンクの最小の、または、最大の予約可能帯域幅の変化、ポート識別子の変化、またはバンドルにおける、コンポーネント識別子の変化を許容します。 このメカニズムはリンク概要メッセージの交換でサポートされます。
6.3. Link Connectivity Verification
6.3. リンク接続性検証
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シグナリングに使用されるリンク識別子を交換するのに用いられるかもしれない任意の手順です。
Mannie Standards Track [Page 24] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[24ページ]。
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.
検証手続はデータを持つリンクの上のバンドの送付Testメッセージから成ります。 これは、「非-割り当て」られたリンクが不透明であるに違いないことを必要とします。 しかしながら、複数の程度の不透明(例えば、ペイロードを終えて、オーバーヘッドバイトを調べますなど)、およびTestメッセージを輸送するしたがって、異なったメカニズムは指定されます。 Testメッセージがデータを持つリンクの上に送られる唯一のLMPメッセージであり、Helloメッセージが、リンク検証の過程の間、制御チャンネルの上と交換され続けていることに注意してください。 データを持つリンクがテストされる、それらが単方向ので、指示を伝えてください。 そういうものとして、LMPの隣接しているノードが同時にTestメッセージを両方の方向と交換するのは、可能です。
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.
リンク検証手続に着手するために、ノードは、最初に、特定のデータを持つリンクの上、または、特定の束ねられたリンクのコンポーネントリンクの上にメッセージをTestに送り始めるように隣接しているノードに通知しなければなりません。 また、ノードは確かめられることになっているデータを持つリンクの数を示さなければなりません。 テストメッセージが送られる間隔。 コード化計画、サポートされる移送機構、Testメッセージのためのデータ信号速度。 そして、データベアリングがリンクされる場合では、ファイバー(Testメッセージが送られる波長)に対応してください。 その上、地方の、そして、リモートな束ねられたリンク識別子は、このとき、束ねられたリンク識別子とのコンポーネントリンク協会を実行するために伝えられます。
6.4. Fault Management
6.4. 障害管理
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).
透明なフォトニック切り換えなどの新技術では、欠点の場所を見つけるように現在の方法を全く定義しません、そして、「バンド」(制御飛行機を通した)から欠点情報が伝播されるメカニズムを送らなければなりません。
Mannie Standards Track [Page 25] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[25ページ]。
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つのノードの間には、失敗があるかを決定するために対応する入力ポートで失敗を関連させることができます。 失敗がいったん局所化されると、リンクか経路保護/回復手順に着手するのにシグナリングプロトコルを使用できます。
6.5. LMP for DWDM Optical Line Systems (OLSs)
6.5. DWDMの光学回線システムのためのLMP(OLSs)
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)に焦点を合わせます。 2OXCsの間のリンクの多くの情報がOLS(光学線SystemかWDM Terminal回線多重化装置)によって知られています。 この情報を制御飛行機に露出すると、必要な手動の構成をさらに減少させて、欠点検出と回復を大いに機能アップすることによって、ネットワークユーザビリティを改良できます。
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]で説明されたOptical Link Interface Requirementsを満たすことを意図します。
Fault detection is particularly an issue when the network is using all-optical photonic switches (PXC). Once a connection is established, PXCs have only limited visibility into the health of the connection. Although the PXC is all-optical, long-haul OLSs typically terminate channels electrically and regenerate them optically. This provides an opportunity to monitor the health of a channel between PXCs. LMP-WDM can then be used by the OLS to provide this information to the PXC.
ネットワークがオール光学の光子スイッチ(PXC)を使用しているとき、欠点検出は特に問題です。 接続がいったん確立されると、PXCsは目に見えることを接続の健康に制限するだけでした。 PXCはオール光学ですが、長期OLSsは電気的にチャンネルを通常終えて、光学的に彼らを作り直します。 これはPXCsの間のチャンネルの健康をモニターする機会を提供します。 そして、OLSは、この情報をPXCに供給するのにLMP-WDMを使用できます。
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において知られているリンク情報に加えて、OLSと共にLMP-WDMを通してOXCにおいて知られている何らかの情報を交換するかもしれません。 この情報はアラーム管理とリンクモニター(例えば、跡のモニター)の役に立ちます。 アラーム管理は、偽物のアラームを抑圧するのにOXC(例えばこの情報はGMPLSシグナリング[RFC3471]のAdmin Status物を通して学習されるかもしれない)において知られている接続の管理状態を使用できるので、重要です。例えば、OXCは、接続が“up"であることを知るかもしれません、“down"、「テスト」モード、または削除される際に(「進行中の削除」)。 OXCは、アラームが接続が“down"であるときに、OLSから報告するか、「テストする」か、または削除されるのを禁止するのにこの情報を使用できます。
Mannie Standards Track [Page 26] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[26ページ]。
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が1OLSsと共にじっと見るかもしれないことに注意するのが重要であり、OLSは1OXCsと共にじっと見るかもしれません。 OXC-OXC LMPセッションとOXC-OLS LMPセッションの間には、多くの類似性がありますが、特にコントロール管理とリンク検証のために、また、いくつかの違いがあります。 主としてこれらの違いをOXC-OLSリンクの自然、およびOXC-OLS LMPセッションの目的の結果と考えることができます。 光学層でGMPLSシグナリングとルーティングの基礎を提供するのにOXC-OXCリンクを使用できます。 LMP-WDMセッションの間に交換された情報は、OXCsの間のリンクに関する知識を増大させるのに使用されます。
In order for the information exchanged over the OXC-OLS LMP sessions to be used by the OXC-OXC session, the information must be coordinated by the OXC. However, the OXC-OXC and OXC-OLS LMP sessions are run independently and must be maintained separately. One critical requirement when running an OXC-OLS LMP session is the ability of the OLS to make a data link transparent when not doing the verification procedure. This is because the same data link may be verified between OXC-OLS and between OXC-OXC. The verification procedure of LMP is used to coordinate the Test procedure (and hence the transparency/opaqueness of the data links). To maintain independence between the sessions, it must be possible for the LMP sessions to come up in any order. In particular, it must be possible for an OXC-OXC LMP session to come up without an OXC-OLS LMP session being brought up, and vice-versa.
OXC-OXCセッションで使用されるためにOXC-OLS LMPセッションの間に交換された情報において整然とします、OXCは情報を調整しなければなりません。 しかしながら、OXC-OXCとOXC-OLS LMPセッションを独自に走って、別々に維持しなければなりません。 OXC-OLS LMPセッションを走らせるとき、1つの批判的な要件が検証手続をしないときOLSがデータ・リンクを透明にする能力です。 これは同じデータ・リンクがOXC-OLSの間と、そして、OXC-OXCの間で確かめられるかもしれないからです。 LMPの検証手続は、Test手順を調整するのに使用されます(したがって、データの透明/不透明はリンクされます)。 セッションの間で独立を維持するために、LMPセッションが順不同に来るのは、可能でなければなりません。 OXC-OXC LMPセッションが持って来られるOXC-OLS LMPセッションなしで来るのが、特に、可能でなければならなく、逆もまた同様です。
7. Generalized Signaling
7. 一般化されたシグナリング
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-自由民主党シグナリングのあるベース機能を広げていて、いくつかの場合、機能性を加えます。 これらの変化と追加は基本的なLSP資産に影響を与えます: ラベルがどう要求されていて、伝えられるか、そして、LSPsの単方向の自然、誤りがどう伝播されるか、そして、および情報はイングレスを同期させて、出口に備えました。
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-自由民主党の拡大[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]を制御します。
Mannie Standards Track [Page 27] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[27ページ]。
The following MPLS profile expressed in terms of MPLS features [RFC3031] applies to GMPLS:
MPLSの特徴[RFC3031]で急送された以下のMPLSプロフィールはGMPLSに適用されます:
- Downstream-on-demand label allocation and distribution.
- 川下要求次第のラベル配分と分配。
- Ingress initiated ordered control.
- イングレスは命令されたコントロールを開始しました。
- Liberal (typical), or conservative (could) label retention mode.
- 寛容(典型的な)か、保守的な(could)ラベル保有モード。
- 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. Generalized Labelとして一般的に知られているTDM、LSC、およびFSCインタフェースへのラベル。 3. 周波数帯切り換えサポート。 4. 目的(例えば、潜在)と最適化のための上流のそばでの提案をラベルしてください。 5. 上流のそばを制限をラベルして、いくつかの光の規制を支持してください。 6. 主張解決による双方向のLSP設立。 7. 急速な失敗通知拡張子。 8. 現在リンク保護に焦点を合わせる保護情報、および第一の、そして、二次のLSP指示。 9. すばらしい統制度のための明白なラベルコントロールがある明白なルーティング。 10. 1技術あたりの特定の交通パラメタ。 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は任意です。
Mannie Standards Track [Page 28] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[28ページ]。
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.
典型的なMPLS-IPネットワークはこれらのブロックのいずれも実行しないでしょう、ブロック1の不在が通常のMPLS-IPを示すでしょう、したがって。 しかしながら、また、MPLS-IPに合図するのにブロック1と8を使用できることに注意してください。 その場合、MPLS-IPネットワークはリンク保護タイプ(CR-自由民主党、何らかの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を支持しなければならないRSVP-TEとCR-自由民主党の実現のための直接GMPLS手順に関連すること以外のどんなプロフィールも指定しません。 どれが実行される必要があるRSVP-TEとCR-自由民主党の随意的な要素と手順であるかを決めるために、メーカーにはそれがあります。 いくつかの任意のMPLS-TE要素が、TDMとLSCとFSC層、例えば、セットアップの役に立ってMPLS-TEから引き継がれるプライオリティを保つことができます。
7.1. Overview: How to Request an LSP
7.1. 概観: LSPを要求する方法
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/ラベルRequestメッセージを川下に送ることによって、目的地に設立されます。 このメッセージはLSP(すなわち、関する層)のタイプ、およびそのペイロードタイプがあるGeneralized Label Requestを含んでいます。 また、通常、Explicit Route Object(ERO)がメッセージに追加されますが、これは、第1/デフォルトの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-自由民主党Traffic Parameters 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).
1リンクあたりの要求された地方の保護は、Protection情報Object/TLVを使用することで要求されているかもしれません。 終わりから終わりへのLSP保護は、さらなる研究にはあって、導入されたLSP保護/回復部(後に、見る)です。
Mannie Standards Track [Page 29] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[29ページ]。
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であるなら、Upstream LabelはPath/ラベルRequestメッセージで指定されます。 このラベルは上流の方向に使用するものになるでしょう。
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.
また、さらに、メッセージにSuggested Label、Label Set、およびWaveband Labelを含むことができます。 他の操作は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.
川下のノードは数個のGeneralized Labelsを含むことができる1Generalized Label物/TLVを含むResv/ラベルMappingメッセージを返送するでしょう。 例えば、連結された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.
すなわち、SDH Sonet/「乗法」、同じLSPに属すタイプにもかかわらず、連結のない同じくらいにもかかわらず、すべてのサーキットの共同ルーティングの場合には、LSPに参加するすべての信号の明白な規則正しいリストを返します。
7.2. Generalized Label Request
7.2. 一般化されたラベル要求
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.
Generalized Label Requestは通常のLabel Requestの代わりにRSVP-TE Pathメッセージ、または既に既存のTLVsに加えたCR-自由民主党Requestメッセージで加えられるべき新しい物/TLVです。 メッセージ単位で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).
Generalized Label Requestは(パラメタ)が要求されているLSPを支持するのを必要とした3つの主要な特性を与えます: LSP Encoding Type、使用しなければならないSwitching Type、およびLSPペイロードタイプは、Generalized PIDを(G-PID)と呼びました。
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 Encoding TypeはLSPに関連しているデータと共に使用されるコード化しているタイプを示します、すなわち、考えられた技術のタイプ。 例えば、それはSDH、Sonet、イーサネット、ANSI PDHであるかもしれませんなど。 それはLSPが横断するリンクの自然ではなく、LSPの自然を表します。 これはホップごとに各ノードによって使用されます。
Mannie Standards Track [Page 30] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[30ページ]。
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つ以上に関する信号を運んで、切り換えることができることを意味します。 Switching Typeはその時、そのLSPのために特定のリンクに実行されるべきである切り換えのタイプを示します。 この情報が1つ以上のタイプのスイッチング能力の広告を出すリンクに必要です。
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.
ノードは、Switching Typeで示されたタイプが対応する入って来るインタフェースで支持されることを確かめなければなりません。 さもなければ、ノードは「ルート設定の問題/切り換えタイプ」指示で通知メッセージを発生させなければなりません。
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のクライアント層に関する識別子)によって運ばれたペイロードを特定します。 また、いくつかの技術のために、クライアント層によって使用されるマッピングを示して、例えば、バイトは1Eの同期マッピングです。 これは、タイプをコード化するLSPに従って解釈しなければならなくて、要求がどのクライアント層に運命づけられているかを知るLSPの終点のノード、およびいくつかの場合終わりから二番目のホップによって使用されます。
Other technology specific parameters are not transported in the Generalized Label Request but in technology specific traffic parameters as explained hereafter. Currently, two set of traffic parameters are defined, one for SONET/SDH and one for G.709.
他の技術の特定のパラメタはGeneralized Label Requestで輸送されるのではなく、今後説明されるように技術の特定の交通パラメタで輸送されます。 現在2セットの交通パラメタが定義されて、Sonetのための1つは、/SDHとG.709のためのものです。
Note that it is expected than specific traffic parameters will be defined in the future for photonic (all optical) switching.
それが特定の交通パラメタより予想されるというメモは将来、フォトニック(すべて光学の)の切り換えのために定義されるでしょう。
7.3. SONET/SDH Traffic Parameters
7.3. Sonet/SDH交通パラメタ
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、例えば、VC-11、VT6、VC-4、STS-3cなどを含む基本のSonet/SDH信号のタイプを指定します。 そして、相次ぐときにLSPのために実際に要求されている最終的な信号を組立てるためにいくつかの変換を基本のSignalに適用できます。
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.
- まず最初に、近接して連結された信号をもたらして、任意に隣接の連結をElementary Signalに適用できます。
Mannie Standards Track [Page 31] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[31ページ]。
- 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番目に、任意に基本のSignalの直接上、または、前のフェーズから入手された近接して連結された信号の上に仮想の連結を適用できます。
- 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番目に、任意に基本のSignalの直接上、または、第1段階から入手された近接して連結された信号の上、または、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-自由民主党に関しては、Sonet/SDH交通パラメタは新しいTLVで単に運ばれます。
Note that a general discussion on SONET/SDH and GMPLS can be found in [SONET-SDH-GMPLS-FRM].
[Sonet-SDH-GMPLS-FRM]でSonet/SDHとGMPLSについての一般的な議論を見つけることができることに注意してください。
7.4. G.709 Traffic Parameters
7.4. G.709交通パラメタ
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(光学Channel)の光学層においてODU(光学チャンネルData Unit)の電気層で。 ODUk記法は、異なった帯域幅でODUsを指示するのに使用されます。
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、例えば、ODU1、40GbpsのOChなどを含む基本のG.709信号のタイプを指定します。 そして、相次ぐときにLSPのために実際に要求されている最終的な信号を組立てるためにいくつかの変換を基本のSignalに適用できます。
Mannie Standards Track [Page 32] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[32ページ]。
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,
- まず最初に、任意に直接基本の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番目に、任意に基本のSignalの直接上、または、第1段階から入手された実際には連結された信号の上に乗法を適用できます。
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 Multiplexing交通パラメタで、LSPが要求するODUkマルチプレクシングのために(ODUkへのODUj)を写像するODUkを示します。 G.709は以下のマルチプレクシング能力を支持します: ODUk(k>j)へのODUjとODU2がODU3に多重送信しているODU1。
For RSVP-TE, the G.709 traffic parameters are carried in a new SENDER-TSPEC and FLOWSPEC. The same format is used for both. There is no Adspec associated with the SENDER_TSPEC, it is omitted or a default value is used. The content of the FLOWSPEC object received in a Resv message should be identical to the content of the SENDER_TSPEC of the corresponding Path message.
RSVP-TEに関しては、G.709交通パラメタは新しい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-自由民主党に関しては、G.709交通パラメタは新しいTLVで単に運ばれます。
7.5. Bandwidth Encoding
7.5. 帯域幅コード化
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.
特定の交通パラメタを持っていない(まだ)いくつかの技術がただコード化が一般的なフォームで輸送した帯域幅を必要とします。 帯域幅は32ビットの数でIEEEの浮動小数点の形式で運ばれます(ユニットは1秒あたりバイトです)。 値はプロトコルの特定の方法あたりのaで運ばれます。 非パケットLSPsに、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に適用されることに注意されるべきです。(交通パラメタは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.
帯域幅はRSVP-TEのためにCR-自由民主党Traffic Parameters TLVのSENDER_TSPECとFLOWSPEC物とPeakとCommitted Data Rate分野でInt-Serv物のPeak Data Rate分野でコード化されます。
Mannie Standards Track [Page 33] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[33ページ]。
7.6. Generalized Label
7.6. 一般化されたラベル
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.
例えば、Generalized Labelは波長(または、ファイバー)の中で(a) バンドルでの単一のファイバー、(b) ファイバーの中の単一の周波数帯、(c) 周波数帯(または、ファイバー)の中のただ一つの波長、または(d) 1セットの時間帯を特定するかもしれません。 また、それは、一般的なMPLSラベル、Frame Relayラベル、またはATMラベルであるかもしれません(VCI/VPI)。 ラベルの形式について、波長ラベルなどの整数値と同じくらい簡単であることができるか、またはSonet/SDHやG.709ラベルのようにさらに詳しく説明できます。
SDH and SONET define each a multiplexing structure. These multiplexing structures will be used as naming trees to create unique labels. Such a label will identify the exact position (times-lot(s)) of a signal in a multiplexing structure. Since the SONET multiplexing structure may be seen as a subset of the SDH multiplexing structure, the same format of label is used for SDH and SONET. A similar concept is applied to build a label at the G.709 ODU layer.
SDHとSonetはそれぞれマルチプレクシング構造を定義します。 これらのマルチプレクシング構造はユニークなラベルを作成するために木を命名するとして使用されるでしょう。 そのようなラベルは正確な位置を特定するでしょう。(マルチプレクシング構造の信号の回ロット(s))。 Sonetマルチプレクシング構造がSDHマルチプレクシング構造の部分集合と考えられるかもしれないので、ラベルの同じ形式はSDHとSonetに使用されます。 同様の概念は、G.709 ODU層にラベルを造るために適用されます。
Since the nodes sending and receiving the Generalized Label know what kinds of link they are using, the Generalized Label does not identify its type. Instead, the nodes are expected to know from the context what type of label to expect.
ノード送受信以来、Generalized Labelは、それらがどんな種類のリンクを使用しているかを知って、Generalized Labelはタイプを特定しません。 代わりに、ノードが、文脈からどんなタイプのラベルを予想するかを知っていると予想されます。
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.
Generalized Labelはただ一つのレベルのラベルを運ぶだけです、すなわち、それが非階層的です。 複数のレベルのラベル(LSPsの中のLSPs)が必要であるときに、別々に各LSPを設立しなければなりません。
7.7. Waveband Switching
7.7. 周波数帯の切り換え
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.
波長の切り換えの特別なケースは周波数帯の切り換えです。 周波数帯は1セットの隣接の波長を表します。(新しい周波数帯に波長を一緒に切り換えることができます)。 最適化理由で、フォトニック十字接続が光学的に複数の波長を一体にして切り換えるのは、望ましいかもしれません。 これは、個々の波長におけるひずみを減少させて、個々の波長の、よりきつい分離を許容するかもしれません。 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
周波数帯の切り換えは自然に別のレベルのラベル階層構造を紹介します、そして、そのような周波数帯が同じように扱われるとき、他のすべての上側の層のラベルが扱われます。 MPLSプロトコルに関する限り、周波数帯ラベルとaの間には、少しの違いがあります。
Mannie Standards Track [Page 34] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[34ページ]。
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.
波長ラベル。 例外は意味的に、周波数帯を波長に細分できるということですが、波長は時間まで細分しているか、または統計的に多重送信されたラベルであるにすぎないかもしれません。
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.
周波数帯の切り換えの文脈では、一般化されたラベルは、以前はよく周波数帯が3つの分野、周波数帯ID、Start Label、およびEnd Labelを含むのを示していました。 StartとEnd Labelsは送付者見解からのそれぞれ、最も低く周波数帯を作る値の波長と最も高い値の波長を特定するチャンネル識別子です。
7.8. Label Suggestion by the Upstream
7.8. 上流のそばでのラベル提案
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準備時間の費用で。 切り換え織物を構成する長い(電気用語による)遅れがあるかもしれないある種類の光学機器を通してLSPsを設立するとき、提案されたラベルは貴重です。 例えば、マイクロ鏡は、上げられなければならないか、または動かされなければならないかもしれません、そして、この物理的な動きの、そして、その後の湿気は時間がかかります。 ラベルとしたがって、切り替わっている織物が反対の方向(標準)に構成されるなら、Resv/MAPPINGメッセージは、使用可能な推進経路を確立するために10年代までに1ホップあたりのミリセカンドについて遅らせられる必要があるかもしれません。 LSPsが、ネットワーク失敗の結果、急速に設立される必要があるのは、回復目的のために交互であるところで重要である場合があります。
7.9. Label Restriction by the Upstream
7.9. 上流のそばでのラベル制限
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.
上流のノードは任意に川下のノードのラベルの選択を1セットの許容できるラベルに制限する場合があります(制限します)。 Label Setで包括的(許容できる)か排他的な(容認できない)ラベルのリスト、そして/または、範囲を与えると、この制限は提供されます。 適用されないなら、有効なラベル範囲からのすべてのラベルが使用されるかもしれません。 少なくとも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: リンクの2つの端が異なった波長を支持します。
Mannie Standards Track [Page 35] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[35ページ]。
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.
Label Setの受信機はラベルの選択をLabel Setにあるものに制限しなければなりません。 Label Setは複数のホップの向こう側に存在しているかもしれません。 この場合、各ノードはそれ自身の出発しているLabel Setを発生させます、ことによると入って来るLabel Setとノードのハードウェア能力に基づいて。 本件は変換の不可能なインタフェースがあるノードのための標準であると予想されます。
7.10. Bi-directional LSP
7.10. 双方向のLSP
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は双方向の左右対称のLSPs(非対称のLSPsでない)の設立を許容します。 左右対称の双方向のLSPには、各指示に運命共有、保護、回復、LSRs、およびリソース要件(例えば、潜在とジター)を含む同じ交通工学要件があります。
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の目標であるノードを参照するのに使用されます。 双方向のLSPsのために、1人の創始者と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-自由民主党[RFC3212]を使用するとき、双方向のLSPを証明するために、独自に2つの単方向の経路を確立しなければなりません。 このアプローチには、以下の損失があります:
1. The latency to establish the bi-directional LSP is equal to one
round trip signaling time plus one initiator-terminator signaling
transit delay. This not only extends the setup latency for
successful LSP establishment, but it extends the worst-case
latency for discovering an unsuccessful LSP to as much as two
times the initiator-terminator transit delay. These delays are
particularly significant for LSPs that are established for
restoration purposes.
1. 双方向のLSPを設立する潜在は、トランジット遅れに合図しながら、ある周遊旅行シグナリング時間と1つの創始者ターミネータと等しいです。 これはうまくいっているLSP設立のためにセットアップ潜在を広げるだけではありませんが、それは、創始者ターミネータトランジット遅れの最大2倍に失敗のLSPを発見するために最悪の場合潜在を広げています。 回復目的のために設立されるLSPsには、これらの遅れは特に重要です。
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. コントロールオーバーヘッドは単方向のものの2倍LSPです。 これは別々のコントロールメッセージ(例えば、PathとResv)が双方向のLSPの両方のセグメントのために発生しなければならないからです。
3. Because the resources are established in separate segments, route
selection is complicated. There is also additional potential race
for conditions in assignment of resources, which decreases the
overall probability of successfully establishing the bi-
directional connection.
3. リソースが別々のセグメントに確立されるので、ルート選択は複雑です。 また、リソースの課題には状態のための追加潜在的人種がいます。(それは、首尾よく両性愛者の方向の接続を確立するという総合的な確率を減少させます)。
Mannie Standards Track [Page 36] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[36ページ]。
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. 双方向の光学LSPs(または、lightpaths)は多くの光学ネットワークサービスプロバイダーのための要件と考えられます。
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.
双方向のLSPsと共に、両方の川下の、そして、上流のデータ経路は、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.
双方向のLSPsに関しては、2個のラベルを割り当てなければなりません。 両性愛者の方向のLSPセットアップは適切なシグナリングメッセージでのUpstream Labelの存在によって示されます。
7.11. Bi-directional LSP Contention Resolution
7.11. 双方向の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があるノードは主張を得るでしょう。 また、主張の確率を減少させるために、いくつかのメカニズムが示されます。
7.12. Rapid Notification of Failure
7.12. 失敗の急速な通知
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は失敗の速められた通知と失敗したLSPsを返すのに原因となるノード、およびエラー処理への他の出来事を可能にするいくつかのシグナリング拡大を定義します。
1. Acceptable Label Set for notification on Label Error:
1. Label Errorに関する通知のための許容できるLabel Set:
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は「許容できるラベル・セット」を通してそのような情報を伝える能力を導入します。 Acceptable Label Setは適切なプロトコル特定のエラーメッセージで運ばれます。 Acceptable Label Setの形式はLabel Setと同じです。
Mannie Standards Track [Page 37] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[37ページ]。
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-自由民主党のために、現在でないときに、同様のメカニズムがあります。 最初の拡大は、イベント通知がどこに送られるかことであることを特定します。 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メッセージは即座の上流の、または、川下の隣人以外のノードに「狙うことができる」という点において現在定義されたエラーメッセージと異なっている一般化された通知メカニズムです。 Notifyメッセージは既存のエラーメッセージを置き換えません。 (a) 通常、Notifyメッセージを送るかもしれません、非目標ノードがただNotifyメッセージを目標ノードに転送するところで、[RFC2205]でのResvConf処理と同様です。 または、(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メカニズムに対処するのに使用されます。
7.13. Link Protection
7.13. リンク保護
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.
保護情報は新しい任意のProtection情報Object/TLVで運ばれます。 それは現在、LSPの各リンクのための必要なリンク保護を示します。 1:Nは要求されて、当時のa接続要求です。特定の保護であるならすなわち、タイプしてください、1、+1、必要な保護タイプが光栄に思う場合がある場合にだけ、処理されます。 GMPLSがルーティング・プロトコルでリンクの保護能力の広告を出すことに注意してください。 LSPsをセットアップするために経路を計算するとき、経路計算アルゴリズムはこの情報を考えるかもしれません。
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の上で失敗するまで、それらは他のLSPsによって使用されるかもしれません。 その時、二次LSPにリソースを使用しているどんなLSPも先取りしなければなりません。
Mannie Standards Track [Page 38] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[38ページ]。
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.
6つのリンク保護タイプを現在、独特の旗と定義して、結合できます: +1(ひたむきな1:1)が共有した高められて、ひたむきな1、保護のなくて、余分な交通。 それぞれの厳密な定義に関して[RFC3471]セクション7.1を見てください。
7.14. Explicit Routing and Explicit Label Control
7.14. 明白なルート設定と明白なラベルコントロール
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のヘッド端のノードは、通常、明白なルートを見つけて、そのルートを含むExplicit Route Object(ERO)/明白なRoute(ER)TLVを造ります。 ことによると、縁のノードは、どんな明白なルートも造って、ただデフォルト隣人LSRにシグナリング要求を伝えません(IP/MPLSホストがそうするように)。 例えば、最初の切り換えノードで明白なルートをシグナリングメッセージに追加できました、縁のノードを代表して。 また、明白なルートが進行の間中間的LSRsによって目的地に向かって変更されることに注意してください。
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に続かなければなりません、それが使用されていることになっているリンクに関連しています。
Mannie Standards Track [Page 39] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[39ページ]。
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.
また、すなわち、2LSPsが最初のLSPのテールが第2LSPのヘッドに「継がれる」ところに一緒に「継ぐ」であることが望ましいときに、これを使用できます。
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.
最適化アルゴリズムと共に使用されると、非常に詳細な明白なルートを提供できます、リンクの上に使用するラベル(timeslot)を含んでいて、対応するインタフェースにおけるSonet/SDHマルチプレックスの断片化を最小にするために。
7.15. Route Recording
7.15. ルート録音
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構造の中では、TDM、LSC、およびFSC層に、2番目と3番目の機能だけが主に適切です。
7.16. LSP Modification and LSP Re-routing
7.16. LSP変更とLSPのコースを変更すること
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-自由民主党と共に支持されます(動作インディケータ旗を使用して)。
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
いくつかのLSPパラメタを変えますが、通常、ルートは変えないで、LSP変更が成ります。 それは、コースを変更するのと同じメカニズムを使用することで支持されます。 しかしながら、LSP変更の意味は1つの技術からもう片方まで異なるでしょう。 例えば、そして、さらに
Mannie Standards Track [Page 40] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[40ページ]。
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.
研究が、ダイナミックに帯域幅、保護タイプ、透明、連結などのいくつかのSonet/SDHサーキットの特性などを変える衝撃を理解するのに必要です。
7.17. LSP Administrative Status Handling
7.17. LSPの管理状態取り扱い
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は新しいAdmin Status物/TLVを使用することによってLSPの管理状態を示す任意の能力を提供します。 管理Status情報は現在、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/ラベルRequestかResv/ラベルMappingメッセージで運ばれます。 この用法で、Administrative Status情報はLSPの州を示します。(「テスト」モードで削除が進行しているかどうかにLSPはそれであるなら“up"か“down"を含んでいます)。
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が“down"にあるとき、報告するか、または州を「テストすること」を禁止するか、または優先における接続に関連しているアラームが「非サービス影響」より等しいか、または少ないと報告してください。
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に沿ったいくつかのノードがAdmin Status Object/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の管理状態を設定するのは役に立ちます。Path/ラベルRequest(変更する変更動作インディケータ旗のセットがある)メッセージに適切なAdmin Status Object/TLVを挿入することによって、イングレスLSRはLSP削除に先行します。 トランジットLSRsはAdmin Status Object/TLVを処理して、それを進めます。 出口LSRはResv/ラベルMapping(変更する変更動作インディケータ旗のセットがある)メッセージでAdmin Status物で答えます。 このメッセージと物を受け取ると、イングレスノードはLSPを取り外すためにPathTear/リリースメッセージを川下に送ります、そして、通常のRSVP-TE/CR-自由民主党の処理は行われます。
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番目の用法で、Admin Status物/TLVはイングレスノードがLSPの管理州を変えるよう要求するNotification/ラベルMapping(変更する変更動作インディケータ旗のセットがある)メッセージで運ばれます。 これは管理状態の設定の引き金となる中間介在物と出口ノードを許容します。 特に、これはイングレスノードによって開始されたLSPのリリースを要求する中間介在物か出口LSRsを許容します。
Mannie Standards Track [Page 41] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[41ページ]。
7.18. Control Channel Separation
7.18. コントロールチャネルセパレーション
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.
使用するデータインタフェースの選択は、いつもPath/ラベルRequestメッセージの送付者によって作られていて、メッセージに新しい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).
双方向のLSPsのために、送付者は各方向にデータインタフェースを選びます。 すべてのケースにもかかわらず、バンドリングでは、上流のインタフェースは川下のインタフェースによって含意されます。 バンドリングのために、Path/ラベルRequest送付者は明らかに各方向に使用されるコンポーネントインタフェースを特定します。 新しい物/TLVは川下のノードの示されたインタフェースの用法を示すResv/ラベル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は埋め込まれたTLVsのリストを含むことができます、そして、それぞれの埋め込まれたTLVはIPv4アドレスであるかもしれません、そして、IPv6アドレス、インタフェースインデックス、下流成分インタフェースIDまたは上流のコンポーネントがIDを連結します。 最後の3つの場合では、埋め込まれたTLV自身はIPアドレスとInterface ID(インタフェースID(例えば、それはルータIDであるかもしれない)を特定するのに使用されるIPアドレス)を含んでいます。
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.
ケースが誤りに関連している特定のインタフェースを示すのが役に立つところにあります。 これらのケースを支える、_ID ERROR_SPEC RSVP Objectsが定義されるなら。
Mannie Standards Track [Page 42] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[42ページ]。
8. Forwarding Adjacencies (FA)
8. 推進隣接番組(ファ)
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 LSPsに集めるのは役に立つかもしれません。 中間的ノードは外部のLSPだけを見ます。 彼らはそれぞれの内部のLSPのために推進州を維持する必要はありません、そして、より少ないシグナリングメッセージが、交換される必要があります、そして、代わりに(さらに)どうにか内部のLSPsに外部の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) LSRがそのLSPから推進隣接番組を形成して(Traffic Engineering(TE)としてのこのLSPがリンクする広告、-、/OSPF)、他のLSRsが彼らの経路計算のための推進隣接番組、およびLSPsの(d)巣篭もりを使用できる(c)は他のLSRsでその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.
ちょうどいかなる他のリンクの情報もあふれさせるようにイシス/OSPFは「推進隣接番組」FAsの情報をあふれさせます。 その結果この氾濫するのに、LSRはTEリンク州のデータベースに従来のリンクだけではなく、また、FAsの情報を持っています。
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は従来のリンクだけではなく、また、FAsも使用します。 経路がいったん計算されると、LSRは、経路に沿ってラベル結合を確立するのにRSVP- TE/CR-自由民主党を使用します。 FAsはシグナリングとルーティング・プロトコルに単純拡大を必要とします。
8.1. Routing and Forwarding Adjacencies
8.1. ルート設定と隣接番組を進めること。
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つのノードの間のLSPsのバンドルであるかもしれません。
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.
GMPLS TEが[HIERARCHY]で定義されるようにリンクするとき、FAsの広告を出します。 そして、OSPFにGMPLS TEリンクの広告を出す、-、[OSPF-TE-GMPLS]と[イシス-TE-GMPLS]で定義されるように。 これらの最後の2つの仕様が[OSPF-TE]とベースのTEリンクを定義する[イシス-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-LSPに利用可能であるなら、FAの帯域幅がそれを引き起こしていますが、より大きいかもしれないFA-LSPと少なくとも同じくらい大きいに違いないことに注意してください。 一般に、ダイナミックに食糧を供給された推進隣接番組において、方針ベースのメカニズムが、推進隣接番組に属性を関連づけるのに必要であるかもしれません。
Mannie Standards Track [Page 43] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[43ページ]。
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によって取られた経路の情報を含むかもしれません。 他のLSRsは経路計算にこの情報を使用するかもしれません。 そして、この情報が新しいOSPFで運ばれる、-、IS TLV、Path 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.
推進隣接番組が束ねられて(リンクバンドリングを通した)、結果として起こる束ねられたリンクがPath TLVを運ぶなら、コンポーネントリンクを形成するそれぞれのFA-LSPsによって続かれた基本的な経路は同じであるに違いありません。
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.
推進隣接番組が設立に使用されないと予想される、-、隣接番組の終わりのルータの/OSPFじっと見関係。
LSP hierarchy could exist both with the peer and with the overlay models. With the peer model, the LSP hierarchy is realized via FAs and an LSP is both created and used as a TE link by exactly the same instance of the control plane. Creating LSP hierarchies with overlays does not involve the concept of FA. With the overlay model an LSP created (and maintained) by one instance of the GMPLS control plane is used as a TE link by another instance of the GMPLS control plane. Moreover, the nodes using a TE link are expected to have a routing and signaling adjacency.
LSP階層構造は同輩とオーバレイモデルと共に存在できました。 同輩モデルと共に、LSP階層構造がFAsを通して実現されて、LSPはTEリンクとして制御飛行機のまさに同じ例によって作成されて、使用されます。 オーバレイでLSP階層構造を作成する場合、FAの概念はかかわりません。 オーバレイモデルと共に、GMPLS制御飛行機の1つの例によって作成された(そして、維持されます)LSPはTEリンクとしてGMPLS制御飛行機の別の例によって使用されます。 そのうえ、TEリンクを使用するノードがルーティングとシグナリング隣接番組を持っていると予想されます。
8.2. Signaling Aspects
8.2. シグナリング局面
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に関するPath/要求メッセージで明白なルートを処理する目的のために、FA-LSPのギヤエンドのLSRはそのFA-LSPのテールで隣接していた状態で(遠くの1つのIPホップ)LSRを見ます。
8.3. Cascading of Forwarding Adjacencies
8.3. 推進隣接番組の滝
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、-、サブTLVはそれぞれのインタフェースのマルチプレクシング能力の広告を出すために定義されました: PSC、L2SC、TDM、LSCまたはFSC。 このサブTLVはInterface Switching Capability DescriptorサブTLVと呼ばれます。(TLVは中で定義されたサブTLVsの補足となります)。
Mannie Standards Track [Page 44] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[44ページ]。
[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]と[イシス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の設立の引き金となることができます。 これは以下の明白なオーダーによる層の間のFAsの滝の引き金となることができます: L2SC、次に、TDM、次に、LSC、およびそして、最終的にFSC。
9. Routing and Signaling Adjacencies
9. ルート設定と隣接番組に合図すること。
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)隣接番組が彼らが中の隣人であるならある、-、/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-自由民主党)隣接番組が彼らがRSVP-TE/CR-自由民主党意味で隣人であるならあります。 彼らが直接、RSVP-TEメッセージ(経路/Resv)を交換するなら(例えば、セクション7.1.1と7.1で.2[HIERARCHY]について説明するので)、ノードAとBはRSVP-TE隣接物です。 隣人関係は、RSVP-TEハローズを交換するのを含んでいます。
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.
定義上、Forwarding Adjacency(FA)は経路が(G)MPLS制御飛行機の同じ例で他の1つ以上の(G)MPLSノードを通過する2つのGMPLSノードの間のTE Linkです。 それらの間には、2つのノードに1つの、または、より多くのより非FA TEのリンクスがいるなら、これらの2つのノードにルーティング隣接番組があると予想されます(必要ではありませんが)。 それらの間には、2つのノードに非FA TEリンクスが少しのいないなら、これらの2つのノードにルーティング隣接番組がないと予想されます(必要ではありませんが)。 当然のことを言うために、2つのノードの間のTEリンクがLSPsを設立するのに使用されるつもりであるなら、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 Linkであるかもしれません、IPリンクに似ている何でも。(例えば、GREがトンネルを堀る、(双方向)のLSP、PSCのインタフェーススイッチング能力があるそれ)
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
TEリンクは、直接ルーティング、そして/または、シグナリング隣接番組を維持するのに使用できないかもしれません。 これが隣接番組を発送して、合図するGMPLSが、フレーム/パケット基礎あたりのaとデータを交換するのを必要とするからであるTEリンク(例えば、OXCsの間のリンク)はパケット基礎あたりのaとデータを交換できないかもしれません。 この場合
Mannie Standards Track [Page 45] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[45ページ]。
routing and signaling adjacencies are maintained via a set of one or more control channels (see [LMP]).
ルーティングと隣接番組に合図するのは1個以上の制御チャンネルのセットを通して維持されます([LMP]を見てください)。
Two nodes may have a TE link between them even if they do not have a routing adjacency. Naturally, each node must run OSPF/IS-IS with GMPLS extensions in order for that TE link to be advertised. More precisely, the node needs to run GMPLS extensions for TE Links with an interface switching capability (see [GMPLS-ROUTING]) other than PSC. Moreover, this node needs to run either GMPLS or MPLS extensions for TE links with an interface switching capability of PSC.
2つのノードで、それらにルーティング隣接番組がなくても、TEはそれらの間でリンクするかもしれません。 当然、各ノードがOSPF/を走らせなければならない、-、GMPLSに、そのTEにおいて、整然としている拡大は、広告を出すためにリンクされます。 より正確に、ノードは、PSCを除いて、インタフェースが能力を切り換えていて([GMPLS-ルート設定]を見ます)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.
Control Channel Separation[RFC3471]のためのメカニズムは使用されるべきです(2つのノードの間のIP経路がTEリンクであっても)。 すなわち、RSVP-TE/CR-自由民主党シグナリングは、LSPを設立するとき、特定のTEリンクを指定するのにInterface_ID(_IDであるなら)物を使用するべきです。
The IP path could consist of multiple IP hops. In this case, the mechanisms of sections 7.1.1 and 7.1.2 of [HIERARCHY] should be used (in addition to Control Channel Separation).
IP経路は複数のIPホップから成ることができました。 この場合メカニズム、セクション7.1 .1と7.1では、.2[HIERARCHY]が使用されるべきです(Control Channel Separationに加えて)。
10. Control Plane Fault Handling
10. コントロール飛行機欠点取り扱い
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.
コントロールチャンネル欠点によって、コミュニケーションがいったん回復すると、ルーティング・プロトコルは自然に回復できますが、基本的なシグナリングプロトコルは、ノードが失敗を通してそれらの状態を維持したのを示さなければなりません。 また、シグナリングプロトコルは、失敗の間に例示されたどんな州の変化もノードの間で連動するのを確実にしなければなりません。
Mannie Standards Track [Page 46] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[46ページ]。
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]、および[イシス-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.
自由民主党Fault寛容([RFC3479]を見る)は、コントロールチャンネルの故障から回復するために手順を指定します。 [RFC3473]はコントロールチャンネルの故障とノード障害を両方から取り戻す方法を指定します。
11. LSP Protection and Restoration
11. LSP保護と王政復古
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 LSPsのためにProtectionと王政復古(P&R)問題について論じます。 それは[RFC3386]に概説された要件と[RFC3469]に概説された原則のいくつかによって運転されます。 より多くのGMPLS P&Rメカニズムが定義されるとき、それは高められるでしょう。 このセクションの範囲は今後はっきりさせられます:
- This section is only applicable when a fault impacting LSP(s)
happens in the data/transport plane. Section 10 deals with
control plane fault handling for nodal and control channel faults.
- LSP(s)に影響を与える欠点がデータ/輸送機で起こるときだけ、このセクションは適切です。 セクション10はこぶのよう、そして、コントロールチャンネル欠点のためのコントロール飛行機欠点取り扱いに対処します。
- This section focuses on P&R at the TDM, LSC and FSC layers. There
are specific P&R requirements at these layers not present at the
PSC layer.
- このセクションはTDM、LSC、およびFSC層でP&Rに焦点を合わせます。 特定のP&R要件がPSC層の現在でないこれらの層にあります。
- This section focuses on intra-area P&R as opposed to inter-area
P&R and even inter-domain P&R. Note that P&R can even be more
restricted, e.g., to a collection of like customer equipment, or a
collection of equipment of like capabilities, in one single
routing area.
- このセクションは相互領域P&Rと相互ドメインP&Rと対照的にさえイントラ領域P&Rに焦点を合わせます。 P&Rがさらに制限さえされる場合があることに例えば、あるただ一つのルーティング領域での同様の顧客設備の収集、または同様の能力の設備の収集に注意してください。
- This section focuses on intra-layer P&R (horizontal hierarchy as
defined in [RFC3386]) as opposed to the inter-layer P&R (vertical
hierarchy).
- このセクションは相互層のP&R(垂直的階層組織)と対照的にイントラ層のP&R([RFC3386]で定義される水平な階層構造)に焦点を合わせます。
- P&R mechanisms are in general designed to handle single failures,
which makes SRLG diversity a necessity. Recovery from multiple
failures requires further study.
- 一般に、P&Rメカニズムは、ただ一つの失敗を扱うように設計されています(SRLGの多様性を必要性にします)。 複数の失敗からの回復はさらなる研究を必要とします。
- Both mesh and ring-like topologies are supported.
- メッシュとリングのようなtopologiesの両方が支持されます。
Mannie Standards Track [Page 47] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[47ページ]。
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.
- 回復リソースにおける送付の先取り可能余分な交通はオペレータにとって、貴重な特徴です。
11.1. Protection Escalation across Domains and Layers
11.1. ドメインと層の向こう側の保護増大
To describe the P&R architecture, one must consider two dimensions of hierarchy [RFC3386]:
P&R構造について説明するために、階層構造[RFC3386]の二次元を考えなければなりません:
- A horizontal hierarchy consisting of multiple P&R domains, which
is important in an LSP based protection scheme. The scope of P&R
may extend over a link (or span), an administrative domain or
sub-network, an entire LSP.
- 複数の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道、lightpaths、ファイバーなど)で複数の層の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階層構造の中で1つのレベルから次まで伝播されるかもしれません。 それは「衝突」に通じることができます、そして、同時の回復動作は競合条件、減少しているリソース利用、または不安定性[マンチェスター]につながるかもしれません。 したがって、一貫した増大戦略が、ドメインと層の向こう側に回復を調整するのに必要です。 異なった層で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
2つのタイプの増大戦略があります: ボトムアップと先端ダウンしてください。 ボトムアップ・アプローチは、「低レベル」回復計画が、より好都合であると仮定します。 したがって、私たちは、禁止できるか、または距離を保ちます。
Mannie Standards Track [Page 48] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[48ページ]。
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.
よりハイレベルのP&R。 「下のレベル」P&Rを呼び出す前に、下にTopアプローチは、より高いレベルでサービスP&Rを試みます。 より高い層のP&Rは、サービス選択していて、「CoS」か"LSP"あたりの再ルーティングを可能にします。
Service Level Agreements (SLAs) between network operators and their clients are needed to determine the necessary time scales for P&R at each layer and at each domain.
ネットワーク・オペレータと彼らのクライアントの間のサービス・レベル・アグリーメント(SLA)が、P&Rのために各層において各ドメインで必要なタイムスケールを測定するのに必要です。
11.2. Mapping of Services to P&R Resources
11.2. P&Rリソースに対するサービスのマッピング
The choice of a P&R scheme is a tradeoff between network utilization (cost) and service interruption time. In light of this tradeoff, network service providers are expected to support a range of different service offerings or service levels.
P&R体系の選択はネットワーク利用(費用)と停電時間の間の見返りです。 この見返りの観点から、ネットワークサービスプロバイダーが、さまざまな異なったサービスが提供かサービスレベルであるとサポートすると予想されます。
One can classify LSPs into one of a small set of service levels. Among other things, these service levels define the reliability characteristics of the LSP. The service level associated with a given LSP is mapped to one or more P&R schemes during LSP establishment. An advantage that mapping is that an LSP may use different P&E schemes in different segments of a network (e.g., some links may be span protected, whilst other segments of the LSP may utilize ring protection). These details are likely to be service provider specific.
人はLSPsを小さいサービスレベルの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は計画される)の選択は異なったアプリケーションに関するサービス要件によって書き取られるべきです。
11.3. Classification of P&R Mechanism Characteristics
11.3. 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.
以下の図は、回復LSPs、およびそれらに、可能なオーバーブッキングのレベルのタイプに食糧を供給しながら、可能の分類を提供します。
Mannie Standards Track [Page 49] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[49ページ]。
+-Computed on +-Established +-Resources pre-
| demand | on demand | allocated
| | |
Recovery LSP | | |
Provisioning -+-Pre computed +-Pre established +-Resources allocated
on demand
+で+で確立した+リソースで計算される、プレ| 要求| 要求に関して| 割り当てます。| | | 回復LSP| | | +に食糧を供給して前計算される、+、-、前、確立した+リソースは要求に応じて割り当てました。
+--- Dedicated (1:1, 1+1)
|
|
+--- Shared (1:N, Ring, Shared mesh)
|
Level of |
Overbooking ---+--- Best effort
+--- ひたむきである、(1:1 1 +1)| | +--- 共有されます(1:N、Ring、Sharedメッシュ)。| 平ら| オーバーブッキング---+--- ベストエフォート型
11.4. Different Stages in P&R
11.4. P&Rの異なったステージ
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]で議論するようにいくつかの段階に起こります、トラフィック(すなわち、オリジナルの働くLSP、または、新しいものにトラフィックを返す)の欠点検出、欠点ローカライズ、通知、回復(すなわち、P&R自体)、および逆戻りを含んでいて。
- 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(LOL))によって失敗は検出されます。 ノードが失敗を検出すると、アラームがGMPLS実体まで渡されるかもしれませんか、またはアラームは下層(例えば、Sonet/SDH AIS)で伝播されるかもしれません。(実体は適切な行動を取るでしょう)。
- Fault localization can be done with the help of GMPLS, e.g., using
LMP for fault localization (see section 6.4).
- 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を通して欠点通知を達成できて、例えば、使用はGMPLS RSVP-TE/CR-自由民主党の通知(セクション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.
- 欠点検出、ローカライズ、および通知がいったん行われると、このセクションはトラフィックの回復と逆戻りに利用可能な異なったメカニズムに焦点を合わせます。
11.5. Recovery Strategies
11.5. 回復戦略
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と王政復古に分割できます。 保護に、保護終点の間のリソースは失敗の前に確立されました、そして、失敗が単に切り替わることによって達成された後に、接続性は保護エンドポイントで働きました。 対照的に、回復は回復経路に沿ってリソースを割り当てないことの後にシグナリングを使用します。
Mannie Standards Track [Page 50] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[50ページ]。
- 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.
これらの戦略を使用して、以下の回収機構を定義できます。
11.6. Recovery mechanisms: Protection schemes
11.6. 回収機構: 保護体系
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つのバックアップ)を扱って、保護するのはあらかじめ食糧を供給されます。 働くリソースが失敗するなら、データは保護リソースに切り換えられます、コーディネートメカニズム(例えば、オーバーヘッドバイトにおける)を使用して。 より一般に、Mのためにリソースを保護するN働きと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+1LSP保護: LSPsと末端選択を扱って、保護するときの同時のデータ伝送を適用できます(また[GMPLS-FUNCT]、見ます)。
Mannie Standards Track [Page 51] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[51ページ]。
11.7. Recovery mechanisms: Restoration schemes
11.7. 回収機構: 王政復古体系
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設立の間の)の後にダイナミックに計算されるかもしれません。 重要に、失敗にもかかわらず、どんな回復帯域幅も予約されていない前に合図は回復経路に沿って使用されません。 その結果、失敗が起こるとき、与えられた回復経路が利用可能であるという保証が全くありません。 したがって、1は利用可能な経路を捜し求めるcrankbackにそうしたかもしれません。
- 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.
回復経路の各リンクの上に予約されたリソースは同時に失敗しないと予想される異なった働くLSPsの向こう側に共有されるかもしれません。 容量が独立している失敗の向こう側に共有される度合いを定義するためにローカルのノード方針を適用できます。 失敗検出のときに、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.
各リンクの上に予約されたリソースは同時に失敗しないと予想される異なった働くLSPsの向こう側に共有されるかもしれません。 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回復: 終わらせる終わりよりむしろ地方ベースで上のアプローチを適用できます、回復時間(注意: 公表時に利用可能な参照がない)を短縮するために。
Mannie Standards Track [Page 52] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[52ページ]。
11.8. Schema Selection Criteria
11.8. 図式選択評価基準
This section discusses criteria that could be used by the operator in order to make a choice among the various P&R mechanisms.
このセクションはオペレータが様々なP&Rメカニズムの中で選択をするのに使用できた評価基準について論じます。
- Robustness: In general, the less pre-planning of the restoration
path, the more robust the restoration scheme is to a variety of
failures, provided that adequate resources are available.
Restoration schemes with pre-planned paths will not be able to
recover from network failures that simultaneously affect both the
working and restoration paths. Thus, these paths should ideally
be chosen to be as disjoint as possible (i.e., SRLG and node
disjoint), so that any single failure event will not affect both
paths. The risk of simultaneous failure of the two paths can be
reduced by recalculating the restoration path whenever a failure
occurs along it.
- 丈夫さ: 一般に、さまざまな失敗には回復経路では、回復体系が強健であれば強健であるほど、あらかじめ計画していないのがあります、適切なリソースが利用可能であれば。 あらかじめ計画された経路がある王政復古体系は同時に働きと回復経路の両方に影響するネットワーク失敗から回復できないでしょう。 したがって、これらの経路はばらばらになるようにあるように可能であるとして理想的に選ばれるべきです(すなわち、SRLGとノードはばらばらになります)、どんなただ一つの失敗イベントも両方の経路に影響しないように。 2つの経路の同時の失敗の危険は、失敗がそれに沿って起こるときはいつも、回復経路について再計算することによって、減少できます。
The pre-selection of a label gives less flexibility for multiple
failure scenarios than no label pre-selection. If failures occur
that affect two LSPs that are sharing a label at a common node
along their restoration routes, then only one of these LSPs can be
recovered, unless the label assignment is changed.
ラベルの前選択は複数の失敗シナリオのための柔軟性よりラベルなし前選択を与えます。 彼らの回復ルートに沿って一般的なノードでラベルを共有している2LSPsに影響する失敗が起こるなら、これらのLSPsの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体系は、より急速です。 一般に、保護体系は復元模型が計画されるより速く回復します。 あらかじめ合図された帯域幅の予約がある王政復古が再の食糧を供給するのによる経路回復より速いのと、特にどんなcrankbackの除去のためにもありそうです(かなり)。 一般に、地方の回復は終わりまでの終わりの体系よりさらに速くなるでしょう。
Mannie Standards Track [Page 53] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[53ページ]。
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保護の切り換え(失敗を検出する時間を含んでいない)のための目標復旧時間が50msの[ITUT-G.841]で指定されて、距離で規制を考慮に入れて、ポートの数は、保護(リングでのノードの数)にかかわって、リングに関するケース機能アップしました。
Recovery time objectives for restoration mechanisms are being
defined through a separate effort [RFC3386].
回復メカニズムのための目標復旧時間は別々の取り組み[RFC3386]を通して定義されています。
- Resource Sharing: 1+1 and 1:N link and LSP protection require
dedicated recovery paths with limited ability to share resources:
1+1 allows no sharing, 1:N allows some sharing of protection
resources and support of extra (pre-emptable) traffic.
Flexibility is limited because of topology restrictions, e.g.,
fixed ring topology for traditional enhanced protection schemes.
- リソース・シェアリング: +1と1:Nがリンクする1と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.
回復体系が複数の独立している失敗の中で共有するのを許容する度合いは回復プールのサイズによって直接書き取られます。 再の食糧を供給するのがある回復体系では、すべての回復ルートが失敗の後に選択される回復容量のプールを定義できます。 したがって、共有の度合いは有効な回復容量の量によって定義されます。 あらかじめ合図された帯域幅の予約による回復では、予約された回復容量の量はローカルの帯域幅予約方針で測定されます。 すべての回復体系では、その容量が失敗回復に使用されていないとき、プレ空に可能リソースは予備回復容量を使用できます。
12. Network Management
12. ネットワークマネージメント
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
それらのネットワークで(SPs)が構成するのに手広くネットワークマネージメントを使用するProviders、モニターまたは支給の様々なデバイスにサービスを提供してください。 SPの設備がその結果、分散管理をさらに重要にしながら地理的に別々のサイトの向こう側に分配されるかもしれないことに注意するのは重要です。 サービスプロバイダーは構成する標準インターフェース、モニター、および支給デバイスとして様々な位置でSNMPなどのNMSシステムと標準の管理プロトコル([RFC3410]、[RFC3411]、および[RFC3416]を見る)と関連MIBモジュールを利用するべきです。 また、サービスプロバイダーはベンダーによってそれらのデバイスに提供されたコマンドラインインタフェース(CLI)を使用したがっているかもしれません。 しかしながら、どんな標準のCLI言語もインタフェース(N異なったベンダーからのデバイスでネットワークにおけるN異なったCLIsをもたらす)もないので、これは標準の、または、お勧めのソリューションではありません。 GMPLSの文脈では、SPのデバイス(例えば、SNMP)への標準インターフェースが技術自体の本質のため存在するのは、非常に重要です。 GMPLSが多くの異なった層の制御飛行機を包括するので
Mannie Standards Track [Page 54] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[54ページ]。
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.
そして、データ飛行機技術、この領域の管理インタフェースがマネージャが簡単、および標準の方法でGMPLSを管理するのを許容するほどフレキシブルであることは、重要です。
12.1. Network Management Systems (NMS)
12.1. ネットワーク管理システム(NMS)
The NMS system should maintain the collective information about each device within the system. Note that the NMS system may actually be comprised of several distributed applications (i.e., alarm aggregators, configuration consoles, polling applications, etc.) that collectively comprises the SP's NMS. In this way, it can make provisioning and maintenance decisions with the full knowledge of the entire SP's network. Configuration or provisioning information (i.e., requests for new services) could be entered into the NMS and subsequently distributed via SNMP to the remote devices. Thus, making the SP's task of managing the network much more compact and effortless rather than having to manage each device individually (i.e., via CLI).
NMSシステムはシステムの中の各デバイスの集合的な情報を保守するはずです。 NMSシステムが実際にいくつかの分配されたアプリケーション(すなわち、アラームアグリゲータ、構成コンソール、世論調査アプリケーションなど)からそんなにまとめて成るかもしれないというメモはSPのNMSを包括します。このように、それは全体のSPのネットワークに関する完全な知識で食糧を供給するのとメインテナンスを決定にすることができます。 構成か情報に食糧を供給するのを(すなわち、新種業務を求める要求)NMSに入れて、次に、SNMPを通して遠隔装置に分配できました。 その結果、個別(すなわち、CLIを通して)に各デバイスを管理しなければならないよりむしろSPのネットワークを経営するタスクをはるかにコンパクトで楽にします。
Security and access control can be achieved using the SNMPv3 User- based Security Model (USM) [RFC3414] and the View-based Access Control Model (VACM) [RFC3415]. This approach can be very effectively used within a SP's network, since the SP has access to and control over all devices within its domain. Standardized MIBs will need to be developed before this approach can be used ubiquitously to provision, configure and monitor devices in non- heterogeneous networks or across SP's network boundaries.
SNMPv3 UserのベースのSecurity Model(USM)[RFC3414]とViewベースのAccess Control Model(VACM)[RFC3415]を使用することでセキュリティとアクセスコントロールを達成できます。 SPのネットワークの中で非常に効果的にこのアプローチを使用できます、SPがドメインの中のすべてのデバイスの上に近づく手段を持って、制御するので。 標準化されたMIBsは非異機種ネットワークかSPのネットワーク限界の向こう側にデバイスをこのアプローチを支給に遍在して使用できる前に開発されるのが必要であり、構成して、モニターするでしょう。
12.2. Management Information Base (MIB)
12.2. 管理情報ベース(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
GMPLSの文脈では、デバイスへの標準インターフェースが技術自体の本質のため存在するのは、非常に重要です。 GMPLSが多くの異なった層の制御飛行機技術を包括するので、この領域のSNMP MIBモジュールがマネージャが全体の制御飛行機を管理するのを許容するほどフレキシブルであることは、重要です。 これは、協力するかもしれない(すなわち、エージェントの上で行作成を調整します)MIBモジュールを使用し終わっているか、取るために必要な動作のいくつかに集められるさらに一般化されたMIBモジュールであって、それらの詳細をデバイスまで押すべきです。 ある特定の状況では、管理便宜のための新しいMIBモジュールで処理しやすいオブジェクトの何らかの小さい部分集合をコピーするのが必要であるかもしれないことに注意するのは重要です。 また、GMPLSのいくつかの部分のコントロールは、既存のMIBインタフェース(すなわち、既存のSONET MIB)を使用するか、またはまだ定義されていないことである別々のものを使用することで達成されるかもしれません。 MIBモジュールは以前に、IETFかITUで定義されたかもしれません。 現在のMIBモジュールは、新しい機能性のいくつかを容易にするために広げられる必要があるかもしれません。
Mannie Standards Track [Page 55] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[55ページ]。
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によって望まれています。 これらの場合では、ワーキンググループは、これらの拡大を加えることができるようにこれらのMIBモジュールの新しいバージョンに取り組むべきです。
12.3. Tools
12.3. ツール
As in traditional networks, standard tools such as traceroute [RFC1393] and ping [RFC2151] are needed for debugging and performance monitoring of GMPLS networks, and mainly for the control plane topology, that will mimic the data plane topology. Furthermore, such tools provide network reachability information. The GMPLS control protocols will need to expose certain pieces of information in order for these tools to function properly and to provide information germane to GMPLS. These tools should be made available via the CLI. These tools should also be made available for remote invocation via the SNMP interface [RFC2925].
伝統的ネットワークでは、トレースルート[RFC1393]やピング[RFC2151]などの標準のツールがGMPLSネットワークのデバッグと性能モニター、および主にコントロール飛行機トポロジーに必要であるように、それはデータ飛行機トポロジーをまねるでしょう。 その上、そのようなツールはネットワーク可到達性情報を提供します。 GMPLS制御プロトコルは、これらのツールが適切に機能して、GMPLSに適切な情報を提供するようにある情報を暴露する必要があるでしょう。 これらのツールをCLIを通して利用可能にするべきです。 また、これらのツールをSNMPインタフェース[RFC2925]を通してリモート実施に利用可能にするべきです。
12.4. Fault Correlation between Multiple Layers
12.4. 複数の層の間の欠点相関関係
Due to the nature of GMPLS, and that potential layers may be involved in the control and transmission of GMPLS data and control information, it is required that a fault in one layer be passed to the adjacent higher and lower layers to notify them of the fault. However, due to nature of these many layers, it is possible and even probable, that hundreds or even thousands of notifications may need to transpire between layers. This is undesirable for several reasons. First, these notifications will overwhelm the device. Second, if the device(s) are programmed to emit SNMP Notifications [RFC3417] then the large number of notifications the device may attempt to emit may overwhelm the network with a storm of notifications. Furthermore, even if the device emits the notifications, the NMS that must process these notifications either will be overwhelmed or will be processing redundant information. That is, if 1000 interfaces at layer B are stacked above a single interface below it at layer A, and the interface at A goes down, the interfaces at layer B should not emit notifications. Instead, the interface at layer A should emit a single notification. The NMS receiving this notification should be able to correlate the fact that this interface has many others stacked above it and take appropriate action, if necessary.
GMPLSの自然、および層がそうするその可能性への支払われるべきものがGMPLSデータと制御情報のコントロールと伝達にかかわって、1つの層における欠点が欠点についてそれらに通知するために隣接しているより高くて低級な層に通過されるのが必要です。 しかしながら、これらの多くの層の本質のために、それは、可能であって、ありえそうでさえあり、数百か何千もの通知が、層の間で蒸散する必要があるかもしれません。 これはいくつかの理由で望ましくありません。 まず最初に、これらの通知はデバイスを圧倒するでしょう。 2番目に、デバイスがSNMP Notifications[RFC3417]を放つようにプログラムされるなら、デバイスが放つのを試みるかもしれない多くの通知が通知の嵐に伴うネットワークを圧倒するかもしれません。 その上、デバイスが通知を放っても、これらの通知を処理しなければならないNMSは圧倒されるか、または余分な情報を処理するでしょう。 すなわち、層Bの1000のインタフェースが層Aでそれの下の単一のインタフェースの上で積み重ねられて、Aのインタフェースが落ちるなら、層Bのインタフェースは通知を放つべきではありません。 代わりに、層Aのインタフェースはただ一つの通知を放つべきです。 この通知を受け取るNMSはそれの上でこのインタフェースで多くの他のものを積み重ねるという事実を関連させて、必要なら、適切な行動を取ることができるはずです。
Devices that support GMPLS should provide mechanisms for aggregating, summarizing, enabling and disabling of inter-layer notifications for the reasons described above. In the context of SNMP MIB modules, all MIB modules that are used by GMPLS must provide enable/disable objects for all notification objects. Furthermore, these MIBs must also provide notification summarization objects or functionality (as described above) as well. NMS systems and standard tools which
GMPLSをサポートするデバイスはメカニズムを集めるのに提供するはずです、まとめます、と理由のための相互層の通知を可能にするのと無効にするのは上で説明しました。 SNMP MIBモジュールの文脈では、必須が提供するGMPLSによって使用されるすべてのMIBモジュールが、すべての通知オブジェクトのためにオブジェクトを可能にするか、または無効にします。 その上、また、これらのMIBsはまた、通知総括オブジェクトか機能性(上で説明されるように)を提供しなければなりません。 NMSシステムと規格はどれをツーリングするか。
Mannie Standards Track [Page 56] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[56ページ]。
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を実行するネットワークデバイスによって潜在的に放たれるかもしれない広大な情報量を処理しながら、どんな与えられたデバイスの上の層はできなければならない多くの動向をおさえてください。
13. Security Considerations
13. セキュリティ問題
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を使用することで設立されたLSPsがデータの高い量を運んで、重要なネットワーク資源を消費するかもしれないので、セキュリティー対策はデータ伝送リソースの制御飛行機、そして/または、権限のない用法に対する攻撃に対して基本的なネットワークを保護しなければなりません。 したがって、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]を見てください)。 さらに、プロトコル([RFC2402]、[RFC2406]、および[RFC2409]を見る)のIPsecスイートは認証、秘密性または両方を提供するのに使用されるかもしれません、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できるノードによるリソースに関する要求の承認のものです。 承認で、認証されて、当然のことのパーティーで、ありそうであるか否かに関係なく、既に決定して、aは、要求されたリソースにアクセスするために正します。 通常、この決断は地方の方針コントロール[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
要求を認証した後に、制御要素はローカルの承認方針に対してそれらに合っているはずです。 これらの制御要素はアイデンティティに基づく決定をすることができなければなりません。
Mannie Standards Track [Page 57] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLSアーキテクチャ2004年10月にRFC3945を追跡します[57ページ]。
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.
暗号で位相的に確かめられるようなリクエスタ。 または、例えば、決定が要求がされるインタフェースがそうであるかどうかによるかもしれない、相互、イントラドメイン1 適切なローカルの承認方針の使用は、ネットワークのリモート部分で機密保護違反の影響を制限するのを手伝うかもしれません。
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-自由民主党)にどんな新しいセキュリティ問題も取り入れないことに注意されるべきです、ルーティング・プロトコル、(OSPF-TE、TEである、)、または、ネットワーク管理プロトコル(SNMP)。
14. Acknowledgements
14. 承認
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議論のためにベンマック-クレーン(Tellabs)をありがとうございます。 また、彼らのSonet/SDH、光の技術的助言、およびサポートをEboneからペドロ・ファルカン、アレクサンドルGeyssens、マイケルMoelants、ザビエルNeerdaels、およびフィリップNoelまでありがとうございます。 また、最終的に、彼らの改正の努力のためにセクション12でクリシュナ・ミトラ(コンサルタント)、カーティスVillamizar(Avici)、ロンBonica(ワールドコム)、およびバートWijnen(透明な)をありがとうございます。
15. References
15. 参照
15.1. Normative References
15.1. 引用規格
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T.,
Srinivasan, V., and G. Swallow, "RSVP-TE:
Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
[RFC3209] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。
[RFC3212] Jamoussi, B., Andersson, L., Callon, R., Dantu,
R., Wu, L., Doolan, P., Worster, T., Feldman,
N., Fredette, A., Girish, M., Gray, E.,
Heinanen, J., Kilty, T., and A. Malis,
"Constraint-Based LSP Setup using LDP", RFC
3212, January 2002.
[RFC3212] Jamoussi、B.、アンデション、L.、Callon、R.、Dantu、R.、ウー、L.、Doolan、P.、オースター、T.、フェルドマン、N.、Fredette、A.、Girish、M.、グレー、E.、Heinanen、J.、Kilty、T.、およびA.Malis、「自由民主党を使用して、規制ベースのLSPはセットアップします」、RFC3212、2002年1月。
[RFC3471] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional
Description", RFC 3471, January 2003.
[RFC3471] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)のシグナリングの機能的な記述」、RFC3471、2003年1月。
Mannie Standards Track [Page 58] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[58ページ]。
[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-スミス(P.とL.バーガー)は、「規制ベースの発送されたラベル分配プロトコル(CR-自由民主党)拡大に合図しながら、マルチプロトコルラベルスイッチング(GMPLS)を一般化しました」、RFC3472、2003年1月。
[RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering
(RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3473] バーガー、L.、「一般化されたマルチプロトコルラベルスイッチング(GMPLS)シグナリング資源予約プロトコル交通工学(RSVP-Te)拡大」、RFC3473、2003年1月。
15.2. Informative References
15.2. 有益な参照
[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.バーガー、「MPLS交通工学におけるリンクバンドリング」は進行中で働いています。
[GMPLS-FUNCT] Lang, J.P., Ed. and B. Rajagopalan, Ed.,
"Generalized MPLS Recovery Functional
Specification", Work in Progress.
エド[GMPLS-FUNCT]ラング、J.P.、B.Rajagopalan、エド、「一般化されたMPLS回復機能的な仕様」、処理中の作業。
[GMPLS-G709] Papadimitriou, D., Ed., "GMPLS Signaling
Extensions for G.709 Optical Transport Networks
Control", Work in Progress.
[GMPLS-G709] エドPapadimitriou、D.、「GMPLSはG.709の光の転送ネットワークコントロールのための拡大に合図すること」での処理中の作業。
[GMPLS-OVERLAY] Swallow, G., Drake, J., Ishimatsu, H., and Y.
Rekhter, "GMPLS UNI: RSVP Support for the
Overlay Model", Work in Progress.
[GMPLS-オーバレイ]のツバメ、G.、ドレイク、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-ルーティング] エド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)拡大を切り換えること」でのRFC3946(2004年10月)。
[HIERARCHY] Kompella, K. and Y. Rekhter, "LSP Hierarchy
with Generalized MPLS TE", Work in Progress.
「一般化されたMPLS TeがあるLSP階層構造」という[階層構造]Kompella、K.、およびY.Rekhterは進行中で働いています。
Mannie Standards Track [Page 59] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[59ページ]。
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for
Traffic Engineering (TE)", RFC 3784, June 2004.
[イシス-Te] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(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.
一般化されたマルチプロトコルを支持した拡大は切り換えをラベルします。エド[イシスTe GMPLS]Kompella、K.、Y.Rekhter、エド、「-、」 仕事進行中です。
[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)」、Recommendation G.709バージョン1.0(そして、Amendment1)(2001(2001年10月)年2月)。
[ITUT-G.841] ITU-T, "Types and Characteristics of SDH
Network Protection Architectures,"
Recommendation G.841, October 1998.
[ITUT-G.841]ITU-T、「SDHのタイプと特性は保護構造をネットワークでつなぐ」推薦G.841、1998年10月。
[LMP] Lang, J., Ed., "Link Management Protocol
(LMP)", Work in Progress.
[LMP] ラング、J.、エド、「リンク管理プロトコル(LMP)」、処理中の作業。
[LMP-WDM] Fredette, A., Ed. and J. Lang Ed., "Link
Management Protocol (LMP) for Dense Wavelength
Division Multiplexing (DWDM) Optical Line
Systems", Work in Progress.
[LMP-WDM]Fredette(A.エド(J.ラング・エド))は「高密度波長多重光通信(DWDM)の光学回線システムのために、管理プロトコル(LMP)をリンクします」、処理中の作業。
[MANCHESTER] J. Manchester, P. Bonenfant and C. Newton, "The
Evolution of Transport Network Survivability,"
IEEE Communications Magazine, August 1999.
[マンチェスター] J.マンチェスターとP.BonenfantとC.ニュートン、「転送ネットワークの生存性の発展」、IEEEコミュニケーション雑誌、1999年8月。
[OIF-UNI] The Optical Internetworking Forum, "User
Network Interface (UNI) 1.0 Signaling
Specification - Implementation Agreement OIF-
UNI-01.0," October 2001.
[OIF-UNI] 光学インターネットワーキングフォーラム、「ユーザネットワークは(UNI)1.0シグナリング仕様を連結します--実現協定OIF- UNI-01.0」、10月2001日
[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拡張子は切り替わる」処理中の作業。
Mannie Standards Track [Page 60] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[60ページ]。
[OSPF-TE] Katz, D., Kompella, K., and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2",
RFC 3630, September 2003.
[OSPF-Te] キャッツ、D.、Kompella、K.、およびD.Yeung、「(Te)拡大をOSPFにバージョン2インチ設計する交通、RFC3630、2003年9月。」
[RFC1393] Malkin, G., "Traceroute Using an IP Option",
RFC 1393, January 1993.
[RFC1393] マルキン、G.、「IPオプションを使用するトレースルート」、RFC1393、1993年1月。
[RFC2151] Kessler, G. and S. Shepard, "A Primer On
Internet and TCP/IP Tools and Utilities", RFC
2151, June 1997.
[RFC2151] ケスラーとG.とS.シェパード、「インターネット、TCP/IPツール、およびユーティリティに関する入門書」、RFC2151、1997年6月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S.,
and S. Jamin, "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification",
RFC 2205, September 1997.
[RFC2205] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via
the TCP MD5 Signature Option", RFC 2385, August
1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication
Header", RFC 2402, November 1998.
[RFC2402] ケントとS.とR.アトキンソン、「IP認証ヘッダー」、RFC2402、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating
Security Payload (ESP)", RFC 2406, November
1998.
[RFC2406]ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key
Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 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.とマルコムとJ.とAgogbuaとJ.とオデル、M.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP
Cryptographic Authentication", RFC 2747,
January 2000.
[RFC2747] ベイカーとF.とリンデル、B.とM.Talwar、「RSVPの暗号の認証」、RFC2747、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.ゲラン、「方針ベースの入場コントロールのための枠組み」、RFC2753、2000年1月。
[RFC2925] White, K., "Definitions of Managed Objects for
Remote Ping, Traceroute, and Lookup
Operations", RFC 2925, September 2000.
[RFC2925]ホワイト、K.、「リモートピング、トレースルート、およびルックアップ操作のための管理オブジェクトの定義」、RFC2925、2000年9月。
Mannie Standards Track [Page 61] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[61ページ]。
[RFC3036] Andersson, L., Doolan, P., Feldman, N.,
Fredette, A., and B. Thomas, "LDP
Specification", RFC 3036, January 2001.
[RFC3036] アンデションとL.とDoolanとP.とフェルドマンとN.とFredette、A.とB.トーマス、「自由民主党仕様」、RFC3036、2001年1月。
[RFC3386] Lai, W. and D. McDysan, "Network Hierarchy and
Multilayer Survivability", RFC 3386, November
2002.
[RFC3386] レイ、W.、およびD.McDysanが「階層構造と多層の生存性をネットワークでつなぐ」、RFC3386、11月2002日
[RFC3410] Case, J., Mundy, R., Partain, D., and B.
Stewart, "Introduction and Applicability
Statements for Internet-Standard Management
Framework", RFC 3410, December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準の管理枠組みのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management
Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理枠組みについて説明するための構造」、STD62、RFC3411(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]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、STD62、RFC3414、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、「簡単なネットワークマネージメントのための視点ベースのアクセス管理モデル(VACM)は(SNMP)について議定書の中で述べます」、STD62、RFC3415、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.、「簡単なネットワークマネージメントのためのプロトコル操作のバージョン2は(SNMP)について議定書の中で述べます」、STD62、RFC3416、2002年12月。
[RFC3417] Presuhn, R., "Transport Mappings for the Simple
Network Management Protocol (SNMP)", STD 62,
RFC 3417, December 2002.
[RFC3417] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための輸送マッピング」、STD62、RFC3417、2002年12月。
[RFC3469] Sharma, V. and F. Hellstrand, "Framework for
Multi-Protocol Label Switching (MPLS)-based
Recovery", RFC 3469, February 2003.
[RFC3469] シャルマとV.とF.Hellstrand、「マルチプロトコルラベルスイッチングの(MPLS)ベースの回復のための枠組み」、RFC3469、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)」、RFC3477、2003年1月。
Mannie Standards Track [Page 62] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[62ページ]。
[RFC3479] Farrel, A., "Fault Tolerance for the Label
Distribution Protocol (LDP)", RFC 3479,
February 2003.
[RFC3479]ファレル、A.、「ラベル分配プロトコル(自由民主党)のための耐障害性」、RFC3479、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-自由民主党(規制ルート設定ラベル分配プロトコル)で無数のリンクに合図します」、RFC3480(2003年2月)。
[SONET-SDH-GMPLS-FRM] Bernstein, G., Mannie, E., and V. Sharma,
"Framework for GMPLS-based Control of SDH/SONET
Networks", Work in Progress.
[Sonet-SDH-GMPLS-FRM] バーンスタイン、G.、マニー、E.、およびV.シャルマ、「SDH/SonetネットワークのGMPLSベースのコントロールのための枠組み」は進行中で働いています。
16. Contributors
16. 貢献者
Peter Ashwood-Smith Nortel P.O. Box 3511 Station C, Ottawa, ON K1Y 4H7, Canada
ピーターAshwood-スミスノーテルP.O. Box3511駅C、K1Y 4H7、カナダのオタワ
EMail: petera@nortelnetworks.com
メール: petera@nortelnetworks.com
Eric Mannie Consult Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
エリック・マニーは電話に相談します: +32 2 648-5023 モバイル: +32 (0)495-221775
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Daniel O. Awduche Consult
ダニエルO.Awducheは相談します。
EMail: awduche@awduche.com
メール: awduche@awduche.com
Thomas D. Nadeau Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
トーマスD.ナドーシスコ250アポロDriveチェルムズフォード、MA 01824、米国
EMail: tnadeau@cisco.com
メール: tnadeau@cisco.com
Mannie Standards Track [Page 63] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[63ページ]。
Ayan Banerjee Calient 5853 Rue Ferrari San Jose, CA 95138, USA
フェラーリサンノゼ、バネルジーCalient5853Rueカリフォルニア 95138、アヤン米国
EMail: abanerjee@calient.net
メール: abanerjee@calient.net
Lyndon Ong Ciena 10480 Ridgeview Ct Cupertino, CA 95014, USA
カルパチーノ、Ridgeview Ctカリフォルニア 95014、リンドンオングCiena10480米国
EMail: lyong@ciena.com
メール: lyong@ciena.com
Debashis Basak Accelight 70 Abele Road, Bldg.1200 Bridgeville, PA 15017, USA
Debashis Basak Accelight70ハクヨウ道路、Bldg.1200 Bridgeville、PA 15017、米国
EMail: dbasak@accelight.com
メール: dbasak@accelight.com
Dimitri Papadimitriou Alcatel Francis Wellesplein, 1 B-2018 Antwerpen, Belgium
ディミトリPapadimitriouアルカテルフランシスWellesplein、1B-2018のアントウェルペン(ベルギー)
EMail: dimitri.papadimitriou@alcatel.be
メール: dimitri.papadimitriou@alcatel.be
Lou Berger Movaz 7926 Jones Branch Drive MCLean VA, 22102, USA
22102、ルウバーガーMovaz7926ジョーンズ・支店ドライブMCLeanヴァージニア(米国)
EMail: lberger@movaz.com
メール: lberger@movaz.com
Dimitrios Pendarakis Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
デーメートリオスPendarakis Tellium2の三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: dpendarakis@tellium.com
メール: dpendarakis@tellium.com
Mannie Standards Track [Page 64] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[64ページ]。
Greg Bernstein Grotto
グレッグバーンスタインGrotto
EMail: gregb@grotto-networking.com
メール: gregb@grotto-networking.com
Bala Rajagopalan Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Bala Rajagopalan Tellium2の三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: braja@tellium.com
メール: braja@tellium.com
Sudheer Dharanikota Consult
Sudheer Dharanikotaは相談します。
EMail: sudheer@ieee.org
メール: sudheer@ieee.org
Yakov Rekhter Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
ヤコフRekhter Juniper1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国
EMail: yakov@juniper.net
メール: yakov@juniper.net
John Drake Calient 5853 Rue Ferrari San Jose, CA 95138, USA
フェラーリサンノゼ、ジョンドレイクCalient5853Rueカリフォルニア 95138、米国
EMail: jdrake@calient.net
メール: jdrake@calient.net
Debanjan Saha Tellium 2 Crescent Place Oceanport, NJ 07757-0901, USA
三日月形場所Oceanport、DebanjanシャハTellium2ニュージャージー07757-0901(米国)
EMail: dsaha@tellium.com
メール: dsaha@tellium.com
Mannie Standards Track [Page 65] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[65ページ]。
Yanhe Fan Axiowave 200 Nickerson Road Marlborough, MA 01752, USA
YanheファンAxiowave200Nickerson Roadマールバラ、MA 01752、米国
EMail: yfan@axiowave.com
メール: yfan@axiowave.com
Hal Sandick Shepard M.S. 2401 Dakota Street Durham, NC 27705, USA
ダラム、NC 27705、ハルSandickシェパードm.s.2401ダコタ通り米国
EMail: sandick@nc.rr.com
メール: sandick@nc.rr.com
Don Fedyk Nortel 600 Technology Park Drive Billerica, MA 01821, USA
Driveビルリカ、ドンFedykノーテル600技術Park MA 01821、米国
EMail: dwfedyk@nortelnetworks.com
メール: dwfedyk@nortelnetworks.com
Vishal Sharma Metanoia 1600 Villa Street, Unit 352 Mountain View, CA 94041, USA
VishalシャルマMetanoia1600Villa通り、Unit352マウンテンビュー、カリフォルニア 94041、米国
EMail: v.sharma@ieee.org
メール: v.sharma@ieee.org
Gert Grammel Alcatel Lorenzstrasse, 10 70435 Stuttgart, Germany
ゲルトGrammelアルカテルLorenzstrasse、10 70435シュツットガルト(ドイツ)
EMail: gert.grammel@alcatel.de
メール: gert.grammel@alcatel.de
George Swallow Cisco 250 Apollo Drive Chelmsford, MA 01824, USA
ジョージツバメシスコ250アポロDriveチェルムズフォード、MA 01824、米国
EMail: swallow@cisco.com
メール: swallow@cisco.com
Mannie Standards Track [Page 66] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[66ページ]。
Dan Guo Turin 1415 N. McDowell Blvd, Petaluma, CA 95454, USA
ダンクオトリノ1415N.マクドウェルBlvd、ペタルマ、カリフォルニア 95454、米国
EMail: dguo@turinnetworks.com
メール: dguo@turinnetworks.com
Z. Bo Tang Tellium 2 Crescent Place, P.O. Box 901 Oceanport, NJ 07757-0901, USA
Z.棒ピリッとする味Tellium2の三日月形場所、Oceanport、ニュージャージー07757-0901、P.O. Box901米国
EMail: btang@tellium.com
メール: btang@tellium.com
Kireeti Kompella Juniper 1194 N. Mathilda Ave. Sunnyvale, CA 94089, USA
Kireeti Kompella杜松1194N.マチルダAve。 サニーベル、カリフォルニア 94089、米国
EMail: kireeti@juniper.net
メール: kireeti@juniper.net
Jennifer Yates AT&T 180 Park Avenue Florham Park, NJ 07932, USA
ジェニファーイェイツAT&T180パーク・アベニューFlorham公園、ニュージャージー 07932、米国
EMail: jyates@research.att.com
メール: jyates@research.att.com
Alan Kullberg NetPlane 888 Washington St.Dedham, MA 02026, USA
聖デダム、MA 02026、アランKullberg NetPlane888ワシントン米国
EMail: akullber@netplane.com
メール: akullber@netplane.com
George R. Young Edgeflow 329 March Road Ottawa, Ontario, K2K 2E1, Canada
ジョージR.の若いEdgeflow329 3月のRoadオタワ、オンタリオK2K2E1、カナダ
EMail: george.young@edgeflow.com
メール: george.young@edgeflow.com
Mannie Standards Track [Page 67] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[67ページ]。
Jonathan P. Lang Rincon Networks
ジョナサンP.ラングリンコンネットワーク
EMail: jplang@ieee.org
メール: jplang@ieee.org
John Yu Hammerhead Systems 640 Clyde Court Mountain View, CA 94043, USA
マウンテンビュー、ジョンユーハンマーの頭システム640クライド法廷カリフォルニア 94043、米国
EMail: john@hammerheadsystems.com
メール: john@hammerheadsystems.com
Fong Liaw Solas Research Solas Research, LLC
フォンLiawソラスの研究ソラスの研究、LLC
EMail: fongliaw@yahoo.com
メール: fongliaw@yahoo.com
Alex Zinin Alcatel 1420 North McDowell Ave Petaluma, CA 94954, USA
アレックスジニンアルカテル1420の北のマクドウェル・Aveペタルマ、カリフォルニア 94954、米国
EMail: alex.zinin@alcatel.com
メール: alex.zinin@alcatel.com
17. Author's Address
17. 作者のアドレス
Eric Mannie (Consultant) Avenue de la Folle Chanson, 2 B-1050 Brussels, Belgium Phone: +32 2 648-5023 Mobile: +32 (0)495-221775
エリックマニー(コンサルタント)アベニューde la Folle Chanson、2B-1050ブリュッセル(ベルギー)電話: +32 2 648-5023 モバイル: +32 (0)495-221775
EMail: eric_mannie@hotmail.com
メール: eric_mannie@hotmail.com
Mannie Standards Track [Page 68] RFC 3945 GMPLS Architecture October 2004
マニーStandardsはGMPLS構造2004年10月にRFC3945を追跡します[68ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Mannie Standards Track [Page 69]
マニー標準化過程[69ページ]
一覧
スポンサーリンク
