[要約] RFC 3386は、ネットワークの階層構造とマルチレイヤーの生存性に関するガイドラインです。その目的は、ネットワークの設計と運用において、階層構造と生存性の考慮を通じて信頼性と効率性を向上させることです。
Network Working Group W. Lai, Ed.
Request for Comments: 3386 AT&T
Category: Informational D. McDysan, Ed.
WorldCom
November 2002
Network Hierarchy and Multilayer Survivability
ネットワーク階層と多層の生存性
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments.
この文書は、現在のサービスプロバイダー環境におけるネットワークの生存性と階層に関する短期的および実用的な要件の提案を提示します。
Conventions used in this document
このドキュメントで使用されている規則
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されているように解釈される。
Table of Contents
目次
1. Introduction..............................................2
2. Terminology and Concepts..................................5
2.1 Hierarchy................................................6
2.1.1 Vertical Hierarchy.....................................5
2.1.2 Horizontal Hierarchy...................................6
2.2 Survivability Terminology................................6
2.2.1 Survivability..........................................7
2.2.2 Generic Operations.....................................7
2.2.3 Survivability Techniques...............................8
2.2.4 Survivability Performance..............................9
2.3 Survivability Mechanisms: Comparison....................10
3. Survivability............................................11
3.1 Scope...................................................11
3.2 Required initial set of survivability mechanisms........12
3.2.1 1:1 Path Protection with Pre-Established Capacity.....12
3.2.2 1:1 Path Protection with Pre-Planned Capacity.........13
3.2.3 Local Restoration.....................................13
3.2.4 Path Restoration......................................14
3.3 Applications Supported..................................14
3.4 Timing Bounds for Survivability Mechanisms..............15
3.5 Coordination Among Layers...............................16
3.6 Evolution Toward IP Over Optical........................17
4. Hierarchy Requirements...................................17
4.1 Historical Context......................................17
4.2 Applications for Horizontal Hierarchy...................18
4.3 Horizontal Hierarchy Requirements.......................19
5. Survivability and Hierarchy..............................19
6. Security Considerations..................................20
7. References...............................................21
8. Acknowledgments..........................................22
9. Contributing Authors.....................................22
Appendix A: Questions used to help develop requirements.....23
Editors' Addresses..........................................26
Full Copyright Statement....................................27
This document is the result of the Network Hierarchy and Survivability Techniques Design Team established within the Traffic Engineering Working Group. This team collected and documented current and near term requirements for survivability and hierarchy in service provider environments. For clarity, an expanded set of definitions is included. The team determined that there appears to be a need to define a small set of interoperable survivability approaches in packet and non-packet networks. Suggested approaches include path-based as well as one that repairs connections in proximity to the network fault. They operate primarily at a single network layer. For hierarchy, there did not appear to be a driving near-term need for work on "vertical hierarchy," defined as communication between network layers such as Time Division Multiplexed (TDM)/optical and Multi-Protocol Label Switching (MPLS). In particular, instead of direct exchange of signaling and routing between vertical layers, some looser form of coordination and communication, such as the specification of hold-off timers, is a nearer term need. For "horizontal hierarchy" in data networks, there are several pressing needs. The requirement is to be able to set up many Label Switched Paths (LSPs) in a service provider network with hierarchical Interior Gateway Protocol (IGP). This is necessary to support layer 2 and layer 3 Virtual Private Network (VPN) services that require edge-to-edge signaling across a core network.
このドキュメントは、トラフィックエンジニアリングワーキンググループ内で確立されたネットワーク階層と生存性テクニックデザインチームの結果です。このチームは、サービスプロバイダー環境における生存性と階層に関する現在および短期的な要件を収集し、文書化しました。明確にするために、拡張された一連の定義が含まれています。チームは、パケットネットワークと非パケットネットワークで、相互運用可能な生存可能性アプローチの小さなセットを定義する必要があると判断しました。推奨されるアプローチには、パスベースと、ネットワーク障害に近い接続を修理するものが含まれます。それらは主に単一のネットワークレイヤーで動作します。階層の場合、「垂直階層」の作業に対する近い策の必要性はありませんでした。これは、時分割多重（TDM）/光学およびマルチプロトコルラベルスイッチング（MPLS）などのネットワークレイヤー間の通信として定義されています。特に、垂直層間のシグナリングとルーティングの直接交換の代わりに、ホールドオフタイマーの仕様など、いくつかのゆるい形式の調整と通信は、より近い用語の必要性です。データネットワークの「水平階層」の場合、いくつかの差し迫ったニーズがあります。要件は、階層的なインテリアゲートウェイプロトコル（IGP）を備えたサービスプロバイダーネットワークに多くのラベルスイッチ付きパス（LSP）をセットアップできるようにすることです。これは、コアネットワーク全体でエッジツーエッジシグナル伝達を必要とするレイヤー2およびレイヤー3仮想プライベートネットワーク（VPN）サービスをサポートするために必要です。
This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments. With feedback from the working group solicited, the objective is to help focus the work that is being addressed in the TEWG (Traffic Engineering Working Group), CCAMP (Common Control and Measurement Plane Working Group), and other working groups. A main goal of this work is to provide some expedience for required functionality in multi-vendor service provider networks. The initial focus is primarily on intra-domain operations. However, to maintain consistency in the provision of end-to-end service in a multi-provider environment, rules governing the operations of survivability mechanisms at domain boundaries must also be specified. While such issues are raised and discussed, where appropriate, they will not be treated in depth in the initial release of this document.
この文書は、現在のサービスプロバイダー環境におけるネットワークの生存性と階層に関する短期的および実用的な要件の提案を提示します。ワーキンググループからのフィードバックを求めて、目的は、TEWG（トラフィックエンジニアリングワーキンググループ）、CCAMP（Common Control and Measurement Plane Working Group）、およびその他のワーキンググループで対処されている作業の集中を支援することです。この作業の主な目標は、マルチベンダーサービスプロバイダーネットワークで必要な機能にいくつかの手段を提供することです。最初の焦点は主にドメイン内の操作にあります。ただし、マルチプロバイダー環境でのエンドツーエンドサービスの提供の一貫性を維持するには、ドメイン境界での生存可能性メカニズムの操作を管理するルールも指定する必要があります。そのような問題は提起され、議論されていますが、必要に応じて、このドキュメントの最初のリリースでは詳細に扱われません。
The document first develops a set of definitions to be used later in this document and potentially in other documents as well. It then addresses the requirements and issues associated with service restoration, hierarchy, and finally a short discussion of survivability in hierarchical context.
このドキュメントは、最初に、このドキュメントの後半で使用される一連の定義を開発し、潜在的に他のドキュメントでも開発します。次に、サービスの復元、階層に関連する要件と問題に対処し、最後に階層的コンテキストでの生存性についての短い議論に対処します。
Here is a summary of the findings:
これが調査結果の要約です：
A. Survivability Requirements
A.生存可能性要件
o need to define a small set of interoperable survivability approaches in packet and non-packet networks o suggested survivability mechanisms include - 1:1 path protection with pre-established backup capacity (non-shared) - 1:1 path protection with pre-planned backup capacity (shared)
o パケットおよび非パケットネットワークでの小さな相互運用可能な生存可能性アプローチを定義する必要がありますo推奨される生存可能性メカニズムには-1：1のバックアップ容量（非共有）を備えた1：1パス保護-1：1プランのバックアップによるパス保護容量（共有）
- local restoration with repairs in proximity to the network fault - path restoration through source-based rerouting o timing bounds for service restoration to support voice call cutoff (140 msec to 2 sec), protocol timer requirements in premium data services, and mission critical applications o use of restoration priority for service differentiation
- ネットワーク障害に近接した修理を伴うローカルの修復 - ソースベースの再ルーティングを通じてパスの修復o音声コールカットオフ（140ミリ秒から2秒）、プレミアムデータサービスのプロトコルタイマー要件、およびミッションクリティカルアプリケーションをサポートするためのサービス復元の境界oサービス差別化のための修復優先度の使用
B. Hierarchy Requirements
B.階層要件
B.1. Horizontally Oriented Hierarchy (Intra-Domain)
B.1. 水平方向の階層（ドメイン内）
o ability to set up many LSPs in a service provider network with hierarchical IGP, for the support of layer 2 and layer 3 VPN services o requirements for multi-area traffic engineering need to be developed to provide guidance for any necessary protocol extensions
o レイヤー2とレイヤー3 VPNサービスのサポートのために、階層IGPを使用してサービスプロバイダーネットワークに多くのLSPをセットアップする能力o必要なプロトコル拡張のガイダンスを提供するために、マルチエリア交通工学の要件を開発する必要があります
B.2. Vertically Oriented Hierarchy
B.2. 垂直方向の階層
The following functionality for survivability is common on most routing equipment today.
現在のほとんどのルーティング機器では、生存性のための次の機能が一般的です。
o near-term need is some loose form of coordination and communication based on the use of nested hold-off timers, instead of direct exchange of signaling and routing between vertical layers o means for an upper layer to immediately begin recovery actions in the event that a lower layer is not configured to perform recovery
o 短期的なニーズとは、垂直層間の直接的な信号とルーティングの直接交換の代わりに、ネストされたホールドオフタイマーの使用に基づいた調整と通信のゆるい形式o上層層がすぐに回復アクションを開始することを意味します。下層は、回復を実行するように構成されていません
C. Survivability Requirements in Horizontal Hierarchy
C.水平階層における生存性要件
o protection of end-to-end connection is based on a concatenated set of connections, each protected within their area o mechanisms for connection routing may include (1) a network element that participates on both sides of a boundary (e.g., OSPF ABR) - note that this is a common point of failure; (2) a route server o need for inter-area signaling of survivability information (1) to enable a "least common denominator" survivability mechanism at the boundary; (2) to convey the success or failure of the service restoration action; e.g., if a part of a "connection" is down on one side of a boundary, there is no need for the other side to recover from failures
o エンドツーエンド接続の保護は連結された接続セットに基づいています。各エリア内で保護されている各接続ルーティングのメカニズムには、（1）境界の両側に関与するネットワーク要素が含まれます（例：OSPF ABR） - これは障害の一般的なポイントであることに注意してください。（2）ルートサーバーo生存可能性情報のエリア間信号の必要性（1）境界での「最も一般的な分母」生存性メカニズムを可能にする。（2）サービス修復措置の成功または失敗を伝える。たとえば、「接続」の一部が境界の片側にある場合、反対側が障害から回復する必要はありません
Hierarchy is a technique used to build scalable complex systems. It is based on an abstraction, at each level, of what is most significant from the details and internal structures of the levels further away. This approach makes use of a general property of all hierarchical systems composed of related subsystems that interactions between subsystems decrease as the level of communication between subsystems decreases.
階層は、スケーラブルな複雑なシステムを構築するために使用される手法です。これは、各レベルの抽象化に基づいており、さらに離れたレベルの詳細と内部構造から最も重要なものです。このアプローチは、サブシステム間の相互作用がサブシステム間の通信レベルが減少するにつれて減少するため、関連するサブシステムで構成されるすべての階層システムの一般的な特性を利用します。
Network hierarchy is an abstraction of part of a network's topology, routing and signaling mechanisms. Abstraction may be used as a mechanism to build large networks or as a technique for enforcing administrative, topological, or geographic boundaries. For example, network hierarchy might be used to separate the metropolitan and long-haul regions of a network, or to separate the regional and backbone sections of a network, or to interconnect service provider networks (with BGP which reduces a network to an Autonomous System).
ネットワーク階層は、ネットワークのトポロジ、ルーティング、シグナリングメカニズムの一部の抽象化です。抽象化は、大規模なネットワークを構築するメカニズムとして、または管理、トポロジー、または地理的境界を実施するための手法として使用できます。たとえば、ネットワーク階層を使用して、ネットワークの大都市圏と長距離地域を分離したり、ネットワークの地域とバックボーンセクションを分離したり、サービスプロバイダーネットワークを相互接続したりするために（ネットワークを自律システムに削減するBGPを使用して）。
In this document, network hierarchy is considered from two perspectives:
このドキュメントでは、ネットワーク階層は2つの観点から考慮されます。
(1) Vertically oriented: between two network technology layers. (2) Horizontally oriented: between two areas or administrative subdivisions within the same network technology layer.
(1) 垂直方向の方向：2つのネットワークテクノロジーレイヤー間。（2）水平方向の方向：同じネットワークテクノロジーレイヤー内の2つの領域または管理下の区画の間。
Vertical hierarchy is the abstraction, or reduction in information, which would be of benefit when communicating information across network technology layers, as in propagating information between optical and router networks.
垂直階層は抽象化、または情報の削減であり、光学ネットワークとルーターネットワーク間で情報を伝播するように、ネットワークテクノロジーレイヤー間で情報を通信するときに有益です。
In the vertical hierarchy, the total network functions are partitioned into a series of functional or technological layers with clear logical, and maybe even physical, separation between adjacent layers. Survivability mechanisms either currently exist or are being developed at multiple layers in networks [3]. The optical layer is now becoming capable of providing dynamic ring and mesh restoration functionality, in addition to traditional 1+1 or 1:1 protection. The Synchronous Digital Hierarchy (SDH)/Synchronous Optical NETwork (SONET) layer provides survivability capability with automatic protection switching (APS), as well as self-healing ring and mesh restoration architectures. Similar functionality has been defined in the Asynchronous Transfer Mode (ATM) Layer, with work ongoing to also provide such functionality using MPLS [4]. At the IP layer, rerouting is used to restore service continuity following link and node outages. Rerouting at the IP layer, however, occurs after a period of routing convergence, which may require a few seconds to several minutes to complete [5].
垂直階層では、総ネットワーク関数は、明確な論理的で、さらには隣接する層間の物理的な分離を伴う一連の機能的または技術的層に分割されます。現在存在する生存性メカニズムは、ネットワーク内の複数の層で開発されています[3]。光学層は、従来の1 1または1：1の保護に加えて、動的リングとメッシュの修復機能を提供できるようになりました。同期デジタル階層（SDH）/同期光ネットワーク（SONET）レイヤーは、自動保護スイッチング（APS）、および自己修復リングとメッシュの修復アーキテクチャで生存性機能を提供します。同様の機能は、非同期転送モード（ATM）層で定義されており、MPLを使用してそのような機能を提供するように作業を進行しています[4]。IPレイヤーでは、リンクとノードの停止後のサービスの継続性を回復するために再ルーティングが使用されます。ただし、IPレイヤーでのルーティングのルーティングの期間後に発生します。これは、完了するのに数秒から数分かかる場合があります[5]。
Horizontal hierarchy is the abstraction that allows a network at one technology layer, for instance a packet network, to scale. Examples of horizontal hierarchy include BGP confederations, separate Autonomous Systems, and multi-area OSPF.
水平階層は、たとえばパケットネットワークなど、1つのテクノロジーレイヤーでネットワークを拡張できるようにする抽象化です。水平階層の例には、BGPコンフェデレーション、個別の自律システム、およびマルチエリアOSPFが含まれます。
In the horizontal hierarchy, a large network is partitioned into multiple smaller, non-overlapping sub-networks. The partitioning criteria can be based on topology, network function, administrative policy, or service domain demarcation. Two networks at the *same* hierarchical level, e.g., two Autonomous Systems in BGP, may share a peer relation with each other through some loose form of coupling. On the other hand, for routing in large networks using multi-area OSPF, abstraction through the aggregation of routing information is achieved through a hierarchical partitioning of the network.
水平階層では、大規模なネットワークが複数の小さく、重複しないサブネットワークに分割されます。パーティション基準は、トポロジ、ネットワーク機能、管理ポリシー、またはサービスドメインの境界に基づいています。*同じ *階層レベル、たとえばBGPの2つの自律システムの2つのネットワークは、いくつかのゆるい形式のカップリングを通じてピア関係を互いに共有する場合があります。一方、マルチエリアOSPFを使用した大規模なネットワークでのルーティングの場合、ルーティング情報の集約による抽象化は、ネットワークの階層分割を通じて達成されます。
In alphabetical order, the following terms are defined in this section:
アルファベット順に、次の用語がこのセクションで定義されています。
backup entity, same as protection entity (section 2.2.2) extra traffic (section 2.2.2) non-revertive mode (section 2.2.2) normalization (section 2.2.2) preemptable traffic, same as extra traffic (section 2.2.2) preemption priority (section 2.2.4) protection (section 2.2.3) protection entity (section 2.2.2) protection switching (section 2.2.3) protection switch time (section 2.2.4) recovery (section 2.2.2) recovery by rerouting, same as restoration (section 2.2.3) recovery entity, same as protection entity (section 2.2.2) restoration (section 2.2.3) restoration priority (section 2.2.4) restoration time (section 2.2.4) revertive mode (section 2.2.2) shared risk group (SRG) (section 2.2.2) survivability (section 2.2.1) working entity (section 2.2.2)
保護エンティティと同じバックアップエンティティ（セクション2.2.2）余分なトラフィック（セクション2.2.2）非反転モード（セクション2.2.2）正規化（セクション2.2.2）は、余分なトラフィック（セクション2.2.2）と同様に、予約可能なトラフィック）プリエンプションの優先順位（セクション2.2.4）保護（セクション2.2.3）保護エンティティ（セクション2.2.2）保護スイッチング（セクション2.2.3）保護スイッチ時間（セクション2.2.4）回復（セクション2.2.2）回復による回復回復、回復（セクション2.2.3）回復エンティティ、保護エンティティ（セクション2.2.2）と同じ回復エンティティ（セクション2.2.2）回復（セクション2.2.3）修復優先度（セクション2.2.4）回復時間（セクション2.2.4）リバートモード（セクション2.2.2）共有リスクグループ（SRG）（セクション2.2.2）生存可能性（セクション2.2.1）作業エンティティ（セクション2.2.2）
Survivability is the capability of a network to maintain service continuity in the presence of faults within the network [6]. Survivability mechanisms such as protection and restoration are implemented either on a per-link basis, on a per-path basis, or throughout an entire network to alleviate service disruption at affordable costs. The degree of survivability is determined by the network's capability to survive single failures, multiple failures, and equipment failures.
生存性とは、ネットワーク内の障害の存在下でサービスの継続性を維持するネットワークの能力です[6]。保護や修復などの生存可能性メカニズムは、リンクごと、パスごとに、またはネットワーク全体で、または手頃なコストでサービスの混乱を軽減するために、ネットワーク全体で実装されます。生存性の程度は、単一の障害、複数の障害、および機器の故障に耐えるネットワークの能力によって決定されます。
This document does not discuss the sequence of events of how network failures are monitored, detected, and mitigated. For more detail of this aspect, see [4]. Also, the repair process following a failure is out of the scope here.
このドキュメントでは、ネットワークの障害が監視、検出、および緩和された方法のイベントのシーケンスについては説明していません。この側面の詳細については、[4]を参照してください。また、障害後の修理プロセスはここでの範囲外です。
A working entity is the entity that is used to carry traffic in normal operation mode. Depending upon the context, an entity can be a channel or a transmission link in the physical layer, an Label Switched Path (LSP) in MPLS, or a logical bundle of one or more LSPs.
作業エンティティとは、通常の操作モードでトラフィックを運ぶために使用されるエンティティです。コンテキストに応じて、エンティティは、物理層のチャネルまたは伝送リンク、MPLSのラベルスイッチングパス（LSP）、または1つ以上のLSPの論理バンドルにすることができます。
A protection entity, also called backup entity or recovery entity, is the entity that is used to carry protected traffic in recovery operation mode, i.e., when the working entity is in error or has failed.
バックアップエンティティまたはリカバリエンティティとも呼ばれる保護エンティティは、回復操作モードで保護されたトラフィックを運ぶために使用されるエンティティです。つまり、作業エンティティが誤っているか、失敗した場合です。
Extra traffic, also referred to as preemptable traffic, is the traffic carried over the protection entity while the working entity is active. Extra traffic is not protected, i.e., when the protection entity is required to protect the traffic that is being carried over the working entity, the extra traffic is preempted.
先制的なトラフィックとも呼ばれる追加のトラフィックは、作業エンティティがアクティブである間に保護エンティティを介して運ばれるトラフィックです。追加のトラフィックは保護されていません。つまり、作業エンティティの上に運ばれているトラフィックを保護するために保護エンティティが必要な場合、追加のトラフィックが先取りされます。
A shared risk group (SRG) is a set of network elements that are collectively impacted by a specific fault or fault type. For example, a shared risk link group (SRLG) is the union of all the links on those fibers that are routed in the same physical conduit in a fiber-span network. This concept includes, besides shared conduit, other types of compromise such as shared fiber cable, shared right of way, shared optical ring, shared office without power sharing, etc. The span of an SRG, such as the length of the sharing for compromised outside plant, needs to be considered on a per fault basis. The concept of SRG can be extended to represent a "risk domain" and its associated capabilities and summarization for traffic engineering purposes. See [7] for further discussion.
共有リスクグループ（SRG）は、特定の障害または障害タイプによってまとめて影響を受けるネットワーク要素のセットです。たとえば、共有リスクリンクグループ（SRLG）は、繊維スパンネットワークの同じ物理的導管でルーティングされている繊維のすべてのリンクの結合です。この概念には、共有された導管に加えて、共有ファイバーケーブル、共有された権利、共有光学リング、パワーシェアリングなしの共有オフィスなど、他のタイプの妥協が含まれます。外部の植物は、障害ごとに考慮する必要があります。SRGの概念は、「リスクドメイン」とそれに関連する機能と交通工学の目的の要約を表すように拡張できます。詳細については、[7]を参照してください。
Normalization is the sequence of events and actions taken by a network that returns the network to the preferred state upon completing repair of a failure. This could include the switching or rerouting of affected traffic to the original repaired working entities or new routes. Revertive mode refers to the case where traffic is automatically returned to a repaired working entity (also called switch back).
正規化は、障害の修復を完了するとネットワークを優先状態に戻すネットワークが取得した一連のイベントとアクションです。これには、当初の修理された作業エンティティまたは新しいルートへの影響を受けたトラフィックの切り替えまたは再ルーティングが含まれます。復帰モードとは、トラフィックが自動的に修理された作業エンティティ（スイッチバックとも呼ばれます）に自動的に返される場合を指します。
Recovery is the sequence of events and actions taken by a network after the detection of a failure to maintain the required performance level for existing services (e.g., according to service level agreements) and to allow normalization of the network. The actions include notification of the failure followed by two parallel processes: (1) a repair process with fault isolation and repair of the failed components, and (2) a reconfiguration process using survivability mechanisms to maintain service continuity. In protection, reconfiguration involves switching the affected traffic from a working entity to a protection entity. In restoration, reconfiguration involves path selection and rerouting for the affected traffic.
回復とは、既存のサービスに必要なパフォーマンスレベルを維持できなかった後（サービスレベルの合意に従って）、ネットワークの正規化を許可した後、ネットワークが行った一連のイベントとアクションです。アクションには、2つの並列プロセスが続く障害の通知が含まれます。（1）失敗したコンポーネントの障害分離と修復を伴う修復プロセス、および（2）サービスの継続性を維持するための生存可能性メカニズムを使用した再構成プロセス。保護において、再構成には、影響を受けたトラフィックを作業エンティティから保護エンティティに切り替えることが含まれます。復元では、再構成には、影響を受けるトラフィックのパス選択と再ルーティングが含まれます。
Revertive mode is a procedure in which revertive action, i.e., switch back from the protection entity to the working entity, is taken once the failed working entity has been repaired. In non-revertive mode, such action is not taken. To minimize service interruption, switch-back in revertive mode should be performed at a time when there is the least impact on the traffic concerned, or by using the make-before-break concept.
復帰モードは、故障した作業エンティティが修復されたら、リバートアクション、つまり保護エンティティから作業エンティティに切り替える手順です。非反対モードでは、そのようなアクションは実行されません。サービスの中断を最小限に抑えるには、関係するトラフィックに最も影響が少ないとき、またはブレイク前の概念を使用して、リバートモードのスイッチバックを実行する必要があります。
Non-revertive mode is the case where there is no preferred path or it may be desirable to minimize further disruption of the service brought on by a revertive switching operation. A switch-back to the original working path is not desired or not possible since the original path may no longer exist after the occurrence of a fault on that path.
非リバートモードは、好みのパスがない場合、またはリバートスイッチング操作によってもたらされるサービスのさらなる混乱を最小限に抑えることが望ましい場合があります。元のパスがそのパスに障害が発生した後にもはや存在しない可能性があるため、元の作業パスへのスイッチバックは望ましくないか、不可能です。
Protection, also called protection switching, is a survivability technique based on predetermined failure recovery: as the working entity is established, a protection entity is also established. Protection techniques can be implemented by several architectures: 1+1, 1:1, 1:n, and m:n. In the context of SDH/SONET, they are referred to as Automatic Protection Switching (APS).
保護スイッチングとも呼ばれる保護は、所定の故障回復に基づいた生存性技術です。作業エンティティが確立されるにつれて、保護エンティティも確立されます。保護技術は、いくつかのアーキテクチャによって実装できます：1 1、1：1、1：n、およびm：n。SDH/SONETのコンテキストでは、それらは自動保護スイッチング（APS）と呼ばれます。
In the 1+1 protection architecture, a protection entity is dedicated to each working entity. The dual-feed mechanism is used whereby the working entity is permanently bridged onto the protection entity at the source of the protected domain. In normal operation mode, identical traffic is transmitted simultaneously on both the working and protection entities. At the other end (sink) of the protected domain, both feeds are monitored for alarms and maintenance signals. A selection between the working and protection entity is made based on some predetermined criteria, such as the transmission performance requirements or defect indication.
1 1保護アーキテクチャでは、保護エンティティが各作業エンティティに専念しています。デュアルフィードメカニズムが使用され、作業エンティティが保護されたドメインのソースで保護エンティティに永久に架橋されます。通常の動作モードでは、作業エンティティと保護エンティティの両方で同時に同時トラフィックが送信されます。保護されたドメインのもう一方の端（シンク）では、両方のフィードがアラームとメンテナンス信号について監視されます。作業エンティティと保護エンティティの間の選択は、送信パフォーマンスの要件や欠陥の表示など、いくつかの所定の基準に基づいて行われます。
In the 1:1 protection architecture, a protection entity is also dedicated to each working entity. The protected traffic is normally transmitted by the working entity. When the working entity fails, the protected traffic is switched to the protection entity. The two ends of the protected domain must signal detection of the fault and initiate the switchover.
1：1の保護アーキテクチャでは、保護エンティティも各作業エンティティに専念しています。保護されたトラフィックは通常、作業エンティティによって送信されます。作業エンティティが失敗すると、保護されたトラフィックが保護エンティティに切り替えられます。保護されたドメインの両端は、障害の検出を信号し、スイッチオーバーを開始する必要があります。
In the 1:n protection architecture, a dedicated protection entity is shared by n working entities. In this case, not all of the affected traffic may be protected.
1：n保護アーキテクチャでは、専用の保護エンティティがN作業エンティティによって共有されています。この場合、影響を受けるトラフィックのすべてが保護されるわけではありません。
The m:n architecture is a generalization of the 1:n architecture. Typically m <= n, where m dedicated protection entities are shared by n working entities.
M：nアーキテクチャは、1：nアーキテクチャの一般化です。通常、M <= nで、M専用の保護エンティティはN作業エンティティによって共有されます。
Restoration, also referred to as recovery by rerouting [4], is a survivability technique that establishes new paths or path segments on demand, for restoring affected traffic after the occurrence of a fault. The resources in these alternate paths are the currently unassigned (unreserved) resources in the same layer. Preemption of extra traffic may also be used if spare resources are not available to carry the higher-priority protected traffic. As initiated by detection of a fault on the working path, the selection of a recovery path may be based on preplanned configurations, network routing policies, or current network status such as network topology and fault information. Signaling is used for establishing the new paths to bypass the fault. Thus, restoration involves a path selection process followed by rerouting of the affected traffic from the working entity to the recovery entity.
再ルーティングによる回復とも呼ばれる修復[4]は、障害の発生後に影響を受けるトラフィックを回復するために、需要のある新しいパスまたはパスセグメントを確立する生存可能性技術です。これらの代替パスのリソースは、同じレイヤーの現在割り当てられていない（予約されていない）リソースです。より優先順位の保護されたトラフィックを運ぶために予備のリソースが利用できない場合は、追加のトラフィックの先制も使用できます。作業経路での障害の検出によって開始されるように、回復パスの選択は、事前に定められた構成、ネットワークルーティングポリシー、またはネットワークトポロジや障害情報などの現在のネットワークステータスに基づいている場合があります。シグナリングは、障害をバイパスするための新しいパスを確立するために使用されます。したがって、修復には、パス選択プロセスに続いて、影響を受けたトラフィックが作業エンティティから回復エンティティへの再ルーティングが含まれます。
Protection switch time is the time interval from the occurrence of a network fault until the completion of the protection-switching operations. It includes the detection time necessary to initiate the protection switch, any hold-off time to allow for the interworking of protection schemes, and the switch completion time.
保護スイッチ時間は、ネットワーク障害の発生から保護操作操作の完了までの時間間隔です。保護スイッチを開始するのに必要な検出時間、保護スキームのインターワーキングを可能にするためのホールドオフ時間、およびスイッチの完了時間が含まれます。
Restoration time is the time interval from the occurrence of a network fault to the instant when the affected traffic is either completely restored, or until spare resources are exhausted, and/or no more extra traffic exists that can be preempted to make room.
復元時間は、影響を受けたトラフィックが完全に復元されるか、予備のリソースが使い果たされるまで、および/または部屋を作るために先制する余分なトラフィックが存在しないときのインスタントまでのネットワーク障害の発生からの時間間隔です。
Restoration priority is a method of giving preference to protect higher-priority traffic ahead of lower-priority traffic. Its use is to help determine the order of restoring traffic after a failure has occurred. The purpose is to differentiate service restoration time as well as to control access to available spare capacity for different classes of traffic.
回復の優先順位は、より低い範囲のトラフィックよりも優先順位のトラフィックを保護する優先権を与える方法です。その使用は、障害が発生した後にトラフィックを回復する順序を決定するのに役立ちます。目的は、サービスの復元時間を区別し、さまざまなクラスのトラフィックで利用可能な予備容量へのアクセスを制御することです。
Preemption priority is a method of determining which traffic can be disconnected in the event that not all traffic with a higher restoration priority is restored after the occurrence of a failure.
プリエンプションの優先順位は、障害の発生後により高い回復優先度のあるすべてのトラフィックが回復していない場合に、どのトラフィックを切断できるかを決定する方法です。
In a survivable network design, spare capacity and diversity must be built into the network from the beginning to support some degree of self-healing whenever failures occur. A common strategy is to associate each working entity with a protection entity having either dedicated resources or shared resources that are pre-reserved or reserved-on-demand. According to the methods of setting up a protection entity, different approaches to providing survivability can be classified. Generally, protection techniques are based on having a dedicated protection entity set up prior to failure. Such is not the case in restoration techniques, which mainly rely on the use of spare capacity in the network. Hence, in terms of trade-offs, protection techniques usually offer fast recovery from failure with enhanced availability, while restoration techniques usually achieve better resource utilization.
生存可能なネットワーク設計では、障害が発生するたびにある程度の自己治癒をサポートするために、スペア容量と多様性を最初からネットワークに組み込む必要があります。一般的な戦略は、各作業エンティティを、専用のリソースまたは事前に予約されたリソースまたは需要のあるリソースを共有するリソースを持つ保護エンティティと関連付けることです。保護エンティティを設定する方法によれば、生存性を提供するためのさまざまなアプローチを分類できます。一般に、保護技術は、障害前に専用の保護エンティティを設定することに基づいています。これは、主にネットワークでの予備容量の使用に依存している修復技術には当てはまりません。したがって、トレードオフの観点から、保護技術は通常、可用性が向上した故障からの迅速な回復を提供しますが、回復技術は通常、より良いリソース利用を実現します。
A 1+1 protection architecture is rather expensive since resource duplication is required for the working and protection entities. It is generally used for specific services that need a very high availability.
作業および保護エンティティには、リソースの複製が必要なため、1 1保護アーキテクチャはかなり高価です。通常、非常に高い可用性を必要とする特定のサービスに使用されます。
A 1:1 architecture is inherently slower in recovering from failure than a 1+1 architecture since communication between both ends of the protection domain is required to perform the switch-over operation. An advantage is that the protection entity can optionally be used to carry low-priority extra traffic in normal operation, if traffic preemption is allowed. Packet networks can pre-establish a protection path for later use with pre-planned but not pre-reserved capacity. That is, if no packets are sent onto a protection path, then no bandwidth is consumed. This is not the case in transmission networks like optical or TDM where path establishment and resource reservation cannot be decoupled.
1：1のアーキテクチャは、保護ドメインの両端間の通信がスイッチオーバー操作を実行するために必要であるため、1 1アーキテクチャよりも故障から回復するのが本質的に遅くなります。利点は、トラフィックの先制が許可されている場合、保護エンティティをオプションで使用して、通常の操作で低優先度の追加トラフィックを運ぶことができることです。パケットネットワークは、事前に計画されていないが事前に予約されていない容量で、後で使用するための保護パスを事前に確立できます。つまり、保護パスにパケットが送信されない場合、帯域幅は消費されません。これは、PATHの確立とリソースの予約を分離できない光学型やTDMなどのトランスミッションネットワークではそうではありません。
In the 1:n protection architecture, traffic is normally sent on the working entities. When multiple working entities have failed simultaneously, only one of them can be restored by the common protection entity. This contention could be resolved by assigning a different preemptive priority to each working entity. As in the 1:1 case, the protection entity can optionally be used to carry preemptable traffic in normal operation.
1：n保護アーキテクチャでは、通常、作業エンティティにトラフィックが送信されます。複数の作業エンティティが同時に失敗した場合、共通の保護エンティティによって復元できるのはそのうちの1つだけです。この競合は、各作業エンティティに異なる先制優先度を割り当てることによって解決できます。1：1の場合と同様に、保護エンティティはオプションで使用されて、通常の動作で先制トラフィックを運ぶことができます。
While the m:n architecture can improve system availability with small cost increases, it has rarely been implemented or standardized.
M：nアーキテクチャは、わずかなコストの増加とともにシステムの可用性を向上させることができますが、実装されたり標準化されたりすることはめったにありません。
When compared with protection mechanisms, restoration mechanisms are generally more frugal as no resources are committed until after the fault occurs and the location of the fault is known. However, restoration mechanisms are inherently slower, since more must be done following the detection of a fault. Also, the time it takes for the dynamic selection and establishment of alternate paths may vary, depending on the amount of traffic and connections to be restored, and is influenced by the network topology, technology employed, and the type and severity of the fault. As a result, restoration time tends to be more variable than the protection switch time needed with pre-selected protection entities. Hence, in using restoration mechanisms, it is essential to use restoration priority to ensure that service objectives are met cost-effectively.
保護メカニズムと比較すると、障害が発生し、障害の位置がわかっているまでリソースがコミットされないため、回復メカニズムは一般により質素です。ただし、障害の検出後にさらに多くのことを行う必要があるため、回復メカニズムは本質的に遅くなります。また、代替パスの動的な選択と確立にかかる時間は、回復するトラフィックと接続の量によって異なる場合があり、ネットワークトポロジ、採用された技術、および障害の種類と重大度の影響を受けます。その結果、復元時間は、事前に選択された保護エンティティで必要な保護スイッチ時間よりも変動する傾向があります。したがって、修復メカニズムを使用する際には、回復の優先度を使用して、サービス目標が費用対効果に満たされるようにすることが不可欠です。
Once the network routing algorithms have converged after a fault, it may be preferable in some cases, to reoptimize the network by performing a reroute based on the current state of the network and network policies.
ネットワークルーティングアルゴリズムが障害の後に収束すると、ネットワークおよびネットワークポリシーの現在の状態に基づいて再ルートを実行することにより、ネットワークを再最適化することが望ましい場合があります。
Interoperable approaches to network survivability were determined to be an immediate requirement in packet networks as well as in SDH/SONET framed TDM networks. Not as pressing at this time were techniques that would cover all-optical networks (e.g., where framing is unknown), as the control of these networks in a multi-vendor environment appeared to have some other hurdles to first deal with. Also, not of immediate interest were approaches to coordinate or explicitly communicate survivability mechanisms across network layers (such as from a TDM or optical network to/from an IP network). However, a capability should be provided for a network operator to perform fault notification and to control the operation of survivability mechanisms among different layers. This may require the development of corresponding OAM functionality. However, such issues and those related to OAM are currently outside the scope of this document. (For proposed MPLS OAM requirements, see [8, 9]).
ネットワークの生存性に対する相互運用可能なアプローチは、パケットネットワークおよびSDH/SONETフレームTDMネットワークの即時の要件であると判断されました。現時点では、多面的なネットワークをカバーする技術（たとえば、フレーミングが不明な場合）ではなく、マルチベンダー環境でのこれらのネットワークの制御には、最初に対処する他のハードルがあるように見えました。また、ネットワークレイヤー全体で生存可能性メカニズムを調整または明示的に通信するアプローチは、直接的な関心事ではありませんでした（TDMや光学ネットワークなど）。ただし、ネットワークオペレーターが障害通知を実行し、異なるレイヤー間の生存可能性メカニズムの動作を制御する機能を提供する必要があります。これには、対応するOAM機能の開発が必要になる場合があります。ただし、そのような問題とOAMに関連する問題は現在、このドキュメントの範囲外です。（提案されたMPLS OAM要件については、[8、9]を参照）。
The initial scope is to address only "backhoe failures" in the inter-office connections of a service provider network. A link connection in the router layer is typically comprised of multiple spans in the lower layers. Therefore, the types of network failures that cause a recovery to be performed include link/span failures. However, linecard and node failures may not need to be treated any differently than their respective link/span failures, as a router failure may be represented as a set of simultaneous link failures.
初期範囲は、サービスプロバイダーネットワークのオフィス間接続における「バックホーの障害」のみに対処することです。ルーター層のリンク接続は、通常、下層の複数のスパンで構成されます。したがって、回復を引き起こすネットワーク障害のタイプには、リンク/スパン障害が含まれます。ただし、ルーターの障害は同時リンク障害のセットとして表される可能性があるため、リンカーとノードの障害をそれぞれのリンク/スパン障害とは異なる方法で処理する必要がない場合があります。
Depending on the actual network configuration, drop-side interface (e.g., between a customer and an access router, or between a router and an optical cross-connect) may be considered either inter-domain or inter-layer. Another inter-domain scenario is the use of intra-office links for interconnecting a metro network and a core network, with both networks being administered by the same service provider. Failures at such interfaces may be similarly protected by the mechanisms of this section.
実際のネットワーク構成に応じて、ドロップサイドインターフェイス（例：顧客とアクセスルーター間、またはルーターと光学クロスコネクト間）は、ドメイン間または層間層のいずれかと見なされる場合があります。もう1つのドメイン間シナリオは、メトロネットワークとコアネットワークを相互接続するためのオフィス内リンクの使用であり、両方のネットワークが同じサービスプロバイダーによって管理されています。このようなインターフェイスでの障害は、このセクションのメカニズムによって同様に保護される場合があります。
Other more complex failure mechanisms such as systematic control-plane failure, configuration error, or breach of security are not within the scope of the survivability mechanisms discussed in this document. Network impairment such as congestion that results in lower throughput are also not covered.
系統的な制御プレーン障害、構成エラー、セキュリティ違反などの他のより複雑な障害メカニズムは、このドキュメントで説明されている生存可能性メカニズムの範囲内ではありません。スループットの低下をもたらす混雑などのネットワーク障害もカバーされていません。
In this protection mode, the head end of a working connection establishes a protection connection to the destination. There should be the ability to maintain relative restoration priorities between working and protection connections, as well as between different classes of protection connections.
この保護モードでは、作業接続のヘッドエンドが目的地への保護接続を確立します。さまざまなクラスの保護接続間で、作業と保護接続の間に相対的な回復の優先順位を維持する能力があるはずです。
In normal operation, traffic is only sent on the working connection, though the ability to signal that traffic will be sent on both connections (1+1 Path for signaling purposes) would be valuable in non-packet networks. Some distinction between working and protection connections is likely, either through explicit objects, or preferably through implicit methods such as general classes or priorities. Head ends need the ability to create connections that are as failure disjoint as possible from each other. This requires SRG information that can be generally assigned to either nodes or links and propagated through the control or management plane. In this mechanism, capacity in the protection connection is pre-established, however it should be capable of carrying preemptable extra traffic in non-packet networks. When protection capacity is called into service during recovery, there should be the ability to promote the protection connection to working status (for non-revertive mode operation) with some form of make-before-break capability.
通常の操作では、トラフィックは作業接続にのみ送信されますが、両方の接続（シグナリング目的のために1 1パス）にトラフィックが送信されることを信号する機能は、パケット以外のネットワークで価値があります。作業と保護の接続との区別は、明示的なオブジェクトを介して、または好ましくは一般的なクラスや優先順位などの暗黙的な方法を介して可能です。ヘッドエンドには、互いに可能な限り失敗する接続を作成する機能が必要です。これには、一般にノードまたはリンクに割り当てられ、制御プレーンまたは管理プレーンを介して伝播できるSRG情報が必要です。このメカニズムでは、保護接続の容量は事前に確立されていますが、非パケットネットワークで先制的な追加トラフィックを運ぶことができるはずです。回復中に保護能力がサービスに呼び出される場合、何らかの形のメイクブレーク機能を備えた作業ステータス（非反転モード操作の場合）への保護接続を促進する能力があるはずです。
Similar to the above 1:1 protection with pre-established capacity, the protection connection in this case is also pre-signaled. The difference is in the way protection capacity is assigned. With pre-planned capacity, the mechanism supports the ability for the protection capacity to be shared, or "double-booked". Operators need the ability to provision different amounts of protection capacity according to expected failure modes and service level agreements. Thus, an operator may wish to provision sufficient restoration capacity to handle a single failure affecting all connections in an SRG, or may wish to provision less or more restoration capacity. Mechanisms should be provided to allow restoration capacity on each link to be shared by SRG-disjoint failures. In a sense, this is 1:1 from a path perspective; however, the protection capacity in the network (on a link by link basis) is shared in a 1:n fashion, e.g., see the proposals in [10, 11]. If capacity is planned but not allocated, some form of signaling could be required before traffic may be sent on protection connections, especially in TDM networks.
事前に確立された容量を備えた上記の1：1保護と同様に、この場合の保護接続も事前に署名されています。違いは、保護能力が割り当てられる方法です。事前に計画された容量により、メカニズムは保護能力を共有する能力、または「二重予約」をサポートします。オペレーターは、予想される障害モードとサービスレベル契約に応じて、さまざまな量の保護能力を提供する機能が必要です。したがって、オペレーターは、SRG内のすべての接続に影響を与える単一の障害を処理するのに十分な復元能力を提供したい場合、またはより少ないまたはより多くの修復能力を提供することを希望する場合があります。各リンクの回復能力をSRG-Disjoint障害によって共有できるように、メカニズムを提供する必要があります。ある意味では、これはパスの観点から1：1です。ただし、ネットワーク内の保護能力（リンクごとに）は、1：nファッションで共有されます。たとえば、[10、11]の提案を参照してください。容量が計画されているが割り当てられていない場合、特にTDMネットワークでは、保護接続でトラフィックを送信する前に、何らかの形のシグナル伝達が必要になる可能性があります。
The use of this approach improves network resource utilization, but may require more careful planning. So, initial deployment might be based on 1:1 path protection with pre-established capacity and the local restoration mechanism to be described next.
このアプローチを使用すると、ネットワークリソースの使用率が向上しますが、より慎重な計画が必要になる場合があります。したがって、初期展開は、事前に確立された容量と次に説明するローカル回復メカニズムを備えた1：1のパス保護に基づいている可能性があります。
Due to the time impact of signal propagation, dynamic recovery of an entire path may not meet the service requirements of some networks. The solution to this is to restore connectivity of the link or span in immediate proximity to the fault, e.g., see the proposals in [12, 13]. At a minimum, this approach should be able to protect against connectivity-type SRGs, though protecting against node-based SRGs might be worthwhile. Also, this approach is applicable to support restoration on the inter-domain and inter-layer interconnection scenarios using intra-office links as described in the Scope Section.
信号伝播の時間の影響により、パス全体の動的回復は、一部のネットワークのサービス要件を満たしていない場合があります。これに対する解決策は、障害に即座に近接してリンクまたはスパンの接続性を回復することです。たとえば、[12、13]の提案を参照してください。少なくとも、このアプローチは接続型SRGを保護できるはずですが、ノードベースのSRGから保護することは価値があるかもしれません。また、このアプローチは、スコープセクションで説明されているように、オフィス内リンクを使用して、ドメイン間および層間相互接続シナリオの修復をサポートするために適用できます。
Head end systems must have some control as to whether their connections are candidates for or excluded from local restoration. For example, best-effort and preemptable traffic may be excluded from local restoration; they only get restored if there is bandwidth available. This type of control may require the definition of an object in signaling.
ヘッドエンドシステムは、接続がローカル回復の候補であるか除外されているかについて、ある程度制御する必要があります。たとえば、ベストエフォルトで先制的なトラフィックは、ローカルの復元から除外される場合があります。利用可能な帯域幅がある場合にのみ復元されます。このタイプのコントロールには、シグナリングにオブジェクトの定義が必要になる場合があります。
Since local restoration may be suboptimal, a means for head end systems to later perform path-level re-grooming must be supported for this approach.
局所的な復元は最適ではない可能性があるため、このアプローチでは、ヘッドエンドシステムが後でパスレベルの再室を実行する手段をサポートする必要があります。
In this approach, connections that are impacted by a fault are rerouted by the originating network element upon notification of connection failure. Such a source-based approach is efficient for network resources, but typically takes longer to accomplish restoration. It does not involve any new mechanisms. It merely is a mention of another common approach to protecting against faults in a network.
このアプローチでは、障害の影響を受ける接続は、接続障害の通知時に発信ネットワーク要素によって再ルーティングされます。このようなソースベースのアプローチは、ネットワークリソースにとって効率的ですが、通常、回復を達成するのに時間がかかります。新しいメカニズムは含まれません。それは、ネットワーク内の障害から保護するための別の一般的なアプローチについての言及にすぎません。
With service continuity under failure as a goal, a network is "survivable" if, in the face of a network failure, connectivity is interrupted for a "brief" period and then recovered before the network failure ends. The length of this interrupted period is dependent upon the application supported. Here are some typical applications and considerations that drive the requirements for an acceptable protection switch time or restoration time:
目標として障害下にあるサービスの継続性により、ネットワークが「短い」期間にわたって接続性が中断され、ネットワークの障害が終了する前に回復する場合、ネットワークは「生存可能」になります。この中断された期間の長さは、サポートされているアプリケーションに依存します。許容可能な保護スイッチ時間または復元時間の要件を推進するいくつかの典型的なアプリケーションと考慮事項を以下に示します。
- Best-effort data: recovery of network connectivity by rerouting at the IP layer would be sufficient - Premium data service: need to meet TCP timeout or application protocol timer requirements - Voice: call cutoff is in the range of 140 msec to 2 sec (the time that a person waits after interruption of the speech path before hanging up or the time that a telephone switch will disconnect a call) - Other real-time service (e.g., streaming, fax) where an interruption would cause the session to terminate - Mission-critical applications that cannot tolerate even brief interruptions, for example, real-time financial transactions
- ベストエフォルトデータ：IPレイヤーでの再ルーティングによるネットワーク接続の回復で十分です - プレミアムデータサービス：TCPタイムアウトまたはアプリケーションプロトコルタイマー要件を満たす必要があります - 音声：コールカットオフは140ミリ秒から2秒の範囲です（ハングアップする前にスピーチパスを中断した後に人が待つ時間、または電話スイッチが電話を切断する時間） - 中断がセッションを終了させる他のリアルタイムサービス（たとえば、ストリーミング、ファックス） - ミッション - たとえば、リアルタイムの金融取引など、短時間の中断を容認できない批判的なアプリケーション
The approach to picking the types of survivability mechanisms recommended was to consider a spectrum of mechanisms that can be used to protect traffic with varying characteristics of survivability and speed of protection/restoration, and then attempt to select a few general points that provide some coverage across that spectrum. The focus of this work is to provide requirements to which a small set of detailed proposals may be developed, allowing the operator some (limited) flexibility in approaches to meeting their design goals in engineering multi-vendor networks. Requirements of different applications as listed in the previous sub-section were discussed generally, however none on the team would likely attest to the scientific merit of the ability of the timing bounds below to meet any specific application's needs. A few assumptions include:
推奨される生存可能性メカニズムの種類を選択するアプローチは、生存可能性と保護/修復のさまざまな特性でトラフィックを保護するために使用できるメカニズムのスペクトルを検討し、その後、何らかのカバレッジを提供するいくつかの一般的なポイントを選択しようとすることでした。そのスペクトル。この作業の焦点は、小さな一連の詳細な提案が開発される可能性のある要件を提供し、エンジニアリングマルチベンダーネットワークの設計目標を達成するためのアプローチにおける（限られた）柔軟性をオペレーターに提供することです。前のサブセクションにリストされているさまざまなアプリケーションの要件が一般的に議論されましたが、チーム上の科学的メリットを、特定のアプリケーションのニーズを満たすために以下のタイミング境界の能力の科学的メリットを証明するものはありませんでした。いくつかの仮定には、次のことが含まれます。
1. Approaches in which protection switch without propagation of information are likely to be faster than those that do require some form of fault notification to some or all elements in a network.
1. 情報の伝播なしに保護を切り替えるアプローチは、ネットワーク内の一部またはすべての要素に何らかの形の障害通知を必要とするものよりも速くなる可能性が高い。
2. Approaches that require some form of signaling after a fault will also likely suffer some timing impact.
2. 障害の後に何らかの形のシグナル伝達を必要とするアプローチも、タイミングの影響を与える可能性があります。
Proposed timing bounds for different survivability mechanisms are as follows (all bounds are exclusive of signal propagation):
さまざまな生存可能性メカニズムの提案されたタイミング境界は次のとおりです（すべての境界は信号伝播を除く）。
1:1 path protection with pre-established capacity: 100-500 ms
1:1 path protection with pre-planned capacity: 100-750 ms
Local restoration: 50 ms
Path restoration: 1-5 seconds
To ensure that the service requirements for different applications can be met within the above timing bounds, restoration priority must be implemented to determine the order in which connections are restored (to minimize service restoration time as well as to gain access to available spare capacity on the best paths). For example, mission critical applications may require high restoration priority. At the fiber layer, instead of specific applications, it may be possible that priority be given to certain classifications of customers with their traffic types enclosed within the customer aggregate. Preemption priority should only be used in the event that not all connections can be restored, in which case connections with lower preemption priority should be released. Depending on a service provider's strategy in provisioning network resources for backup, preemption may or may not be needed in the network.
上記のタイミング境界内でさまざまなアプリケーションのサービス要件を満たすことができるようにするには、接続が復元される順序を決定するために復元の優先順位を実装する必要があります（サービスの復元時間を最小限に抑え、利用可能な予備容量にアクセスできるようにします。最高のパス）。たとえば、ミッションクリティカルアプリケーションには、高い回復の優先順位が必要になる場合があります。ファイバー層では、特定のアプリケーションではなく、顧客の総合にトラフィックタイプが囲まれている顧客の特定の分類が優先される可能性があります。先制の優先順位は、すべての接続を復元できるわけではない場合にのみ使用する必要があります。バックアップのためのネットワークリソースのプロビジョニングにおけるサービスプロバイダーの戦略に応じて、ネットワークでプリエンプションが必要になる場合と必要でない場合があります。
A common design goal for networks with multiple technological layers is to provide the desired level of service in the most cost-effective manner. Multilayer survivability may allow the optimization of spare resources through the improvement of resource utilization by sharing spare capacity across different layers, though further investigations are needed. Coordination during recovery among different network layers (e.g., IP, SDH/SONET, optical layer) might necessitate development of vertical hierarchy. The benefits of providing survivability mechanisms at multiple layers, and the optimization of the overall approach, must be weighed with the associated cost and service impacts.
複数の技術層を持つネットワークの一般的な設計目標は、最も費用対効果の高い方法で望ましいレベルのサービスを提供することです。多層の生存性により、さらなる調査が必要ですが、さまざまなレイヤー間で予備の容量を共有することにより、リソースの利用を改善することにより、予備のリソースを最適化することができます。さまざまなネットワークレイヤー間の回復中の調整（例：IP、SDH/SONET、光学層）は、垂直階層の開発を必要とする場合があります。複数の層で生存可能性メカニズムを提供する利点、および全体的なアプローチの最適化は、関連するコストとサービスの影響と比較検討する必要があります。
A default coordination mechanism for inter-layer interaction could be the use of nested timers and current SDH/SONET fault monitoring, as has been done traditionally for backward compatibility. Thus, when lower-layer recovery happens in a longer time period than higher-layer recovery, a hold-off timer is utilized to avoid contention between the different single-layer survivability schemes. In other words, multilayer interaction is addressed by having successively higher multiplexing levels operate at a protection/restoration time scale greater than the next lowest layer. This can impact the overall time to recover service. For example, if SDH/SONET protection switching is used, MPLS recovery timers must wait until SDH/SONET has had time to switch. Setting such timers involves a tradeoff between rapid recovery and creation of a race condition where multiple layers are responding to the same fault, potentially allocating resources in an inefficient manner.
層間相互作用のデフォルトの調整メカニズムは、ネストされたタイマーと現在のSDH/SONET障害監視の使用であり、伝統的に後方互換性のために行われていたようです。したがって、低層回復が高層回復よりも長い期間で発生する場合、異なる単一層の生存性スキーム間の競合を避けるために、ホールドオフタイマーが利用されます。言い換えれば、多層的な相互作用は、次の低層よりも大きい保護/修復時間スケールで動作する多重化レベルが連続的に動作することにより対処されます。これは、サービスを回復するための全体的な時間に影響を与える可能性があります。たとえば、SDH/SONET保護の切り替えを使用する場合、MPLS回復タイマーはSDH/SONETが切り替える時間があるまで待つ必要があります。このようなタイマーの設定には、迅速な回復と複数の層が同じ障害に応答し、非効率的な方法でリソースを割り当てる可能性のある人種条件の作成とのトレードオフが含まれます。
In other configurations where the lower layer does not have a restoration capability or is not expected to protect, say an unprotected SDH/SONET linear circuit, then there must be a mechanism for the lower layer to trigger the higher layer to take recovery actions immediately. This difference in network configuration means that implementations must allow for adjustment of hold-off timer values and/or a means for a lower layer to immediately indicate to a higher layer that a fault has occurred so that the higher layer can take restoration or protection actions.
下層に復元機能がないか、保護されていない他の構成では、保護されていないSDH/SONET線形回路など、保護することが予想されない場合、下層が高層をトリガーするメカニズムがすぐに回復アクションをとるメカニズムが必要です。ネットワーク構成のこの違いは、実装がホールドオフタイマーの値の調整を可能にし、下層層がすぐに障害が発生していることをすぐに示し、より高い層が回復または保護措置をとることができることを意味することを意味します。。
Furthermore, faults at higher layers should not trigger restoration or protection actions at lower layers [3, 4].
さらに、高層の障害は、下層での回復または保護措置を引き起こすべきではありません[3、4]。
It was felt that the current approach to coordination of survivability approaches currently did not have significant operational shortfalls. These approaches include protecting traffic solely at one layer (e.g., at the IP layer over linear WDM, or at the SDH/SONET layer). Where survivability mechanisms might be deployed at several layers, such as when a routed network rides a SDH/SONET protected network, it was felt that current coordination approaches were sufficient in many cases. One exception is the hold-off of MPLS recovery until the completion of SDH/SONET protection switching as described above. This limits the recovery time of fast MPLS restoration. Also, by design, the operations and mechanisms within a given layer tend to be invisible to other layers.
現在の生存可能性アプローチの調整に対する現在のアプローチには、現在の操作上の不足が重要ではないと感じられました。これらのアプローチには、1つのレイヤーのみでトラフィックを保護することが含まれます（例えば、線形WDM上のIPレイヤー、またはSDH/SONET層）。ルーティングされたネットワークがSDH/SONET保護ネットワークに乗るときなど、いくつかのレイヤーで生存性メカニズムが展開される場合がある場合、多くの場合、現在の調整アプローチで十分であると感じられました。1つの例外は、上記のようにSDH/SONET保護スイッチングが完了するまで、MPLS回復の保留です。これにより、MPLの速度回復の回復時間が制限されます。また、設計上、特定のレイヤー内の操作とメカニズムは、他の層には見えない傾向があります。
As more pressing requirements for survivability and horizontal hierarchy for edge-to-edge signaling are met with technical proposals, it is believed that the benefits of merging (in some manner) the control planes of multiple layers will be outlined. When these benefits are self-evident, it would then seem to be the right time to review whether vertical hierarchy mechanisms are needed, and what the requirements might be. For example, a future requirement might be to provide a better match between the recovery requirements of IP networks with the recovery capability of optical transport. One such proposal is described in [14].
エッジとエッジへのシグナル伝達の生存可能性と水平階層のより差し迫った要件が技術的な提案で満たされているため、複数の層のコントロールプレーンが統合することの利点が概説されると考えられています。これらの利点が自明である場合、垂直階層メカニズムが必要かどうか、そして要件が何であるかを確認するのは適切な時期のようです。たとえば、将来の要件は、IPネットワークの回復要件と光学輸送の回復能力をよりよく一致させることです。そのような提案の1つは[14]で説明されています。
Efforts in the area of network hierarchy should focus on mechanisms that would allow more scalable edge-to-edge signaling, or signaling across networks with existing network hierarchy (such as multi-area OSPF). This appears to be a more urgent need than mechanisms that might be needed to interconnect networks at different layers.
ネットワーク階層の分野での努力は、よりスケーラブルなエッジ間のシグナル伝達を可能にするメカニズム、または既存のネットワーク階層（マルチエリアOSPFなど）を使用したネットワーク全体のシグナル伝達を可能にするメカニズムに焦点を当てる必要があります。これは、異なる層でネットワークを相互接続するために必要なメカニズムよりも緊急のニーズであるように見えます。
One reason for horizontal hierarchy is functionality (e.g., metro versus backbone). Geographic "islands" or partitions reduce the need for interoperability and make administration and operations less complex. Using a simpler, more interoperable, survivability scheme at metro/backbone boundaries is natural for many provider network architectures. In transmission networks, creating geographic islands of different vendor equipment has been done for a long time because multi-vendor interoperability has been difficult to achieve. Traditionally, providers have to coordinate the equipment on either end of a "connection," and making this interoperable reduces complexity. A provider should be able to concatenate survivability mechanisms in order to provide a "protected link" to the next higher level. Think of SDH/SONET rings connecting to TDM DXCs with 1+1 line-layer protection between the ADM and the DXC port. The TDM connection, e.g., a DS3, is protected but usually all equipment on each SDH/SONET ring is from a single vendor. The DXC cross connections are controlled by the provider and the ports are physically protected resulting in a highly available design. Thus, concatenation of survivability approaches can be used to cascade across a horizontal hierarchy. While not perfect, it is workable in the near to mid-term until multi-vendor interoperability is achieved.
水平階層の1つの理由は、機能性（例：メトロ対バックボーン）です。地理的な「島」またはパーティションにより、相互運用性の必要性が低下し、管理と運用が複雑になります。メトロ/バックボーンの境界でよりシンプルでより相互運用可能な生存可能性スキームを使用することは、多くのプロバイダーネットワークアーキテクチャでは自然です。トランスミッションネットワークでは、マルチベンダーの相互運用性を達成することが困難であるため、さまざまなベンダー機器の地理的島の作成が長い間行われてきました。伝統的に、プロバイダーは「接続」の両端で機器を調整する必要があり、この相互運用可能なものにすると、複雑さが減少します。プロバイダーは、次のより高いレベルに「保護されたリンク」を提供するために、生存性メカニズムを連結できる必要があります。ADMとDXCポートの間の1 1ラインレイヤー保護でTDM DXCに接続するSDH/SONETリングを考えてください。TDM接続、例えばDS3は保護されていますが、通常、各SDH/SONETリングのすべての機器は単一のベンダーからのものです。DXCクロス接続はプロバイダーによって制御され、ポートは物理的に保護されており、非常に利用可能な設計が行われます。したがって、生存可能性アプローチの連結を使用して、水平階層を横切るカスケードを使用できます。完璧ではありませんが、マルチベンダーの相互運用性が達成されるまで、中期近くから中期に実行可能です。
While the problems associated with multi-vendor interoperability may necessitate horizontal hierarchy as a practical matter in the near to mid-term (at least this has been the case in TDM networks), there should not be a technical reason for it in the standards developed by the IETF for core networks, or even most access networks. Establishing interoperability of survivability mechanisms between multi-vendor equipment in core IP networks is urgently required to enable adoption of IP as a viable core transport technology and to facilitate the traffic engineering of future multi-service IP networks [3].
マルチベンダーの相互運用性に関連する問題は、中期から中期における実用的な問題として水平階層を必要とする可能性がありますが（少なくともこれはTDMネットワークではそうでした）、開発された標準には技術的な理由はないはずですコアネットワークのIETF、またはほとんどのアクセスネットワークによって。コアIPネットワークのマルチベンダー機器間の生存可能性メカニズムの相互運用性を確立することは、実行可能なコアトランスポートテクノロジーとしてのIPの採用を可能にし、将来のマルチサービスIPネットワークのトラフィックエンジニアリングを促進するために緊急に必要です[3]。
Some of the largest service provider networks currently run a single area/level IGP. Some service providers, as well as many large enterprise networks, run multi-area Open Shortest Path First (OSPF) to gain increases in scalability. Often, this was from an original design, so it is difficult to say if the network truly required the hierarchy to reach its current size.
現在、最大のサービスプロバイダーネットワークの一部は、現在単一のエリア/レベルIGPを実行しています。一部のサービスプロバイダーと多くの大規模なエンタープライズネットワークは、最初にマルチアレアを開いた最短パス（OSPF）を実行して、スケーラビリティを増やします。多くの場合、これはオリジナルのデザインからのものなので、ネットワークが現在のサイズに到達するために階層を本当に要求したかどうかを言うのは困難です。
Some proposals on improved mechanisms to address network hierarchy have been suggested [15, 16, 17, 18, 19]. This document aims to provide the concrete requirements so that these and other proposals can first aim to meet some limited objectives.
ネットワーク階層に対処するための改善されたメカニズムに関するいくつかの提案が提案されています[15、16、17、18、19]。このドキュメントは、これらおよびその他の提案が最初にいくつかの限られた目的を満たすことを目的とすることができるように、具体的な要件を提供することを目的としています。
A primary driver for intra-domain horizontal hierarchy is signaling capabilities in the context of edge-to-edge VPNs, potentially across traffic-engineered data networks. There are a number of different approaches to layer 2 and layer 3 VPNs and they are currently being addressed by different emerging protocols in the provider-provisioned VPNs (e.g., virtual routers) and Pseudo Wire Edge-to-Edge Emulation (PWE3) efforts based on either MPLS and/or IP tunnels. These may or may not need explicit signaling from edge to edge, but it is a common perception that in order to meet SLAs, some form of edge-to-edge signaling may be required.
ドメイン内の水平階層の主要なドライバーは、潜在的にトラフィックエンジニアのデータネットワーク全体で、エッジからエッジへのVPNSのコンテキストでのシグナル伝達機能です。レイヤー2とレイヤー3 VPNにはさまざまなアプローチがあり、現在、プロバイダーがプロビジョニングしたVPN（仮想ルーターなど）の異なる新興プロトコルと、擬似ワイヤエッジとエッジのエミュレーション（PWE3）の取り組みに基づいたさまざまなプロトコルによって対処されています。MPLSおよび/またはIPトンネルのいずれか。これらは、エッジからエッジへの明示的なシグナル伝達を必要とするかもしれないし、そうでない場合がありますが、SLAを満たすためには、何らかの形のエッジからエッジへのシグナル伝達が必要になる可能性があるという一般的な認識です。
With a large number of edges (N), scalability is concerned with avoiding the O(N^2) properties of edge-to-edge signaling. However, the main issue here is not with the scalability of large amounts of signaling, such as in O(N^2) meshes with a "connection" between every edge-pair. This is because, even if establishing and maintaining connections is feasible in a large network, there might be an impact on core survivability mechanisms which would cause protection/restoration times to grow with N^2, which would be undesirable. While some value of N may be inevitable, approaches to reduce N (e.g. to pull in from the edge to aggregation points) might be of value.
多数のエッジ（n）では、スケーラビリティは、エッジツーエッジシグナル伝達のO（n^2）特性を回避することに関係しています。ただし、ここでの主な問題は、すべてのエッジペア間の「接続」とO（n^2）メッシュなど、大量のシグナル伝達のスケーラビリティではありません。これは、接続を大規模なネットワークで確立して維持することが実行可能であっても、n^2で保護/回復時間が成長するコア生存可能性メカニズムに影響がある可能性があるためです。nの価値は避けられない場合がありますが、nを減らすためのアプローチ（たとえば、エッジから集約ポイントに引き込むため）には価値があるかもしれません。
Thus, most service providers feel that O(N^2) meshes are not necessary for VPNs, and that the number of tunnels to support VPNs would be within the scalability bounds of current protocols and implementations. That may be the case, as there is currently a lack of ability to signal MPLS tunnels from edge to edge across IGP hierarchy, such as OSPF areas. This may require the development of signaling standards that support dynamic establishment and potentially the restoration of LSPs across a 2-level IGP hierarchy.
したがって、ほとんどのサービスプロバイダーは、o（n^2）メッシュはVPNには必要ではなく、VPNをサポートするトンネルの数は現在のプロトコルと実装のスケーラビリティ境界内にあると感じています。現在、OSPF領域などのIGP階層全体でMPLSトンネルをエッジからエッジへと信号化する能力が不足しているため、そうかもしれません。これには、動的な確立をサポートするシグナリング基準の開発と、2レベルのIGP階層全体のLSPの回復を潜在的にサポートする必要があります。
For routing scalability, especially in data applications, a major concern is the amount of processing/state that is required in the variety of network elements. If some nodes might not be able to communicate and process the state of every other node, it might be preferable to limit the information. There is one school of thought that says that the amount of information contained by a horizontal barrier should be significant, and that impacts this might have on optimality in route selection and ability to provide global survivability are accepted tradeoffs.
特にデータアプリケーションでのスケーラビリティをルーティングするために、主要な懸念は、さまざまなネットワーク要素に必要な処理/状態の量です。一部のノードが他のすべてのノードの状態を通信して処理できない場合は、情報を制限することが望ましい場合があります。水平方向の障壁に含まれる情報の量が重要であるべきであり、これがルートの選択における最適性とグローバルな生存可能性を提供する能力に影響を与える可能性があるという考えの1つの学校があります。
Mechanisms are required to allow for edge-to-edge signaling of connections through a network. One network scenario includes medium to large networks that currently have hierarchical interior routing such as multi-area OSPF or multi-level Intermediate System to Intermediate System (IS-IS). The primary context of this is edge-to-edge signaling, which is thought to be required to assure the SLAs for the layer 2 and layer 3 VPNs that are being carried across the network. Another possible context would be edge-to-edge signaling in TDM SDH/SONET networks with IP control, where metro and core networks again might be in a hierarchical interior routing domain.
ネットワークを介した接続のエッジとエッジへのシグナル伝達を可能にするには、メカニズムが必要です。1つのネットワークシナリオには、現在、マルチエリアOSPFや中間システムへのマルチレベルの中間システム（IS-IS）などの階層的インテリアルーティングを備えた中型から大規模なネットワークが含まれます。これの主なコンテキストは、エッジツーエッジシグナル伝達です。これは、ネットワーク全体で運ばれているレイヤー2とレイヤー3 VPNのSLAを保証するために必要であると考えられています。もう1つの可能なコンテキストは、IPコントロールを備えたTDM SDH/SONETネットワークでのエッジツーエッジシグナル伝達です。メトロとコアネットワークが再び階層的なインテリアルーティングドメインにある可能性があります。
To support edge-to-edge signaling in the above network scenarios within the framework of existing horizontal hierarchies, current traffic engineering (TE) methods [20, 6] may need to be extended. Requirements for multi-area TE need to be developed to provide guidance for any necessary protocol extensions.
既存の水平階層のフレームワーク内の上記のネットワークシナリオでエッジとエッジへのシグナリングをサポートするには、現在のトラフィックエンジニアリング（TE）メソッド[20、6]を拡張する必要がある場合があります。必要なプロトコル拡張のガイダンスを提供するために、マルチアレアTEの要件を開発する必要があります。
When horizontal hierarchy exists in a network technology layer, a question arises as to how survivability can be provided along a connection that crosses hierarchical boundaries.
ネットワークテクノロジーレイヤーに水平階層が存在する場合、階層境界を越えて生存性がどのように提供されるかについて疑問が生じます。
In designing protocols to meet the requirements of hierarchy, an approach to consider is that boundaries are either clean, or are of minimal value. However, the concept of network elements that participate on both sides of a boundary might be a consideration (e.g., OSPF ABRs). That would allow for devices on either side to take an intra-area approach within their region of knowledge, and for the ABR to do this in both areas, and splice the two protected connections together at a common point (granted it is a common point of failure now). If the limitations of this approach start to appear in operational settings, then perhaps it would be time to start thinking about route-servers and signaling propagated directives. However, one initial approach might be to signal through a common border router, and to consider the service as protected as it consists of a concatenated set of connections which are each protected within their area. Another approach might be to have a least common denominator mechanism at the boundary, e.g., 1+1 port protection. There should also be some standardized means for a survivability scheme on one side of such a boundary to communicate with the scheme on the other side regarding the success or failure of the recovery action. For example, if a part of a "connection" is down on one side of such a boundary, there is no need for the other side to recover from failures.
階層の要件を満たすためにプロトコルを設計する際に、考慮すべきアプローチは、境界がきれいであるか、最小値であるということです。ただし、境界の両側に参加するネットワーク要素の概念は、考慮事項である可能性があります（例：OSPF ABRS）。これにより、両側のデバイスは、知識の領域内でエリア内アプローチを取ることができ、ABRは両方の領域でこれを行い、共通点で2つの保護された接続を一緒にスプライスできます（一般的なポイントであると認められます今の失敗の）。このアプローチの制限が運用設定に表示され始めた場合、おそらくルートサーバーと伝播された指示についてのシグナリングについて考え始める時が来るでしょう。ただし、最初のアプローチの1つは、共通の境界線ルーターを介してシグナルを合わせ、それぞれがそれぞれ地域内で保護されている接続の連結セットで構成されるため、保護されていると考えることです。別のアプローチは、境界で最も一般的な分母メカニズムを持つことです。たとえば、1 1ポート保護などです。また、回復アクションの成功または失敗に関して、反対側のスキームと通信するために、そのような境界の片側に生存可能性スキームの標準化された手段があるはずです。たとえば、「接続」の一部がそのような境界の片側にある場合、反対側が障害から回復する必要はありません。
In summary, at this time, approaches as described above that allow concatenation of survivability schemes across hierarchical boundaries seem sufficient.
要約すると、現時点では、上記のように、階層境界を越えた生存可能性スキームの連結を十分にできるようにするアプローチが十分であると思われます。
The set of SRGs that are defined for a network under a common administrative control and the corresponding assignment of these SRGs to nodes and links within the administrative control is sensitive information and needs to be protected. An SRG is an acknowledgement that nodes and links that belong to an SRG are susceptible to a common threat. An adversary with access to information contained in an SRG could use that information to design an attack, determine the scope of damage caused by the attack and, therefore, be used to maximize the effect of an attack.
共通の管理制御下でネットワークに対して定義されているSRGのセットと、これらのSRGのノードと管理制御内のリンクへの対応する割り当ては、機密情報であり、保護する必要があります。SRGは、SRGに属するノードとリンクが一般的な脅威に敏感であることを認めることです。SRGに含まれる情報にアクセスできる敵は、その情報を使用して攻撃を設計し、攻撃によって引き起こされる損傷の範囲を決定するため、攻撃の効果を最大化するために使用できます。
The label used to refer to a particular SRG must allow for an encoding such that sensitive information such as physical location, function, purpose, customer, fault type, etc. is not readily discernable by unauthorized users.
特定のSRGを参照するために使用されるラベルは、物理的位置、機能、目的、顧客、障害タイプなどの機密情報が許可されていないユーザーが容易に識別できないようにエンコードを許可する必要があります。
SRG information that is propagated through the control and management plane should allow for an encryption mechanism. An example of an approach would be to use IPSEC [21] on all packets carrying SRG information.
制御および管理プレーンを介して伝播されるSRG情報は、暗号化メカニズムを可能にするはずです。アプローチの例は、SRG情報を運ぶすべてのパケットでIPSEC [21]を使用することです。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] K. Owens, V. Sharma, and M. Oommen, "Network Survivability Considerations for Traffic Engineered IP Networks", Work in Progress.
[3] K. Owens、V。Sharma、およびM. Oommen、「トラフィックエンジニアリングIPネットワークのネットワークサバイバビリティの考慮事項」は、進行中の作業です。
[4] V. Sharma, B. Crane, S. Makam, K. Owens, C. Huang, F. Hellstrand, J. Weil, L. Andersson, B. Jamoussi, B. Cain, S. Civanlar, and A. Chiu, "Framework for MPLS-based Recovery", Work in Progress.
[4] V. Sharma、B。Crane、S。Makam、K。Owens、C。Huang、F。Hellstrand、J。Weil、L。Andersson、B。Mamoussi、B。Cain、S。Civanlar、およびA. Chiu、MPLSベースの回復のフレームワーク」、進行中の作業。
[5] M. Thorup, "Fortifying OSPF/ISIS Against Link Failure", http://www.research.att.com/~mthorup/PAPERS/lf_ospf.ps
[5] M. Thorup、「リンク障害に対するOSPF/ISISの強化」、http：//www.research.att.com/~mthorup/papers/lf_ospf.ps
[6] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
[6] Awduche、D.、Chiu、A.、Elwalid、A.、Widjaja、I。およびX. Xiao、「概要とインターネットトラフィックエンジニアリングの原則」、RFC 3272、2002年5月。
[7] S. Dharanikota, R. Jain, D. Papadimitriou, R. Hartani, G. Bernstein, V. Sharma, C. Brownmiller, Y. Xue, and J. Strand, "Inter-domain routing with Shared Risk Groups", Work in Progress.
[7] S. Dharanikota、R。Jain、D。Papadimitriou、R。Hartani、G。Bernstein、V。Sharma、C。Brownmiller、Y。Xue、およびJ. Strand、「共有リスクグループとのドメイン間ルーティング」、進捗。
[8] N. Harrison, P. Willis, S. Davari, E. Cuevas, B. Mack-Crane, E. Franze, H. Ohta, T. So, S. Goldfless, and F. Chen, "Requirements for OAM in MPLS Networks," Work in Progress.
[8] N.ハリソン、P。ウィリス、S。ダバリ、E。クエバス、B。マッククレーン、E。フランゼ、H。オタ、T。、「進行中の作業。
[9] D. Allan and M. Azad, "A Framework for MPLS User Plane OAM," Work in Progress.
[9] D.アランとM.アザド、「MPLSユーザープレーンOAMのフレームワーク」、進行中の作業。
[10] S. Kini, M. Kodialam, T.V. Lakshman, S. Sengupta, and C. Villamizar, "Shared Backup Label Switched Path Restoration," Work in Progress.
[10] S. Kini、M。Kodialam、T.V。Lakshman、S。Sengupta、およびC. Villamizar、「共有バックアップラベルスイッチドパス修復」、作業進行中。
[11] G. Li, C. Kalmanek, J. Yates, G. Bernstein, F. Liaw, and V. Sharma, "RSVP-TE Extensions For Shared-Mesh Restoration in Transport Networks", Work in Progress.
[11] G. Li、C。Kalmanek、J。Yates、G。Bernstein、F。Liaw、およびV. Sharma、「輸送ネットワークの共有メッシュ修復のためのRSVP-TE拡張」、進行中の作業。
[12] P. Pan (Editor), D.H. Gan, G. Swallow, J. Vasseur, D. Cooper, A. Atlas, and M. Jork, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", Work in Progress.
[12] P.パン（編集者）、D.H。ガン、G。スワロー、J。ヴァスザー、D。クーパー、A。アトラス、およびM.ジョーク、「LSPトンネルのRSVP-TEへの高速再拡張」、進行中の作業。
[13] A. Atlas, C. Villamizar, and C. Litvanyi, "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute", Work in Progress.
[13] A. Atlas、C。Villamizar、およびC. Litvanyi、「MPLS RSVP-TEの局所保護/高速リルートの相互運用性」、進行中の作業。
[14] A. Chiu and J. Strand, "Joint IP/Optical Layer Restoration after a Router Failure", Proc. OFC'2001, Anaheim, CA, March 2001.
[14] A. ChiuおよびJ. Strand、「ルーター故障後のジョイントIP/光層の復元」、Proc。OFC'2001、カリフォルニア州アナハイム、2001年3月。
[15] K. Kompella and Y. Rekhter, "Multi-area MPLS Traffic Engineering", Work in Progress.
[15] K. KompellaとY. Rekhter、「マルチエリアMPLSトラフィックエンジニアリング」、進行中の作業。
[16] G. Ash, et. al., "Requirements for Multi-Area TE", Work in Progress.
[16] Gcash、et。al。、「マルチエリアへの要件」、進行中の作業。
[17] A. Iwata, N. Fujita, G.R. Ash, and A. Farrel, "Crankback Routing Extensions for MPLS Signaling", Work in Progress.
[17] A. Iwata、N。Fujita、G.R。Ash、およびA. Farrel、「MPLSシグナリング用のクランクバックルーティング拡張機能」、進行中の作業。
[18] C-Y Lee, A. Celer, N. Gammage, S. Ghanti, G. Ash, "Distributed Route Exchangers", Work in Progress.
[18] C-Y Lee、A。Celer、N。Gammage、S。Ghanti、G。Ash、「分散型ルート交換者」、進行中の作業。
[19] C-Y Lee and S. Ghanti, "Path Request and Path Reply Message", Work in Progress.
[19] C-Y LeeとS. Ghanti、「Path Request and Path Replyメッセージ」、進行中の作業。
[20] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, September 1999.
[20] Awduche、D.、Malcolm、J.、Agogbua、J.、O'Dell、M。、およびJ. McManus、「MPLS上の交通工学要件」、RFC 2702、1999年9月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[21] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
A lot of the direction taken in this document, and by the team in its initial effort was steered by the insightful questions provided by Bala Rajagoplan, Greg Bernstein, Yangguang Xu, and Avri Doria. The set of questions is attached as Appendix A in this document.
この文書で行われた多くの方向性は、最初の努力でチームによって行われ、バラ・ラジャゴプラン、グレッグ・バーンスタイン、ヤンググアン・Xu、およびアヴリ・ドリアによって提供された洞察に満ちた質問に導かれました。一連の質問は、このドキュメントの付録Aとして添付されています。
After the release of the first draft, a number of comments were received. Thanks to the inputs from Jerry Ash, Sudheer Dharanikota, Chuck Kalmanek, Dan Koller, Lyndon Ong, Steve Plote, and Yong Xue.
最初のドラフトのリリース後、多くのコメントが受け取られました。Jerry Ash、Sudheer Dharanikota、Chuck Kalmanek、Dan Koller、Lyndon Ong、Steve Plote、Yong Xueの入力に感謝します。
Jim Boyle (PDNets), Rob Coltun (Movaz), Tim Griffin (AT&T), Ed Kern, Tom Reddington (Lucent) and Malin Carlzon.
ジム・ボイル（PDNETS）、ロブ・コルトゥン（Movaz）、ティム・グリフィン（AT＆T）、エド・カーン、トム・レディントン（ルーセント）、マリン・カールゾン。
Appendix A: Questions used to help develop requirements
付録A：要件の開発に役立つ質問
A. Definitions
A.定義
1. In determining the specific requirements, the design team should precisely define the concepts "survivability", "restoration", "protection", "protection switching", "recovery", "re-routing" etc. and their relations. This would enable the requirements doc to describe precisely which of these will be addressed. In the following, the term "restoration" is used to indicate the broad set of policies and mechanisms used to ensure survivability.
1. 特定の要件を決定する際に、設計チームは、「生存性」、「修復」、「保護」、「保護スイッチング」、「回復」、「再ルーティング」などの概念を正確に定義する必要があります。これにより、要件ドキュメントがこれらのどれが対処されるかを正確に記述できるようになります。以下では、「修復」という用語を使用して、生存可能性を確保するために使用される幅広い一連のポリシーとメカニズムを示します。
B. Network types and protection modes
B.ネットワークの種類と保護モード
1. What is the scope of the requirements with regard to the types of networks covered? Specifically, are the following in scope:
1. カバーされているネットワークの種類に関する要件の範囲はどのくらいですか？具体的には、範囲内の以下です。
Restoration of connections in mesh optical networks (opaque or transparent) Restoration of connections in hybrid mesh-ring networks Restoration of LSPs in MPLS networks (composed of LSRs overlaid on a transport network, e.g., optical) Any other types of networks? Is commonality of approach, or optimization of approach more important?
メッシュ光ネットワーク（不透明または透明性）ハイブリッドメッシュリングネットワークでの接続の復元の回復MPLSネットワークのLSPの復元（トランスポートネットワークで重複するLSRで構成される、光学式）他の種類のネットワーク？アプローチの共通性、またはアプローチの最適化はより重要ですか？
2. What are the requirements with regard to the protection modes to be supported in each network type covered? (Examples of protection modes include 1+1, M:N, shared mesh, UPSR, BLSR, newly defined modes such as P-cycles, etc.)
2. カバーされている各ネットワークタイプでサポートされる保護モードに関する要件は何ですか？（保護モードの例には、1 1、M：N、共有メッシュ、UPSR、BLSR、Pサイクルなどの新たに定義されたモードなどが含まれます。）
3. What are the requirements on local span (i.e., link by link) protection and end-to-end protection, and the interaction between them? E.g.: what should be the granularity of connections for each type (single connection, bundle of connections, etc).
3. ローカルスパン（つまり、リンクごとのリンク）の保護とエンドツーエンドの保護、およびそれらの間の相互作用の要件は何ですか？たとえば、各タイプの接続の粒度（単一接続、接続のバンドルなど）は何ですか。
C. Hierarchy
C.階層
1. Vertical (between two network layers): What are the requirements for the interaction between restoration procedures across two network layers, when these features are offered in both layers? (Example, MPLS network realized over pt-to-pt optical connections.) Under such a case,
1. 垂直（2つのネットワークレイヤー間）：両方のレイヤーでこれらの機能が提供されている場合、2つのネットワークレイヤーにわたる復元手順間の相互作用の要件は何ですか？（たとえば、MPLSネットワークはPTからPTへの光接続を介して実現しました。）そのような場合、そのような場合、
(a) Are there any criteria to choose which layer should provide protection?
(a) どのレイヤーが保護を提供するかを選択する基準はありますか？
(b) If both layers provide survivability features, what are the requirements to coordinate these mechanisms?
(b) 両方のレイヤーが生存可能性の機能を提供する場合、これらのメカニズムを調整するための要件は何ですか？
(c) How is lack of current functionality of cross-layer coordination currently hampering operations?
(c) 現在、互いの協調の現在の機能が不足しているのは、現在どのように操作を妨げていますか？
(d) Would the benefits be worth additional complexity associated with routing isolation (e.g. VPN, areas), security, address isolation and policy / authentication processes?
(d) ルーティングの分離（VPN、領域など）、セキュリティ、アドレス分離、および認証プロセスに関連する追加の複雑さはありますか？
2. Horizontal (between two areas or administrative subdivisions within the same network layer):
2. Horizontal（同じネットワークレイヤー内の2つの領域または管理下の区画の間）：
(a) What are the criteria that trigger the creation of protocol or administrative boundaries pertaining to restoration? (e.g., scalability? multi-vendor interoperability? what are the practical issues?) multi-provider? Should multi-vendor necessitate hierarchical separation?
(a) 復元に関するプロトコルまたは管理境界の作成をトリガーする基準は何ですか？（たとえば、スケーラビリティ？マルチベンダーの相互運用性？実際の問題は何ですか？）マルチプロバイダー？マルチベンダーは階層的な分離を必要とするべきですか？
When such boundaries are defined:
そのような境界が定義されている場合：
(b) What are the requirements on how protection/restoration is performed end-to-end across such boundaries?
(b) そのような境界を越えてエンドツーエンドの保護/修復がどのように実行されるかについての要件は何ですか？
(c) If different restoration mechanisms are implemented on two sides of a boundary, what are the requirements on their interaction?
(c) 境界の両側に異なる修復メカニズムが実装されている場合、それらの相互作用の要件は何ですか？
What is the primary driver of horizontal hierarchy? (select one) - functionality (e.g. metro -v- backbone) - routing scalability - signaling scalability - current network architecture, trying to layer on TE on top of an already hierarchical network architecture - routing and signalling
水平階層の主な要因は何ですか？（1つを選択） - 機能（メトロ-V-バックボーンなど） - ルーティングスケーラビリティ - シグナリングスケーラビリティ - 現在のネットワークアーキテクチャ、すでに階層的なネットワークアーキテクチャの上にTEを重ねようとする - ルーティングとシグナリング
For signalling scalability, is it - manageability - processing/state of network - edge-to-edge N^2 type issue
シグナリングスケーラビリティの場合、それは - 管理可能性 - ネットワークの処理/状態 - エッジツーエッジn^2タイプの問題
For routing scalability, is it - processing/state of network - are you flat and want to go hierarchical - or already hierarchical? - data or TDM application?
スケーラビリティをルーティングするために、ネットワークの処理/状態 - あなたはフラットで、階層的になりたいですか、それともすでに階層的ですか？ - データまたはTDMアプリケーション？
D. Policy
D.ポリシー
1. What are the requirements for policy support during protection/restoration, e.g., restoration priority, preemption, etc.
1. 保護/修復中のポリシーサポートの要件、例えば、回復の優先順位、先制など。
E. Signaling Mechanisms
E.シグナル伝達メカニズム
1. What are the requirements on the signaling transport mechanism (e.g., in-band over SDH/SONET overhead bytes, out-of-band over an IP network, etc.) used to communicate restoration protocol messages between network elements? What are the bandwidth and other requirements on the signaling channels?
1. ネットワーク要素間の復元プロトコルメッセージの通信に使用されるシグナリング輸送メカニズム（例：SDH/SONETオーバーヘッドバイト、IPネットワーク上のバンドなど）の要件は何ですか？シグナリングチャネルの帯域幅とその他の要件は何ですか？
2. What are the requirements on fault detection/localization mechanisms (which is the prelude to performing restoration procedures) in the case of opaque and transparent optical networks? What are the requirements in the case of MPLS restoration?
2. 不透明で透明な光学ネットワークの場合の障害検出/ローカリゼーションメカニズム（これが復元手順を実行するための前奏曲）の要件は何ですか？MPLS復元の場合の要件は何ですか？
3. What are the requirements on signaling protocols to be used in restoration procedures (e.g., high priority processing, security, etc)?
3. 修復手順（例：優先度の高い処理、セキュリティなど）で使用されるシグナリングプロトコルの要件は何ですか？
4. Are there any requirements on the operation of restoration protocols?
4. 修復プロトコルの動作に関する要件はありますか？
F. Quantitative
F.定量的
1. What are the quantitative requirements (e.g., latency) for completing restoration under different protection modes (for both local and end-to-end protection)?
1. さまざまな保護モード（ローカル保護とエンドツーエンドの保護の両方で）で修復を完了するための定量的要件（例：レイテンシ）は何ですか？
G. Management
G.管理
1. What information should be measured/maintained by the control plane at each network element pertaining to restoration events?
1. 復元イベントに関連する各ネットワーク要素のコントロールプレーンがどのような情報を測定/維持する必要がありますか？
2. What are the requirements for the correlation between control plane and data plane failures from the restoration point of view?
2. 修復観点からのコントロールプレーンとデータプレーンの故障との相関の要件は何ですか？
Editors' Addresses
編集者のアドレス
Wai Sum Lai AT&T 200 Laurel Avenue Middletown, NJ 07748, USA
ワイサムライAT＆T 200ローレルアベニューミドルタウン、ニュージャージー州07748、米国
Phone: +1 732-420-3712
EMail: wlai@att.com
Dave McDysan WorldCom 22001 Loudoun County Pkwy Ashburn, VA 20147, USA
Dave McDysan Worldcom 22001 Loudoun County Pkwy Ashburn、20147、米国
EMail: dave.mcdysan@wcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。