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.
著作権（C）インターネット協会（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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.
この文書では、トラフィックエンジニアリング作業部会の中に確立されたネットワーク階層と耐障害性技術設計チームの結果です。このチームは、サービスプロバイダ環境での生存性と階層の現在および近い将来の要件を収集し、文書化。明確にするために、定義の拡張セットが含まれています。チームは、パケットと非パケットネットワークにおける相互運用性の生存性アプローチの小さなセットを定義する必要があるように見えることが決定しました。推奨アプローチは、パスベースだけでなく、ネットワーク障害に近接して1つの修理の接続が含まれています。彼らは、単一のネットワーク層で主に動作します。階層のために、このよう時分割多重（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（共通制御・計測プレーンワーキンググループ）、および他のワーキンググループで対処されている作業を集中支援することです。この作品の主な目的は、マルチベンダー、サービスプロバイダーのネットワークで必要な機能のためのいくつかの便宜を提供することです。最初の焦点は、主に、ドメイン内の操作です。しかし、マルチプロバイダ環境におけるエンドツーエンドのサービスの提供における一貫性を維持するために、ドメイン境界での存続性の機構の動作を管理する規則も指定する必要があります。そのような問題を提起し、議論しているが、適切な場合には、彼らは、このドキュメントの最初のリリースでは、深さで扱われることはありません。
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)
事前に計画と1パスプロテクション： - 1、予め確立バックアップ容量（非共有）を有する1パスプロテクション：1 - O相互運用可能な生存の小さなセットがO生存メカニズムとして提案パケットと非パケットネットワークに接近定義する必要がありますバックアップ容量（共有）
- 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
- ネットワーク障害に近接して修理してローカル復元 - 音声通話のカットオフ（2秒〜140ミリ秒）をサポートするために、サービス復旧のための境界のタイミングOソースベースの再ルーティングによるパスリストア、プレミアムデータサービスのプロトコルタイマーの要件、およびミッションクリティカルなアプリケーションサービスの差別化のための復旧優先順位の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サービスのO要件をサポートするために、階層的なIGPとサービスプロバイダのネットワークに多くのLSPを設定する機能は、任意の必要なプロトコルの拡張のためのガイダンスを提供するために開発する必要があります
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）ネットワーク要素を含むことができる接続ルーティングするためのメカニズムoをその領域内に保護された（例えば、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）水平に配向：同じネットワーク技術層内の二つの領域又は管理部門間。
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,
垂直階層において、総ネットワーク機能は、隣接する層の間の明確な、論理的、及び多分物理的分離と機能または技術一連の層に分割されます。生存メカニズムのいずれか、現在存在し又はネットワーク内の複数の層で開発されている[3]。 1保護：光学層は、現在、伝統的な1 + 1または1に加えて、動的リングとメッシュ回復機能を提供することが可能になってきています。同期デジタルハイアラーキ（SDH）/同期光ネットワーク（SONET）層は、自動保護スイッチング（APS）とサバイバビリティ機能を提供するだけでなく、自己回復リングおよび復元アーキテクチャをメッシュ。同様の機能は、[4]また、MPLSを使用してこのような機能を提供するために進行中の作業で、非同期転送モード（ATM）レイヤで定義されています。 IP層では、
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].
再ルーティングは、リンクやノードの停止次のサービスの継続性を復元するために使用されます。 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.
水平の階層では、大規模なネットワークは、複数のより小さな、非重複サブネットワークに分割されます。分割基準は、トポロジ、ネットワーク機能、管理ポリシー、またはサービスドメインの境界に基づくことができます。 2つのネットワークが同じ* *階層レベルで、例えば、BGP内の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.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のスパンを光リングを共有方法の共有権利を、そのような共有ファイバケーブルとして妥協の他の種類を含みます外部プラントは、障害ごとに検討する必要があります。 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.
回復は、（例えば、サービスレベル契約に従って）既存のサービスに必要な性能レベルを維持するために、障害を検出した後、ネットワークによって取らイベントとアクションのシーケンスであり、ネットワークの正規化を可能にします。故障したコンポーネントの障害分離および修理（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アーキテクチャ：Nアーキテクチャが1の一般化です。典型的には、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アーキテクチャよりも障害からの回復です。利点は、保護エンティティは、必要に応じて、トラフィックの優先使用が許可されている場合、通常の操作では、優先度の低い余分なトラフィックを運ぶために使用することができるということです。後で事前に計画ではなく、事前に予約容量で使用するパケットネットワークは、保護パスを事前に確立することができます。何パケットが保護経路上に送信されない場合には、その後、何の帯域幅が消費されませんさ。これは、パス設定と資源予約を切り離すことができない光学的または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の場合、保護エンティティは、必要に応じて、通常動作時にプリエンプタブルトラフィックを搬送するために使用することができます。
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または光ネットワークへの/からのIPネットワークからのような）ネットワーク層にわたって生存メカニズムを通信するための方法でした。しかし、機能が障害通知を実行し、異なる層の間で生存機構の動作を制御するネットワークオペレータのために提供されるべきです。これは、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.
実際のネットワーク構成に応じて、ドロップ側インターフェース（例えば、顧客とアクセスルータとの間、またはルータと光クロスコネクトとの間の）ドメイン間または層間のいずれかと考えることができます。別のドメイン間のシナリオは、両方のネットワークが同じサービスプロバイダによって管理された状態で、メトロネットワークとコアネットワークを相互接続するための局内リンクを使用することです。このような界面での失敗は同様に、このセクションのメカニズムによって保護されていてもよいです。
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-互いに素な障害によって共有されることを可能にするために提供されるべきです。ある意味で、これは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]で提案を参照して、障害にすぐ近くにリンクまたはスパンの接続を復元することです。ノードベースSRGSから保護する価値があるかもしれませんが、最低でも、このアプローチは、接続型SRGSから保護することができなければなりません。また、このアプローチは、スコープ部で説明したように局内のリンクを使用してドメイン間や層間相互接続シナリオに復旧をサポートするために適用されます。
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タイムアウトやアプリケーションプロトコルタイマーの要件を満たすために必要 - 声：呼切断（2秒〜140ミリ秒の範囲であり、人がハングアップする前に、通話路や電話交換機が通話を切断する時間の中断後に待機する時間） - 中断がセッションを終了させるような他のリアルタイムサービス（例えば、ストリーミング、ファックス） - でも、短い中断を容認することはできませんミッションクリティカルなアプリケーション、例えば、リアルタイムの金融取引
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
1：事前に確立された容量を持つ1パスプロテクション：100〜500ミリ秒1：事前に計画された容量を持つ1パスプロテクション：100から750ミリ秒ローカル修復：50ミリパスリストア：1-5秒
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保護切り替えが使用されている場合SDH / SONETスイッチする時間があったまでは例えば、MPLS回復タイマーを待たなければなりません。このようタイマーを設定すると、複数の層が潜在的に非効率的な方法でリソースを割り当てる、同じ障害に応答している競合状態の急速な回復と創造の間のトレードオフを必要とします。
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.
これは、生存性アプローチのコーディネートに現在のアプローチは、現在、重要な業務の不足を持っていなかったことを感じました。これらのアプローチは、単に一つの層（例えば、線形WDMオーバーIPレイヤで、またはSDH / SONETレイヤで）でトラフィックを保護含みます。生存メカニズムは、ルーティングネットワークは、SDH / SONET保護されたネットワークに乗ったときのようないくつかの層で展開されるかもしれない場合、それは現在の協調アプローチは、多くの場合に十分であったと感じました。一つの例外は、上記のようにSDH / SONETプロテクション切り替えが完了するまでMPLS回復のホールドオフです。これは、高速MPLS回復の回復時間を制限します。また、設計によって、所与の層内の操作とメカニズムは、他の層には見えない傾向にあります。
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ネットワークのリカバリ要件間のより良いマッチングを提供するかもしれません。そのような提案は、[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.
水平階層のための一つの理由は、機能性である（例えば、メトロバックボーン対）。地理的な「島」またはパーティションは、相互運用性の必要性を削減し、管理や操作がそれほど複雑にします。メトロ/バックボーン境界で、よりシンプルで相互運用可能、生存性スキームを使用すると、多くのプロバイダ・ネットワーク・アーキテクチャのための自然です。マルチベンダーの相互運用性を達成することは困難であったため、伝送ネットワークでは、異なるベンダーの機器の地理的な島々を作成することは、長い時間のために行われています。伝統的に、プロバイダは「接続」のいずれかの端に機器を調整する必要があり、これは、相互運用可能作ることは複雑さを軽減します。プロバイダは、次の上位レベルに「保護されたリンク」を提供するために生存機構を連結することができなければなりません。 ADMとDXCポートとの間の1 + 1ライン層の保護とTDM DXCsに接続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（Open Shortest Path First）の。多くの場合、これは、元の設計からだったので、ネットワークは本当にその現在のサイズに到達するために階層を必要であれば、言い難いです。
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.
ドメイン内の水平階層の主な要因は、潜在的にトラフィックエンジニアリングデータネットワークを介して、エッジツーエッジVPNの文脈における能力をシグナリングされます。ベースの疑似ワイヤー端から端までエミュレーション（PWE3）の努力があり2およびレイヤ3つのVPNを層に多数の異なるアプローチがあり、彼らは現在、プロバイダプロビジョニングのVPN（例えば、仮想ルーター）に異なる新たなプロトコルによって対処されていて、 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.
メカニズムは、ネットワークを介して接続のエッジ間のシグナリングを可能にするために必要とされます。一つのネットワークシナリオは、現在、このような中間システムへのマルチエリアOSPFまたは多値中間システム（IS-IS）などの階層内部ルーティングを有する大規模ネットワークへの媒体を含みます。この一次コンテキストは、ネットワークを介して実施されているレイヤ2およびレイヤ3つのVPNのSLAを保証するために必要であると考えられているエッジ・ツー・エッジ信号です。別の可能なコンテキストは、メトロとコアネットワークは再び階層内部ルーティングドメイン内にあるかもしれない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のABR）。すなわち、いずれかの側のデバイスは、知識のその領域内のエリア内のアプローチを取ることを可能にし、ABRは、両方の領域でこれを行うために、共通点で2つの保護された接続をスプライスであろう（許可され、それは共通点であります故障の今）。このアプローチの限界は、動作設定に表示されるように開始する場合は、おそらくルートサーバとシグナリング伝播ディレクティブについて考え始める時間になります。しかし、一つの初期のアプローチは、共通の境界ルータを介してシグナル伝達するために、それは、それぞれが自分のエリア内で保護された接続の連結セットで構成されて保護されたサービスを検討するかもしれません。別のアプローチは、例えば、境界で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.
管理コントロール内のノードとリンクに共通の管理制御下でネットワークのために定義されているSRGSのセット及びこれらSRGSの対応割当ては、機密情報であり、保護される必要があります。 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]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] K. Owens, V. Sharma, and M. Oommen, "Network Survivability Considerations for Traffic Engineered IP Networks", Work in Progress.
[3] K.オーエンス、V.シャルマ、および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.シャルマ、B.クレイン、S. Makam債、K.オーウェンズ、C.黄、F. Hellstrand、J.ワイル、L.アンダーソン、B. Jamoussi、B.カイン、S. Civanlar、およびA.チウ、「MPLSベースの回復のための枠組み」が進行中で働いています。
[5] M. Thorup, "Fortifying OSPF/ISIS Against Link Failure", http://www.research.att.com/~mthorup/PAPERS/lf_ospf.ps
[5] M. Thorup、 "強化OSPF / IS-ISに対するリンク障害"、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.、チウ、A.、Elwalid、A.、Widjaja、I.およびX.シャオ、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.バーンスタイン、V.シャルマ、C. Brownmiller、Y.雪、及びJ.ストランド、 "インタードメイン共有リスクグループとルーティング" 、進行中の作業。
[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. Davari、E.クエバス、B.マック・クレーン、E. Franze、H.太田、T.したがって、S. Goldfless、及びF.チェン、「OAMの要件進行中のMPLSネットワークにおける、」ワーク。
[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.ラクシュマン、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.李、C. Kalmanek、J.イェーツ、G.バーンスタイン、F. Liaw、及びV.シャルマ、 "トランスポートネットワークにおける共有メッシュ回復のためのRSVP-TE拡張"、ProgressのWork。
[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.パン（編集）、DHガン、G.ツバメ、J. Vasseur、D.クーパー、A.アトラス、及びM. Jorkの、 "高速リルートExtensionsはLSPトンネルのためのRSVP-TEをする"、ProgressのWork 。
[13] A. Atlas, C. Villamizar, and C. Litvanyi, "MPLS RSVP-TE Interoperability for Local Protection/Fast Reroute", Work in Progress.
[13] A.アトラス、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.チウとJ.ストランド、「ルータ障害後の共同IP /光レイヤ修復」、PROC。 OFC'2001、アナハイム、CA、2001年3月。
[15] K. Kompella and Y. Rekhter, "Multi-area MPLS Traffic Engineering", Work in Progress.
[15] K. KompellaとY. Rekhter、 "マルチエリアMPLSトラフィックエンジニアリング"、ProgressのWork。
[16] G. Ash, et. al., "Requirements for Multi-Area TE", Work in Progress.
[16] G.アッシュ、ら。ら、「マルチエリアTEの要件」が進行中で働いています。
[17] A. Iwata, N. Fujita, G.R. Ash, and A. Farrel, "Crankback Routing Extensions for MPLS Signaling", Work in Progress.
[17] A.岩田、N.藤田、G。R.アッシュ、およびA.ファレル、「MPLSシグナリングのためのクランクバックのルーティング機能拡張」が進行中で働いています。
[18] C-Y Lee, A. Celer, N. Gammage, S. Ghanti, G. Ash, "Distributed Route Exchangers", Work in Progress.
[18] C-Yリー、A. Celer、N.ガメージ、S. Ghanti、G.アッシュ、進行中の作業 "ルート交換器を分散"。
[19] C-Y Lee and S. Ghanti, "Path Request and Path Reply Message", Work in Progress.
[19] C-Y LeeおよびS. Ghanti、 "パス要求および経路応答メッセージ"、ProgressのWork。
[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.、マルコム、J.、Agogbua、J.、オデル、M.及びJ.マクマナス、 "トラフィック過剰性能MPLSのための要件"、RFC 2702、1999年9月。
[21] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[21]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、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.
この文書では、その初期の努力でチームが撮影した方向の多くはバラRajagoplan、グレッグ・バーンスタイン、陽光徐、およびAvriドリアが提供する洞察力の質問によって操縦されました。一連の質問は、このドキュメントの付録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.
最初のドラフトのリリース後、コメントの数が受信されました。ジェリー・アッシュ、Sudheer Dharanikota、チャックKalmanek、ダン・コラー、リンドンオング、スティーブPlote、そして龍雪からの入力に感謝します。
Jim Boyle (PDNets), Rob Coltun (Movaz), Tim Griffin (AT&T), Ed Kern, Tom Reddington (Lucent) and Malin Carlzon.
ジム・ボイル（PDNets）、ロブColtun（Movaz）、ティム・グリフィン（AT＆T）、エド・カーン、トムReddington（ルーセント）とマリンCarlzon。
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,
（2つのネットワーク層の間）1.垂直：これらの機能は、両方の層で提供されている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.水平（二つの領域または同一のネットワーク層内の管理部門間）：
(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
水平階層の主な要因は何ですか？ （いずれかを選択） - 機能（例えば地下鉄-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ローレルアベニューミドルタウン、NJ 07748、USA
Phone: +1 732-420-3712 EMail: wlai@att.com
電話：+1 732-420-3712電子メール：wlai@att.com
Dave McDysan WorldCom 22001 Loudoun County Pkwy Ashburn, VA 20147, USA
デイブMcDysanワールドコム22001ラウドン郡パークウェイアッシュバーン、VA 20147、USA
EMail: dave.mcdysan@wcom.com
メールアドレス：dave.mcdysan@wcom.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。