RFC3386 日本語訳
3386 Network Hierarchy and Multilayer Survivability. W. Lai, Ed., D.McDysan, Ed.. November 2002. (Format: TXT=65345 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Lai, Ed.
Request for Comments: 3386 AT&T
Category: Informational D. McDysan, Ed.
WorldCom
November 2002
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
Network Hierarchy and Multilayer Survivability
Status of this Memo
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.
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 Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Abstract
This document presents a proposal of the near-term and practical requirements for network survivability and hierarchy in current service provider environments.
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
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].
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].
Lai, et. al. Informational [Page 1] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 1] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Table of Contents
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
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
1. Introduction
1. Introduction
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
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
Lai, et. al. Informational [Page 2] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 2] RFC 3386 Hierarchy & Multilayer Survivability November 2002
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.
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.
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.
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.
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.
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:
Here is a summary of the findings:
A. Survivability Requirements
A. Survivability Requirements
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 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)
Lai, et. al. Informational [Page 3] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 3] RFC 3386 Hierarchy & Multilayer Survivability November 2002
- 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
- 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
B. Hierarchy Requirements
B. Hierarchy Requirements
B.1. Horizontally Oriented Hierarchy (Intra-Domain)
B.1. Horizontally Oriented Hierarchy (Intra-Domain)
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 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
B.2. Vertically Oriented Hierarchy
B.2. Vertically Oriented Hierarchy
The following functionality for survivability is common on most routing equipment today.
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 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
C. Survivability Requirements in Horizontal Hierarchy
C. Survivability Requirements in Horizontal Hierarchy
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 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
Lai, et. al. Informational [Page 4] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 4] RFC 3386 Hierarchy & Multilayer Survivability November 2002
2. Terminology and Concepts
2. Terminology and Concepts
2.1 Hierarchy
2.1 Hierarchy
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.
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).
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).
In this document, network hierarchy is considered from two perspectives:
In this document, network hierarchy is considered from two perspectives:
(1) Vertically oriented: between two network technology layers.
(2) Horizontally oriented: between two areas or administrative
subdivisions within the same network technology layer.
(1) Vertically oriented: between two network technology layers. (2) Horizontally oriented: between two areas or administrative subdivisions within the same network technology layer.
2.1.1 Vertical Hierarchy
2.1.1 Vertical Hierarchy
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.
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,
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,
Lai, et. al. Informational [Page 5] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 5] RFC 3386 Hierarchy & Multilayer Survivability November 2002
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].
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].
2.1.2 Horizontal Hierarchy
2.1.2 Horizontal Hierarchy
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.
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.
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.
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.2 Survivability Terminology
2.2 Survivability Terminology
In alphabetical order, the following terms are defined in this section:
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)
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)
Lai, et. al. Informational [Page 6] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 6] RFC 3386 Hierarchy & Multilayer Survivability November 2002
2.2.1 Survivability
2.2.1 Survivability
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.
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.
2.2.2 Generic Operations
2.2.2 Generic Operations
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.
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.
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.
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.
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.
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.
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.
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.
Lai, et. al. Informational [Page 7] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 7] RFC 3386 Hierarchy & Multilayer Survivability November 2002
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).
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.
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.
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.
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.
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.
2.2.3 Survivability Techniques
2.2.3 Survivability Techniques
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).
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).
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
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
Lai, et. al. Informational [Page 8] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 8] RFC 3386 Hierarchy & Multilayer Survivability November 2002
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
2.2.4 Survivability Performance
2.2.4 Survivability Performance
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.
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.
Lai, et. al. Informational [Page 9] RFC 3386 Hierarchy & Multilayer Survivability November 2002
Lai, et. al. Informational [Page 9] RFC 3386 Hierarchy & Multilayer Survivability November 2002
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 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.
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.
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.
2.3 Survivability Mechanisms: Comparison
2.3 Survivability Mechanisms: Comparison
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.
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.
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.
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,
失敗から回復することでは1:1アーキテクチャは本来保護ドメインの両端のコミュニケーション以来の1+1アーキテクチャがオーバースイッチ操作を実行するのに必要であるというよりも遅いです。 利点は通常の操作における低い優先度の付加的なトラフィックを運ぶのに任意に保護実体を使用できるということです、トラフィック先取りが許されているなら。 パケット網は後の使用のためにあらかじめ計画されましたが、プレ予約されなかった容量で保護経路をあらかじめ確立できます。 すなわち、パケットを全く保護経路に送らないなら
Lai, et. al. Informational [Page 10] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[10ページ]のRFC階層構造と多層生存性2002年11月
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.
そして、帯域幅は全く消費されません。 これは、中のトランスミッションが光学であることのようにネットワークでつながないいずれのケースと、または経路設立と資源予約の衝撃を吸収されることができない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.
ネットワークルーティング・アルゴリズムが欠点の後にいったん一点に集まると、いくつかの場合、それは、aがネットワークの現状に基づいて別ルートで送る実行とネットワーク方針でネットワークを再最適化するために望ましいかもしれません。
3. Survivability
3. 生存性
3.1 Scope
3.1 範囲
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
ネットワークの生存性への共同利用できるアプローチは、パケット網における即座の要件であると決心していて、SDH/SonetでTDMネットワークを縁どりました。 このとき押すとして、マルチベンダ環境における、これらのネットワークのコントロールが最初に対処するある他のハードルを持っているように見えたとき、それがカバーするテクニックはオール光学のネットワーク(例えば、どこで、縁どりは未知ですか)ではありませんでした。 また、アプローチは、即座の関心について、調整することになっていませんでしたし、ネットワーク層(IPネットワークからの/へのTDMか光学ネットワーク現在そのようなもの)の向こう側に明らかに生存性メカニズムを伝えることになっていませんでした。 しかしながら、能力をネットワーク・オペレータに提供するべきです。
Lai, et. al. Informational [Page 11] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[11ページ]のRFC階層構造と多層生存性2002年11月
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]).
異なった層の中で欠点通知とコントロールに生存性メカニズムの操作を実行してください。 これは対応する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.
初期の範囲はサービスプロバイダーネットワークの相互オフィス接続における「バックホウ失敗」だけ、を扱うことになっています。 ルータ層のリンク結合は下層で複数の長さから通常成ります。 したがって、回復を実行するネットワーク失敗のタイプはリンク/長さの故障を入れます。 しかしながら、linecardとノード障害は彼らのそれぞれのリンク/長さと異なった扱われたいずれかが失敗であったならそうする必要はないかもしれません、ルータ失敗が1セットの同時のリンクの故障として表されるかもしれないように。
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.
本書では議論した生存性メカニズムの範囲の中にセキュリティの系統的なコントロール飛行機の故障、構成誤り、または不履行などの他の、より複雑な故障メカニズムがありません。 また、カバーされていなく低いスループットをもたらす混雑のような損傷をネットワークでつないでください。
3.2 Required initial set of survivability mechanisms
3.2 必要な始発の生存性メカニズム
3.2.1 1:1 Path Protection with Pre-Established Capacity
3.2.1 1 : プレ確立した容量との1つの経路保護
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
通常の操作では、働く接続にトラフィックを送るだけです、トラフィックが両方の接続(シグナリング目的のための1+1Path)に送られると合図する能力は非パケット網で貴重でしょうが。 働きと保護接続の何らかの区別がありそうです、明白なオブジェクトか望ましくはのどちらか一般的なクラスかプライオリティなどのインプリシット方式で。 ギヤエンドは失敗が互いから可能な状態でばらばらになって接続を創造する能力を必要とします。 これはSRG情報を必要とします。
Lai, et. al. Informational [Page 12] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[12ページ]のRFC階層構造と多層生存性2002年11月
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.
それを一般に、ノードかリンクのどちらかに割り当てて、コントロールか管理飛行機を通して伝播できます。 このメカニズムに、保護接続における容量はあらかじめ確立されて、しかしながら、それは非パケット網における先取り可能付加的なトラフィックを運ぶことができるべきです。 保護容量が回復の間サービスに呼ばれるとき、何らかのフォームの以前開閉している能力で働く状態(非revertiveモード操作のための)に保護接続を昇進させる能力があるべきです。
3.2.2 1:1 Path Protection with Pre-Planned Capacity
3.2.2 1 : あらかじめ計画された容量との1つの経路保護
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経路保護に基づくかもしれません。
3.2.3 Local Restoration
3.2.3 地方の王政復古
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から守る価値があるかもしれませんが。 また、このアプローチも相互ドメインと相互層のインタコネクトシナリオでScopeセクションで説明されるようにイントラオフィスのリンクを使用することで回復をサポートするのにおいて適切です。
Lai, et. al. Informational [Page 13] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[13ページ]のRFC階層構造と多層生存性2002年11月
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.
地方の回復が準最適であるかもしれないので、このアプローチのためにギヤエンドのシステムが後で経路レベル再グルーミングを実行する手段をサポートしなければなりません。
3.2.4 Path Restoration
3.2.4 経路王政復古
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.
このアプローチでは、欠点によって影響を与えられる接続は接続失敗の通知の起因しているネットワーク要素によって別ルートで送られます。 そのようなソースベースのアプローチは、ネットワーク資源に効率的ですが、回復を実行するために通常時間がかかります。 それはどんな新しいメカニズムにもかかわりません。単にネットワークで欠点から守ることへの別の一般的なアプローチの言及です。
3.3 Applications Supported
3.3 サポートされたアプリケーション
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秒(人がハングアップする前か電話スイッチが呼び出しから切断する時間のスピーチ経路の中断の後に待つ時間)までのmsec--セッションが中断で終わる他のリアルタイムのサービス(例えば、ストリーミング、ファックス)--例えば短い中断さえ許容できない必要不可欠なアプリケーションのリアルタイムの金融取引の範囲にあります。
Lai, et. al. Informational [Page 14] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[14ページ]のRFC階層構造と多層生存性2002年11月
3.4 Timing Bounds for Survivability Mechanisms
3.4 生存性メカニズムのためのタイミング領域
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 あらかじめ計画された容量があるms1:1経路保護: 100-750 ms Local回復: 50 ms Path回復: 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.
上のタイミング領域の中で異なったアプリケーションのためのサービス要件を満たすことができるのを保証するなら、接続が復元される(サービス復旧時間を最小にして、最も良い経路で利用可能な設備余力へのアクセスを得る)順番を決定するために回復優先権を実装しなければなりません。 例えば、不可欠なアプリケーションは高い回復優先度を必要とするかもしれません。 ファイバー層では、特定のアプリケーションの代わりに、彼らのトラフィックタイプが顧客集合の中に同封されている状態で顧客のある分類が優先するのは、可能であるかもしれません。 すべての接続を復元できるというわけではないなら、先取り優先権は使用されるだけであるべきです、その場合、下側の先取り優先度との関係がリリースされるべきです。 バックアップのためにネットワーク資源に食糧を供給する際にサービスプロバイダーの戦略によって、先取りがネットワークで必要であるかもしれません。
Lai, et. al. Informational [Page 15] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[15ページ]のRFC階層構造と多層生存性2002年11月
3.5 Coordination Among Layers
3.5 層の中のコーディネート
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
生存性アプローチのコーディネートへの現在のアプローチにはかなりの操作上の不足分が現在なかったと感じられました。 これらのアプローチは、唯一1つの層(直線的なWDMの上のIP層における、または、例えば、SDH/Sonet層の)にトラフィックを保護するのを含んでいます。 生存性メカニズムが配布されるかもしれないところ
Lai, et. al. Informational [Page 16] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[16ページ]のRFC階層構造と多層生存性2002年11月
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.
発送されたネットワークがSDH/Sonetの保護されたネットワークに乗る時などの数個の層では、多くの場合、現在のコーディネートアプローチが十分であると感じられました。 1つの例外がそうである、保持、-、上で説明されるように切り替わるSDH/Sonetの保護の完成までのMPLS回復。 これは速いMPLS回復の回復時間を制限します。 また、故意に、与えられた層の中の操作とメカニズムは、他の層に目に見えない傾向があります。
3.6 Evolution Toward IP Over Optical
3.6 光学の上のIPに向かった発展
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]で説明されます。
4. Hierarchy Requirements
4. 階層構造要件
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などの)で縁から縁への、よりスケーラブルなシグナリング、またはシグナリングを許容するメカニズムに焦点を合わせるべきです。 これは異なった層でネットワークとインタコネクトするのが必要であるかもしれないメカニズムより緊急の必要性であるように見えます。
4.1 Historical Context
4.1 歴史的背景
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
水平な階層構造の1つの理由が機能性(例えば、地下鉄対バックボーン)です。 地理的な「島」かパーティションで、相互運用性の必要性を減少させて、管理と操作は、より複雑でなくなります。 多くのプロバイダーネットワークアーキテクチャに、地下鉄/バックボーン境界で、より簡単で、より共同利用できる生存性体系を使用するのは当然です。 送電網では、マルチベンダ相互運用性は達成するのが難しいので、長い間、異なったベンダー設備の地理的な島は作成されています。 伝統的に、プロバイダーは「接続」のどちらの終わりでも設備を調整しなければなりません、そして、これを共同利用できるようにすると、複雑さは減少します。 プロバイダーは、「保護されたリンク」を次の、より高いレベルに提供するために生存性メカニズムを連結できるべきです。 1で+1にTDM DXCsに接続するリングがADMとDXCポートの間の保護を系列で層にするとSDH/Sonetを考えてください。 TDM接続(例えば、DS3)は保護されますが、通常それぞれのSDH/Sonetリングの上のすべての設備が単一のベンダーから来ています。 DXC交差接続はプロバイダーによって監督されます、そして、ポートは監督されます。
Lai, et. al. Informational [Page 17] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[17ページ]のRFC階層構造と多層生存性2002年11月
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.
非常に利用可能なデザインをもたらしながら、物理的に保護されています。 したがって、水平な階層構造の向こう側にどっと落すのに生存性アプローチの連結を使用できます。 完全ではありませんが、マルチベンダ相互運用性が達成されるまで、それは中期との近さで実行可能です。
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を実行するものもあります。 いくつかのサービスプロバイダー、および多くの大企業ネットワークが、スケーラビリティの増加を獲得するために、マルチ領域オープンShortest Path First(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]。 このドキュメントは、これらと他の提案が、最初にいくつかの限られた目的を満たすことを目指すことができるように具体的な要件を提供することを目指します。
4.2 Applications for Horizontal Hierarchy
4.2 水平な階層構造のアプリケーション
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を層にして、3VPNsを層にするために、多くの異なるアプローチがあります、そして、彼らは現在、MPLS、そして/または、IPトンネルに基づくプロバイダーで食糧を供給されたVPNs(例えば、仮想のルータ)とPseudo Wire Edgeから縁へのEmulation(PWE3)取り組みにおける異なった現れているプロトコルによって扱われています。 これらは縁から縁まで明白なシグナリングを必要とするかもしれませんが、縁から縁への何らかのフォームのシグナリングが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
多くの縁(N)で、スケーラビリティは縁から縁へのシグナリングのO(N^2)の特性を避けるのに関係があります。 しかしながら、ここの本題が多量のシグナリングのスケーラビリティと共にありません、すべての縁組の間には、「接続」があるO(N^2)メッシュなどのように。 これは接続を確立して、維持するのが大きいネットワークで可能であっても、引き起こされるコア生存性メカニズムの上に影響があるかもしれないからです
Lai, et. al. Informational [Page 18] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[18ページ]のRFC階層構造と多層生存性2002年11月
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^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)メッシュはVPNsに必要でなく、現在のプロトコルと実装のスケーラビリティ領域の中にVPNsをサポートするトンネルの数があると感じます。 それはそうであるかもしれません、現在、IGP階層構造の向こう側に斜めに進むように縁からのMPLSトンネルに合図するために能力不足があるとき、OSPF領域などのように。 これは2レベルのIGP階層構造の向こう側にダイナミックな設立をサポートするシグナリング規格の開発と潜在的にLSPsの修復を必要とするかもしれません。
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つの学派があります。
4.3 Horizontal Hierarchy Requirements
4.3 水平な階層構造要件
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かマルチレベルIntermediate Systemなどの階層的な内部のルーティングをIntermediate Systemに持っている大きいネットワークに媒体を含んでいる、(-、) この第一の関係は縁への縁のシグナリングです。(そのシグナリングはネットワークの向こう側に運ばれる3VPNsの層2と層のために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のための要件は、どんな必要なプロトコル拡大のための指導も提供するために開発される必要があります。
5. Survivability and Hierarchy
5. 生存性と階層構造
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.
水平な階層構造がネットワーク技術層の中に存在していると、質問は階層的な境界を横断する接続に沿ってどう生存性を提供できるかに関して起こります。
Lai, et. al. Informational [Page 19] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[19ページ]のRFC階層構造と多層生存性2002年11月
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.
概要では、このとき、階層的な境界の向こう側に生存性計画の連結を許容する上で説明されるアプローチが十分に見えます。
6. Security Considerations
6. セキュリティ問題
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]を使用するだろうことです。
Lai, et. al. Informational [Page 20] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[20ページ]のRFC階層構造と多層生存性2002年11月
7. References
7. 参照
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[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.カイン、Civanlar、およびA.チウ、「MPLSベースの回復のための枠組み」が進行中で扱うS.。
[5] M. Thorup, "Fortifying OSPF/ISIS Against Link Failure",
http://www.research.att.com/~mthorup/PAPERS/lf_ospf.ps
[5] M.Thorup、「リンクの故障に対してOSPF/イシスの栄養価を高めます」、 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.、ウィジャヤ、I.、X.Xiao、および「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。
[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.D.Papadimitriou、R.Hartani、G.バーンスタイン、V.シャルマ、C.ブラウンミラー、Y.シュー、およびJ.Strand、「Shared Risk Groupsがある相互ドメインルーティング」、ProgressのWork。
[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.太田、したがって、S.Goldfless、およびF.チェン、「MPLSネットワークにおけるOAMのための要件」が進行中で扱うT.。
[9] D. Allan and M. Azad, "A Framework for MPLS User Plane OAM,"
Work in Progress.
[9] 「MPLSユーザ飛行機OAMのための枠組み」というD.アランとM.Azadは進行中で働いています。
[10] S. Kini, M. Kodialam, T.V. Lakshman, S. Sengupta, and C.
Villamizar, "Shared Backup Label Switched Path Restoration,"
Work in Progress.
[10] M.KodialamとT.V.Lakshman、S.SenguptaとC.Villamizar、「共有されたバックアップラベル切り換えられた経路王政復古」というS.Kiniは進行中で働いています。
[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.李、J.イェイツ、G.バーンスタイン、F.Liaw、およびV.シャルマ、「転送ネットワークにおける共有されたメッシュ王政復古の間のRSVP-Te拡大」というC.Kalmanekは進行中で働いています。
[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] 「LSP Tunnelsのために速くRSVP-Teに拡大を別ルートで送ってください」というP.なべ(エディタ)、D.H.ガン、G.ツバメ、J.Vasseur、D.クーパー、A.Atlas、およびM.Jorkは進行中で働いています。
Lai, et. al. Informational [Page 21] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[21ページ]のRFC階層構造と多層生存性2002年11月
[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.
A.チウとJ.がより合わせる[14]、「ルータ失敗の後の共同IP/光学の層の王政復古」、Proc。 2001年の'アナハイム(カリフォルニア)の行進のOFC'2001。
[15] K. Kompella and Y. Rekhter, "Multi-area MPLS Traffic
Engineering", Work in Progress.
[15] 「マルチ領域MPLS交通工学」というK.KompellaとY.Rekhterは進行中で働いています。
[16] G. Ash, et. al., "Requirements for Multi-Area TE", Work in
Progress.
[16] et G.灰、アル、「マルチ領域Teのための要件」、ProgressのWork。
[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シグナリングのためのCrankbackルート設定拡張子」は進行中で働いています。
[18] C-Y Lee, A. Celer, N. Gammage, S. Ghanti, G. Ash, "Distributed
Route Exchangers", Work in Progress.
[18] C-Yリー、N.Gammage、S.Ghanti、G.灰、「分配されたルート交換器」というA.Celerは進行中で働いています。
[19] C-Y Lee and S. Ghanti, "Path Request and Path Reply Message",
Work in Progress.
[19] 「経路要求と経路応答メッセージ」というC-YのリーとS.Ghantiは進行中で働いています。
[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の上の交通工学のための要件」RFC2702(1999年9月)。
[21] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[21] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
8. Acknowledgments
8. 承認
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.
多くの指示が、本書では取って、Bala Rajagoplan、グレッグ・バーンスタイン、Yangguangシュー、およびAvriドーリアによって提供された洞察に満ちた質問によって初期の努力におけるチームによって導かれました。 これのAppendix 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.
最初の草稿のリリースの後に、多くのコメントを受けました。 入力ジェリーAsh、Sudheer Dharanikota、チャックKalmanek、ダン・コラー、リンドン・オング、スティーブPlote、およびヤング・シューからありがとうございます。
9. Contributing Authors
9. 作者を寄付します。
Jim Boyle (PDNets), Rob Coltun (Movaz), Tim Griffin (AT&T), Ed Kern, Tom Reddington (Lucent) and Malin Carlzon.
ジム・ボイル(PDNets)、Coltun(Movaz)、ティム・グリフィン(AT&T)、エドKern、トムReddington(透明な)、およびマリン・カールソンから、略奪してください。
Lai, et. al. Informational [Page 22] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[22ページ]のRFC階層構造と多層生存性2002年11月
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. 決められた一定の要求を決定する際に、デザインチームは正確に「生存性」という概念、「回復」、「保護」、「保護の切り換え」、「回復」、などが「別ルートで送る」であり、および彼らの関係を定義するべきです。 これは、要件docが、正確にこれらのどれが記述されるかを説明するのを可能にするでしょう。 以下では、「回復」という用語は、広いセットの方針とメカニズムが以前はよく生存性を確実にしていたのを示すのに使用されます。
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ネットワーク(落ち着いて転送ネットワークでかぶせられたLSRsを、例えば、光学の)でLSPsの王政復古をネットワークでつなぎますか? アプローチの共通点、またはアプローチの最適化が、より重要ですか?
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つのネットワーク層の向こう側の回復手順の間の相互作用のための要件は何ですか? (例、ネットワークがPtとのPtの光の接続の上でわかったMPLS。) そのような場合の下で
(a) Are there any criteria to choose which layer should provide
protection?
(a) どの層が保護を提供するはずであるかを選ぶために、どんな評価基準もありますか?
Lai, et. al. Informational [Page 23] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[23ページ]のRFC階層構造と多層生存性2002年11月
(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. 水平面(同じネットワーク層の中の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) 異なった回復メカニズムがそうであるなら、境界の2つの側で実行されていて、それらの相互作用に関する要件は何ですか?
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アプリケーションですか?
Lai, et. al. Informational [Page 24] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[24ページ]のRFC階層構造と多層生存性2002年11月
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. ネットワーク要素の間の回復プロトコルメッセージを伝えるのに使用されるシグナリング移送機構(例えば、中では、オーバーヘッドバイトはIPネットワークなどの上でバンドの外でSDH/Sonetの上で組になる)に関する要件は何ですか? シグナリングチャンネルに関する帯域幅と他の要件は何ですか?
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. 回復観点からの制御飛行機とデータ飛行機の故障の間の相関関係のための要件は何ですか?
Lai, et. al. Informational [Page 25] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[25ページ]のRFC階層構造と多層生存性2002年11月
Editors' Addresses
エディタのアドレス
Wai Sum Lai AT&T 200 Laurel Avenue Middletown, NJ 07748, USA
Wai合計レイAT&T200ローレルアベニューミドルタウン、ニュージャージー 07748、米国
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ワールドコム22001LoudounカウンティーのPkwy Ashburn、ヴァージニア 20147、米国
EMail: dave.mcdysan@wcom.com
メール: dave.mcdysan@wcom.com
Lai, et. al. Informational [Page 26] RFC 3386 Hierarchy & Multilayer Survivability November 2002
etレイ、アル。 3386年の情報[26ページ]のRFC階層構造と多層生存性2002年11月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Lai, et. al. Informational [Page 27]
etレイ、アル。 情報[27ページ]
一覧
スポンサーリンク
