diff options
Diffstat (limited to 'doc/rfc/rfc6414.txt')
| -rw-r--r-- | doc/rfc/rfc6414.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc6414.txt b/doc/rfc/rfc6414.txt new file mode 100644 index 0000000..603d4f2 --- /dev/null +++ b/doc/rfc/rfc6414.txt @@ -0,0 +1,1851 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Poretsky +Request for Comments: 6414 Allot Communications +Category: Informational R. Papneja +ISSN: 2070-1721 Huawei + J. Karthik + S. Vapiwala + Cisco Systems + November 2011 + + + Benchmarking Terminology for Protection Performance + +Abstract + + This document provides common terminology and metrics for + benchmarking the performance of sub-IP layer protection mechanisms. + The performance benchmarks are measured at the IP layer; protection + may be provided at the sub-IP layer. The benchmarks and terminology + can be applied in methodology documents for different sub-IP layer + protection mechanisms such as Automatic Protection Switching (APS), + Virtual Router Redundancy Protocol (VRRP), Stateful High Availability + (HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6414. + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 1] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. Scope ......................................................4 + 1.2. General Model ..............................................5 + 2. Existing Definitions ............................................8 + 3. Test Considerations .............................................9 + 3.1. Paths ......................................................9 + 3.1.1. Path ................................................9 + 3.1.2. Working Path .......................................10 + 3.1.3. Primary Path .......................................10 + 3.1.4. Protected Primary Path .............................11 + 3.1.5. Backup Path ........................................11 + 3.1.6. Standby Backup Path ................................12 + 3.1.7. Dynamic Backup Path ................................12 + 3.1.8. Disjoint Paths .....................................13 + 3.1.9. Point of Local Repair (PLR) ........................13 + 3.1.10. Shared Risk Link Group (SRLG) .....................14 + 3.2. Protection ................................................14 + 3.2.1. Link Protection ....................................14 + 3.2.2. Node Protection ....................................15 + + + +Poretsky, et al. Informational [Page 2] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + 3.2.3. Path Protection ....................................15 + 3.2.4. Backup Span ........................................16 + 3.2.5. Local Link Protection ..............................16 + 3.2.6. Redundant Node Protection ..........................17 + 3.2.7. State Control Interface ............................17 + 3.2.8. Protected Interface ................................18 + 3.3. Protection Switching ......................................18 + 3.3.1. Protection-Switching System ........................18 + 3.3.2. Failover Event .....................................19 + 3.3.3. Failure Detection ..................................19 + 3.3.4. Failover ...........................................20 + 3.3.5. Restoration ........................................20 + 3.3.6. Reversion ..........................................21 + 3.4. Nodes .....................................................22 + 3.4.1. Protection-Switching Node ..........................22 + 3.4.2. Non-Protection-Switching Node ......................22 + 3.4.3. Headend Node .......................................23 + 3.4.4. Backup Node ........................................23 + 3.4.5. Merge Node .........................................24 + 3.4.6. Primary Node .......................................24 + 3.4.7. Standby Node .......................................25 + 3.5. Benchmarks ................................................26 + 3.5.1. Failover Packet Loss ...............................26 + 3.5.2. Reversion Packet Loss ..............................26 + 3.5.3. Failover Time ......................................27 + 3.5.4. Reversion Time .....................................27 + 3.5.5. Additive Backup Delay ..............................28 + 3.6. Failover Time Calculation Methods .........................28 + 3.6.1. Time-Based Loss Method (TBLM) ......................29 + 3.6.2. Packet-Loss-Based Method (PLBM) ....................29 + 3.6.3. Timestamp-Based Method (TBM) .......................30 + 4. Security Considerations ........................................31 + 5. References .....................................................32 + 5.1. Normative References ......................................32 + 5.2. Informative References ....................................32 + 6. Acknowledgments ................................................32 + + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 3] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +1. Introduction + + The IP network layer provides route convergence to protect data + traffic against planned and unplanned failures in the Internet. Fast + convergence times are critical to maintain reliable network + connectivity and performance. Convergence Events [6] are recognized + at the IP Layer so that Route Convergence [6] occurs. Technologies + that function at sub-IP layers can be enabled to provide further + protection of IP traffic by providing the failure recovery at the + sub-IP layers so that the outage is not observed at the IP layer. + Such sub-IP protection technologies include, but are not limited to, + High Availability (HA) stateful failover, Virtual Router Redundancy + Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH, + Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for + Multiprotocol Label Switching (MPLS-FRR) [9]. + +1.1. Scope + + Benchmarking terminology was defined for IP-layer convergence in [6]. + Different terminology and methodologies specific to benchmarking sub- + IP layer protection mechanisms are required. The metrics for + benchmarking the performance of sub-IP protection mechanisms are + measured at the IP layer, so that the results are always measured in + reference to IP and independent of the specific protection mechanism + being used. The purpose of this document is to provide a single + terminology for benchmarking sub-IP protection mechanisms. + + A common terminology for sub-IP layer protection mechanism + benchmarking enables different implementations of a protection + mechanism to be benchmarked and evaluated. In addition, + implementations of different protection mechanisms can be benchmarked + and evaluated. It is intended that there can exist unique + methodology documents for each sub-IP protection mechanism based upon + this common terminology document. The terminology can be applied to + methodologies that benchmark sub-IP protection mechanism performance + with a single stream of traffic or multiple streams of traffic. The + traffic flow may be unidirectional or bidirectional as to be + indicated in the methodology. + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 4] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +1.2. General Model + + The sequence of events to benchmark the performance of sub-IP + protection mechanisms is as follows: + + 1. Failover Event - Primary Path fails + 2. Failure Detection - Failover Event is detected + 3. Failover - Backup Path becomes the Working Path due to Failover + Event + 4. Restoration - Primary Path recovers from a Failover Event + 5. Reversion (optional) - Primary Path becomes the Working Path + + These terms are further defined in this document. + + Figures 1 through 5 show models that MAY be used when benchmarking + sub-IP protection mechanisms, which MUST use a Protection-Switching + System that consists of a minimum of two Protection-Switching Nodes, + an Ingress Node known as the Headend Node and an Egress Node known as + the Merge Node. The Protection-Switching System MUST include either + a Primary Path and Backup Path, as shown in Figures 1 through 4, or a + Primary Node and Standby Node, as shown in Figure 5. A Protection- + Switching System may provide link protection, node protection, path + protection, local link protection, and high availability, as shown in + Figures 1 through 5, respectively. A Failover Event occurs along the + Primary Path or at the Primary Node. The Working Path is the Primary + Path prior to the Failover Event and the Backup Path after the + Failover Event. A Tester is set outside the two paths or nodes as it + sends and receives IP traffic along the Working Path. The tester + MUST record the IP packet sequence numbers, departure time, and + arrival time so that the metrics of Failover Time, Additive Latency, + Packet Reordering, Duplicate Packets, and Reversion Time can be + measured. The Tester may be a single device or a test system. If + Reversion is supported, then the Working Path is the Primary Path + after Restoration (Failure Recovery) of the Primary Path. + + Link Protection, as shown in Figure 1, provides protection when a + Failover Event occurs on the link between two nodes along the Primary + Path. Node Protection, as shown in Figure 2, provides protection + when a Failover Event occurs at a Node along the Primary Path. Path + Protection, as shown in Figure 3, provides protection for link or + node failures for multiple hops along the Primary Path. Local Link + Protection, as shown in Figure 4, provides sub-IP protection of a + link between two nodes, without a Backup Node. An example of such a + sub-IP protection mechanism is SONET APS. High Availability + Protection, as shown in Figure 5, provides protection of a Primary + Node with a redundant Standby Node. State Control is provided + between the Primary and Standby Nodes. Failure of the Primary Node + + + + +Poretsky, et al. Informational [Page 5] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + is detected at the sub-IP layer to force traffic to switch to the + Standby Node, which has state maintained for zero or minimal packet + loss. + + +-----------+ + +--------------| Tester |<-----------------------+ + | +-----------+ | + | IP Traffic | Failover IP Traffic | + | | Event | + | ------------ | ---------- | + +--->| Ingress/ | V | Egress/ |---+ + |Headend Node|------------------|Merge Node| Primary + ------------ ---------- Path + | ^ + | --------- | Backup + +--------| Backup |-------------+ Path + | Node | + --------- + + Figure 1. System Under Test (SUT) for Sub-IP Link Protection + + +-----------+ + +--------------------| Tester |<-----------------+ + | +-----------+ | + | IP Traffic | Failover IP Traffic | + | | Event | + | V | + | ------------ -------- ---------- | + +--->| Ingress/ | |Midpoint| | Egress/ |---+ + |Headend Node|----| Node |----|Merge Node| Primary + ------------ -------- ---------- Path + | ^ + | --------- | Backup + +--------| Backup |-------------+ Path + | Node | + --------- + + Figure 2. System Under Test (SUT) for Sub-IP Node Protection + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 6] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + +-----------+ + +---------------------------| Tester |<----------------------+ + | +-----------+ | + | IP Traffic | Failover IP Traffic | + | | Event | + | Primary Path | | + | ------------ -------- | -------- ---------- | + +--->| Ingress/ | |Midpoint| V |Midpoint| | Egress/ |---+ + |Headend Node|----| Node |---| Node |---|Merge Node| + ------------ -------- -------- ---------- + | ^ + | --------- -------- | Backup + +--------| Backup |----| Backup |--------+ Path + | Node | | Node | + --------- -------- + + Figure 3. System Under Test (SUT) for Sub-IP Path Protection + + +-----------+ + +--------------------| Tester |<-------------------+ + | +-----------+ | + | IP Traffic | Failover IP Traffic | + | | Event | + | Primary | | + | +--------+ Path v +--------+ | + | | |------------------------>| | | + +--->| Ingress| | Egress |----+ + | Node |- - - - - - - - - - - - >| Node | + +--------+ Backup Path +--------+ + | | + | IP-Layer Forwarding | + +<----------------------------------------->+ + + Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection + + + + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 7] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + +-----------+ + +-----------------| Tester |<--------------------+ + | +-----------+ | + | IP Traffic | Failover IP Traffic | + | | Event | + | V | + | --------- -------- ---------- | + +--->| Ingress | |Primary | | Egress/ |------+ + | Node |----| Node |----|Merge Node| Primary + --------- -------- ---------- Path + | State |Control ^ + | Interface |(Optional) | + | --------- | + +---------| Standby |---------+ + | Node | + --------- + + Figure 5. System Under Test (SUT) + for Sub-IP Redundant Node Protection + + Some protection-switching technologies may use a series of steps that + differ from the general model. The specific differences SHOULD be + highlighted in each technology-specific methodology. Note that some + protection-switching technologies are endowed with the ability to re- + optimize the working path after a node or link failure. + +2. Existing Definitions + + This document uses existing terminology defined in other BMWG work. + Examples include, but are not limited to: + + Latency [2], Section 3.8 + Frame Loss Rate [2], Section 3.6 + Throughput [2], Section 3.17 + Device Under Test (DUT) [3], Section 3.1.1 + System Under Test (SUT) [3], Section 3.1.2 + Offered Load [3], Section 3.5.2 + Out-of-order Packet [4], Section 3.3.4 + Duplicate Packet [4], Section 3.3.5 + Forwarding Delay [4], Section 3.2.4 + Jitter [4], Section 3.2.5 + Packet Loss [6], Section 3.5 + Packet Reordering [7], Section 3.3 + + This document has the following frequently used acronyms: + + DUT Device Under Test + SUT System Under Test + + + +Poretsky, et al. Informational [Page 8] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + This document adopts the definition format in Section 2 of RFC 1242 + [2]. Terms defined in this document are capitalized when used within + this document. + + The keywords "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 [5]. + RFC 2119 defines the use of these keywords to help make the intent of + Standards Track documents as clear as possible. While this document + uses these keywords, this document is not a Standards Track document. + +3. Test Considerations + +3.1. Paths + +3.1.1. Path + + Definition: + A unidirectional sequence of nodes <R1, ..., Rn> and links + <L12,... L(n-1)n> with the following properties: + + a. R1 is the ingress node and forwards IP packets, which input + into DUT/SUT, to R2 as sub-IP frames over link L12. + + b. Ri is a node which forwards data frames to R(i+1) over Link + Li(i+1) for all i, 1<i<n-1, based on information in the sub-IP + layer. + + c. Rn is the egress node, and it outputs sub-IP frames from + DUT/SUT as IP packets. L(n-1)n is the link between the R(n-1) + and Rn. + + Discussion: + The path is defined in the sub-IP layer in this document, unlike + an IP path in RFC 2026 [1]. One path may be regarded as being + equivalent to one IP link between two IP nodes, i.e., R1 and Rn. + The two IP nodes may have multiple paths for protection. A packet + will travel on only one path between the nodes. Packets belonging + to a microflow [10] will traverse one or more paths. The path is + unidirectional. For example, the link between R1 and R2 in the + direction from R1 to R2 is L12. For traffic flowing in the + reverse direction from R2 to R1, the link is L21. Example paths + are the SONET/SDH path and the label switched path for MPLS. + + Measurement Units: + n/a + + + + + +Poretsky, et al. Informational [Page 9] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Issues: + "A bidirectional path", which transmits traffic in both directions + along the same nodes, consists of two unidirectional paths. + Therefore, the two unidirectional paths belonging to "one + bidirectional path" will be treated independently when + benchmarking for "a bidirectional path". + + See Also: + Working Path + Primary Path + Backup Path + +3.1.2. Working Path + + Definition: + The path that the DUT/SUT is currently using to forward packets. + + Discussion: + A Primary Path is the Working Path before occurrence of a Failover + Event. A Backup Path shall become the Working Path after a + Failover Event. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path + Primary Path + Backup Path + +3.1.3. Primary Path + + Definition: + The preferred point-to-point path for forwarding traffic between + two or more nodes. + + Discussion: + The Primary Path is the Path that traffic traverses prior to a + Failover Event. + + Measurement Units: + n/a + + Issues: + None. + + + +Poretsky, et al. Informational [Page 10] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + See Also: + Path + Failover Event + +3.1.4. Protected Primary Path + + Definition: + A Primary Path that is protected with a Backup Path. + + Discussion: + A Protected Primary Path must include at least one Protection- + Switching Node. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path + Primary Path + +3.1.5. Backup Path + + Definition: + A path that exists to carry data traffic only if a Failover Event + occurs on a Primary Path. + + Discussion: + The Backup Path shall become the Working Path upon a Failover + Event. A Path may have one or more Backup Paths. A Backup Path + may protect one or more Primary Paths. There are various types of + Backup Paths: + + a. dedicated recovery Backup Path (1+1) or (1:1), which has 100% + redundancy for a specific ordinary path + + b. shared Backup Path (1:N), which is dedicated to the protection + for more than one specific Primary Path + + c. associated shared Backup Path (M:N) for which a specific set of + Backup Paths protects a specific set of more than one Primary + Path + + + + + + + +Poretsky, et al. Informational [Page 11] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + A Backup Path may be signaled or unsignaled. The Backup Path must + be created prior to the Failover Event. The Backup Path generally + originates at the point of local repair (PLR) and terminates at a + node along a primary path. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path + Working Path + Primary Path + +3.1.6. Standby Backup Path + + Definition: + A Backup Path that is established prior to a Failover Event to + protect a Primary Path. + + Discussion: + The Standby Backup Path and Dynamic Backup Path provide + protection, but are established at different times. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Backup Path + Primary Path + Failover Event + +3.1.7. Dynamic Backup Path + + Definition: + A Backup Path that is established upon occurrence of a Failover + Event. + + Discussion: + The Standby Backup Path and Dynamic Backup Path provide + protection, but are established at different times. + + + + + +Poretsky, et al. Informational [Page 12] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Backup Path + Standby Backup Path + Failover Event + +3.1.8. Disjoint Paths + + Definition: + A pair of paths that do not share a common link or nodes. + + Discussion: + Two paths are disjoint if they do not share a common node or link + other than the ingress and egress. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path + Primary Path + SRLG + +3.1.9. Point of Local Repair (PLR) + + Definition: + A node capable of Failover along the Primary Path that is also the + ingress node for the Backup Path to protect another node or link. + + Discussion: + Any node along the Primary Path from the ingress node to the + penultimate node may be a PLR. The PLR may use a single Backup + Path for protecting one or more Primary Paths. There can be + multiple PLRs along a Primary Path. The PLR must be an ingress to + a Backup Path. The PLR can be any node along the Primary Path + except the egress node of the Primary Path. The PLR may + simultaneously be a Headend Node when it is serving the role as + ingress to the Primary Path and the Backup Path. If the PLR is + also the Headend Node, then the Backup Path is a Disjoint Path + from the ingress to the Merge Node. + + + +Poretsky, et al. Informational [Page 13] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + Backup Path + Failover + +3.1.10. Shared Risk Link Group (SRLG) + + Definition: + SRLG is a set of links that share the same risk (physical or + logical) within a network. + + Discussion: + SRLG is considered the set of links to be avoided when the primary + and secondary paths are considered disjoint. The SRLG will fail + as a group if the shared resource (physical or anything abstract + such as software version) fails. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path Primary Path + +3.2. Protection + +3.2.1. Link Protection + + Definition: + A Backup Path that is signaled to at least one Backup Node to + protect for failure of interfaces and links along a Primary Path. + + Discussion: + Link Protection may or may not protect the entire Primary Path. + Link Protection is shown in Figure 1. + + Measurement Units: + n/a + + + + + +Poretsky, et al. Informational [Page 14] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Issues: + None. + + See Also: + Primary Path Backup Path + +3.2.2. Node Protection + + Definition: + A Backup Path that is signaled to at least one Backup Node to + protect for failure of interfaces, links, and nodes along a + Primary Path. + + Discussion: + Node Protection may or may not protect the entire Primary Path. + Node Protection also provides Link Protection. Node Protection is + shown in Figure 2. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Link Protection + +3.2.3. Path Protection + + Definition: + A Backup Path that is signaled to at least one Backup Node to + provide protection along the entire Primary Path. + + Discussion: + Path Protection provides Node Protection and Link Protection for + every node and link along the Primary Path. A Backup Path + providing Path Protection may have the same ingress node as the + Primary Path. Path Protection is shown in Figure 3. + + Measurement Units: + n/a + + Issues: + None. + + + + + + + +Poretsky, et al. Informational [Page 15] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + See Also: + Primary Path + Backup Path + Node Protection + Link Protection + +3.2.4. Backup Span + + Definition: + The number of hops used by a Backup Path. + + Discussion: + The Backup Span is an integer obtained by counting the number of + nodes along the Backup Path. + + Measurement Units: + number of nodes + + Issues: + None. + + See Also: + Primary Path + Backup Path + +3.2.5. Local Link Protection + + Definition: + A Backup Path that is a redundant path between two nodes and does + not use a Backup Node. + + Discussion: + Local Link Protection must be provided as a Backup Path between + two nodes along the Primary Path without the use of a Backup Node. + Local Link Protection is provided by Protection-Switching Systems + such as SONET APS. Local Link Protection is shown in Figure 4. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Backup Path + Backup Node + + + + + +Poretsky, et al. Informational [Page 16] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.2.6. Redundant Node Protection + + Definition: + A Protection-Switching System with a Primary Node protected by a + Standby Node along the Primary Path. + + Discussion: + Redundant Node Protection is provided by Protection-Switching + Systems such as VRRP and HA. The protection mechanisms occur at + sub-IP layers to switch traffic from a Primary Node to Backup Node + upon a Failover Event at the Primary Node. Traffic continues to + traverse the Primary Path through the Standby Node. The failover + may be stateful, in which the state information may be exchanged + in-band or over an out-of-band State Control Interface. The + Standby Node may be active or passive. Redundant Node Protection + is shown in Figure 5. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + Primary Node + Standby Node + +3.2.7. State Control Interface + + Definition: + An out-of-band control interface used to exchange state + information between the Primary Node and Standby Node. + + Discussion: + The State Control Interface may be used for Redundant Node + Protection. The State Control Interface should be out-of-band. + It is possible to have Redundant Node Protection in which there is + no state control or state control is provided in-band. The State + Control Interface between the Primary and Standby Node may be one + or more hops. + + Measurement Units: + n/a + + Issues: + None. + + + + +Poretsky, et al. Informational [Page 17] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + See Also: + Primary Node + Standby Node + +3.2.8. Protected Interface + + Definition: + An interface along the Primary Path that is protected by a Backup + Path. + + Discussion: + A Protected Interface is an interface protected by a Protection- + Switching System that provides Link Protection, Node Protection, + Path Protection, Local Link Protection, and Redundant Node + Protection. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + Backup Path + +3.3. Protection Switching + +3.3.1. Protection-Switching System + + Definition: + A DUT/SUT that is capable of Failure Detection and Failover from a + Primary Path to a Backup Path or Standby Node when a Failover + Event occurs. + + Discussion: + The Protection-Switching System must include either a Primary Path + and Backup Path, as shown in Figures 1 through 4, or a Primary + Node and Standby Node, as shown in Figure 5. The Backup Path may + be a Standby Backup Path or a Dynamic Backup Path. The + Protection-Switching System includes the mechanisms for both + Failure Detection and Failover. + + Measurement Units: + n/a + + Issues: + None. + + + +Poretsky, et al. Informational [Page 18] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + See Also: + Primary Path Backup Path Failover + +3.3.2. Failover Event + + Definition: + The occurrence of a planned or unplanned action in the network + that results in a change in the Path that data traffic traverses. + + Discussion: + Failover Events include, but are not limited to, link failure and + router failure. Routing changes are considered Convergence Events + [6] and are not Failover Events. This restricts Failover Events + to sub-IP layers. Failover may be at the PLR or at the ingress. + If the failover is at the ingress, it is generally on a disjoint + path from the ingress to egress. + + Failover Events may result from failures such as link failure or + router failure. The change in path after Failover may have a + Backup Span of one or more nodes. Failover Events are + distinguished from routing changes and Convergence Events [6] by + the detection of the failure and subsequent protection switching + at a sub-IP layer. Failover occurs at a PLR or Primary Node. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Path + Failure Detection + Disjoint Path + +3.3.3. Failure Detection + + Definition: + The process to identify at a sub-IP layer a Failover Event at a + Primary Node or along the Primary Path. + + Discussion: + Failure Detection occurs at the Primary Node or ingress node of + the Primary Path. Failure Detection occurs via a sub-IP mechanism + such as detection of a link down event or timeout for receipt of a + control packet. A failure may be completely isolated. A failure + + + + + +Poretsky, et al. Informational [Page 19] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + may affect a set of links that share a single SRLG (e.g., port + with many sub-interfaces). A failure may affect multiple links + that are not part of the SRLG. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + +3.3.4. Failover + + Definition: + The process to switch data traffic from the protected Primary Path + to the Backup Path upon Failure Detection of a Failover Event. + + Discussion: + Failover to a Backup Path provides Link Protection, Node + Protection, or Path Protection. Failover is complete when Packet + Loss [6], Out-of-order Packets [4], and Duplicate Packets [4] are + no longer observed. Forwarding Delay [4] may continue to be + observed. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path Backup Path Failover Event + +3.3.5. Restoration + + Definition: + The state of failover recovery in which the Primary Path has + recovered from a Failover Event, but is not yet forwarding packets + because the Backup Path remains the Working Path. + + Discussion: + Restoration must occur while the Backup Path is the Working Path. + The Backup Path is maintained as the Working Path during + Restoration. Restoration produces a Primary Path that is + + + + + +Poretsky, et al. Informational [Page 20] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + recovered from failure, but is not yet forwarding traffic. + Traffic is still being forwarded by the Backup Path functioning as + the Working Path. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + Failover Event + Failure Recovery + Working Path + Backup Path + +3.3.6. Reversion + + Definition: + The state of failover recovery in which the Primary Path has + become the Working Path so that it is forwarding packets. + + Discussion: + Protection-Switching Systems may or may not support Reversion. + Reversion, if supported, must occur after Restoration. Packet + forwarding on the Primary Path resulting from Reversion may occur + either fully or partially over the Primary Path. A potential + problem with Reversion is the discontinuity in end-to-end delay + when the Forwarding Delays [4] along the Primary Path and Backup + Path are different, possibly causing Out-of-order Packets [4], + Duplicate Packets [4], and increased Jitter [4]. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Protection-Switching System + Working Path + Primary Path + + + + + + + + +Poretsky, et al. Informational [Page 21] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.4. Nodes + +3.4.1. Protection-Switching Node + + Definition: + A node that is capable of participating in a Protection Switching + System. + + Discussion: + The Protection-Switching Node may be an ingress or egress for a + Primary Path or Backup Path, such as used for MPLS Fast Reroute + configurations. The Protection-Switching Node may provide + Redundant Node Protection as a Primary Node in a Redundant chassis + configuration with a Standby Node, such as used for VRRP and HA + configurations. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Protection-Switching System + +3.4.2. Non-Protection-Switching Node + + Definition: + A node that is not capable of participating in a Protection + Switching System, but may exist along the Primary Path or Backup + Path. + + Discussion: + None. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Protection-Switching System + Primary Path + Backup Path + + + + + + +Poretsky, et al. Informational [Page 22] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.4.3. Headend Node + + Definition: + The ingress node of the Primary Path. + + Discussion: + The Headend Node may also be a PLR when it is serving in the dual + role as the ingress to the Backup Path. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + PLR + Failover + +3.4.4. Backup Node + + Definition: + A node along the Backup Path. + + Discussion: + The Backup Node can be any node along the Backup Path. There may + be one or more Backup Nodes along the Backup Path. A Backup Node + may be the ingress, midpoint, or egress of the Backup Path. If + the Backup Path has only one Backup Node, then that Backup Node is + the ingress and egress of the Backup Path. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Backup Path + + + + + + + + + + + +Poretsky, et al. Informational [Page 23] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.4.5. Merge Node + + Definition: + A node along the Primary Path where Backup Path terminates. + + Discussion: + The Merge Node can be any node along the Primary Path except the + ingress node of the Primary Path. There can be multiple Merge + Nodes along a Primary Path. A Merge Node can be the egress node + for a single Backup Path or multiple Backup Paths. The Merge Node + must be the egress to the Backup Path. The Merge Node may also be + the egress of the Primary Path or Point of Local Repair (PLR). + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Path + Backup Path + PLR + Failover + +3.4.6. Primary Node + + Definition: + A node along the Primary Path that is capable of Failover to a + redundant Standby Node. + + Discussion: + The Primary Node may be used for Protection-Switching Systems that + provide Redundant Node Protection, such as VRRP and HA. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Protection-Switching System Redundant Node Protection Standby Node + + + + + + + + +Poretsky, et al. Informational [Page 24] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.4.7. Standby Node + + Definition: + A redundant node to a Primary Node; it forwards traffic along the + Primary Path upon Failure Detection of the Primary Node. + + Discussion: + The Standby Node must be used for Protection-Switching Systems + that provide Redundant Node Protection, such as VRRP and HA. The + Standby Node must provide protection along the same Primary Path. + If the failover is to a Disjoint Path, then it is a Backup Node. + The Standby Node may be configured for 1:1 or N:1 protection. + + The communication between the Primary Node and Standby Node may be + in-band or across an out-of-band State Control Interface. The + Standby Node may be geographically dispersed from the Primary + Node. When geographically dispersed, the number of hops of + separation may increase failover time. + + The Standby Node may be passive or active. The Passive Standby + Node is not offered traffic and does not forward traffic until + Failure Detection of the Primary Node. Upon Failure Detection of + the Primary Node, traffic offered to the Primary Node is instead + offered to the Passive Standby Node. The Active Standby Node is + offered traffic and forwards traffic along the Primary Path while + the Primary Node is also active. Upon Failure Detection of the + Primary Node, traffic offered to the Primary Node is switched to + the Active Standby Node. + + Measurement Units: + n/a + + Issues: + None. + + See Also: + Primary Node + State Control Interface + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 25] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.5. Benchmarks + +3.5.1. Failover Packet Loss + + Definition: + The amount of packet loss produced by a Failover Event until + Failover completes, where the measurement begins when the last + unimpaired packet is received by the Tester on the Protected + Primary Path and ends when the first unimpaired packet is received + by the Tester on the Backup Path. + + Discussion: + Packet loss can be observed as a reduction of forwarded traffic + from the maximum forwarding rate. Failover Packet Loss includes + packets that were lost, reordered, or delayed. Failover Packet + Loss may reach 100% of the offered load. + + Measurement Units: + Number of Packets + + Issues: + None. + + See Also: + Failover Event + Failover + +3.5.2. Reversion Packet Loss + + Definition: + The amount of packet loss produced by Reversion, where the + measurement begins when the last unimpaired packet is received by + the Tester on the Backup Path and ends when the first unimpaired + packet is received by the Tester on the Protected Primary Path. + + Discussion: + Packet loss can be observed as a reduction of forwarded traffic + from the maximum forwarding rate. Reversion Packet Loss includes + packets that were lost, reordered, or delayed. Reversion Packet + Loss may reach 100% of the offered load. + + Measurement Units: + Number of Packets + + Issues: + None. + + + + + +Poretsky, et al. Informational [Page 26] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + See Also: + Reversion + +3.5.3. Failover Time + + Definition: + The amount of time it takes for Failover to successfully complete. + + Discussion: + Failover Time can be calculated using the Time-Based Loss Method + (TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method + (TBM). It is RECOMMENDED that the TBM is used. + + Measurement Units: + milliseconds + + Issues: + None. + + See Also: + Failover + Failover Time + Time-Based Loss Method (TBLM) + Packet-Loss-Based Method (PLBM) + Timestamp-Based Method (TBM) + +3.5.4. Reversion Time + + Definition: + The amount of time it takes for Reversion to complete so that the + Primary Path is restored as the Working Path. + + Discussion: + Reversion Time can be calculated using the Time-Based Loss Method + (TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method + (TBM). It is RECOMMENDED that the TBM is used. + + Measurement Units: + milliseconds + + Issues: + None. + + See Also: + Reversion + Primary Path + Working Path + Reversion Packet Loss + + + +Poretsky, et al. Informational [Page 27] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Time-Based Loss Method (TBLM) + Packet-Loss-Based Method (PLBM) + Timestamp-Based Method (TBM) + +3.5.5. Additive Backup Delay + + Definition: + The amount of increased Forwarding Delay [4] resulting from data + traffic traversing the Backup Path instead of the Primary Path. + + Discussion: + Additive Backup Delay is calculated using Equation 1 as shown + below: + + (Equation 1) + Additive Backup Delay = + Forwarding Delay(Backup Path) - + Forwarding Delay(Primary Path) + + Measurement Units: + milliseconds + + Issues: + Additive Backup Latency may be a negative result. This is + theoretically possible but could be indicative of a sub-optimum + network configuration. + + See Also: + Primary Path + Backup Path + Primary Path Latency + Backup Path Latency + +3.6. Failover Time Calculation Methods + + The following Methods may be assessed on a per-flow basis using at + least 16 flows spread over the routing table (using more flows is + better). Otherwise, the impact of a prefix-dependency in the + implementation of a particular protection technology could be missed. + However, the test designer must be aware of the number of packets per + second sent to each prefix, as this establishes sampling of the path + and the time resolution for measurement of Failover time on a per- + flow basis. + + + + + + + + +Poretsky, et al. Informational [Page 28] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +3.6.1. Time-Based Loss Method (TBLM) + + Definition: + The method to calculate Failover Time (or Reversion Time) using a + time scale on the Tester to measure the interval of Failover + Packet Loss. + + Discussion: + The Tester must provide statistics that show the duration of + failure on a time scale based on occurrence of packet loss on a + time scale. This is indicated by the duration of non-zero packet + loss. The TBLM includes failure detection time and time for data + traffic to begin traversing the Backup Path. Failover Time and + Reversion Time are calculated using the TBLM as shown in Equation + 2: + + (Equation 2) + (Equation 2a) + TBLM Failover Time = Time(Failover) - Time(Failover Event) + + (Equation 2b) + TBLM Reversion Time = Time(Reversion) - Time(Restoration) + + Where + + Time(Failover) = Time on the tester at the receipt of the first + unimpaired packet at egress node after the backup path became the + working path + + Time(Failover Event) = Time on the tester at the receipt of the + last unimpaired packet at egress node on the primary path before + failure + + Measurement Units: + milliseconds + + Issues: + None. + + See Also: + Failover + Packet-Loss-Based Method + +3.6.2. Packet-Loss-Based Method (PLBM) + + Definition: + The method used to calculate Failover Time (or Reversion Time) + from the amount of Failover Packet Loss. + + + +Poretsky, et al. Informational [Page 29] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + Discussion: + PLBM includes failure detection time and time for data traffic to + begin traversing the Backup Path. Failover Time can be calculated + using PLBM from the amount of Failover Packet Loss as shown below + in Equation 3. Note: If traffic is sent to more than 1 + destination, PLBM gives the average loss over the measured + destinations. + + (Equation 3) + (Equation 3a) + PLBM Failover Time = + (Number of packets lost / Offered Load rate) * 1000) + + (Equation 3b) + PLBM Restoration Time = + (Number of packets lost / Offered Load rate) * 1000) + + Units are packets/(packets/second) = seconds + + Measurement Units: + milliseconds + + Issues: + None. + + See Also: + Failover Time-Based Loss Method + +3.6.3. Timestamp-Based Method (TBM) + + Definition: + The method to calculate Failover Time (or Reversion Time) using a + time scale to quantify the interval between unimpaired packets + arriving in the test stream. + + Discussion: + The purpose of this method is to quantify the duration of failure + or reversion on a time scale based on the observation of + unimpaired packets. The TBM is calculated from Equation 2 with + the values obtained from the timestamp in the packet payload, + rather than from the Tester clock (which are used with the TBLM). + + Unimpaired packets are normal packets that are not lost, + reordered, or duplicated. A reordered packet is defined in + Section 3.3 of [7]. A duplicate packet is defined in Section + 3.3.5 of [4]. Unimpaired packets may be detected by checking a + + + + + +Poretsky, et al. Informational [Page 30] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + + sequence number in the payload, where the sequence number equals + the next expected number for an unimpaired packet. A sequence gap + or sequence reversal indicates impaired packets. + + For calculating Failover Time, the TBM includes failure detection + time and time for data traffic to begin traversing the Backup + Path. For calculating Reversion Time, the TBM includes Reversion + Time and time for data traffic to begin traversing the Primary + Path. + + Measurement Units: + milliseconds + + Issues: + None. + + See Also: + Failover + Failover Time + Reversion + Reversion Time + +4. Security Considerations + + Benchmarking activities as described in this memo are limited to + technology characterization using controlled stimuli in a laboratory + environment, with dedicated address space and the constraints + specified in the sections above. + + The benchmarking network topology will be an independent test setup + and MUST NOT be connected to devices that may forward the test + traffic into a production network or misroute traffic to the test + management network. + + Further, benchmarking is performed on a "black-box" basis, relying + solely on measurements observable external to the DUT/SUT. + + Special capabilities SHOULD NOT exist in the DUT/SUT specifically for + benchmarking purposes. Any implications for network security arising + from the DUT/SUT SHOULD be identical in the lab and in production + networks. + + + + + + + + + + +Poretsky, et al. Informational [Page 31] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +5. References + +5.1. Normative References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Benchmarking Terminology for Network + Interconnection Devices", RFC 1242, July 1991. + + [3] Mandeville, R., "Benchmarking Terminology for LAN Switching + Devices", RFC 2285, February 1998. + + [4] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana, + "Terminology for Benchmarking Network-layer Traffic Control + Mechanisms", RFC 4689, October 2006. + + [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [6] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for + Benchmarking Link-State IGP Data Plane Route Convergence", RFC + 6412, November 2011. + + [7] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and + J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. + + [8] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP) + Version 3 for IPv4 and IPv6", RFC 5798, March 2010. + +5.2. Informative References + + [9] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute + Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005. + + [10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of + the Differentiated Services Field (DS Field) in the IPv4 and + IPv6 Headers", RFC 2474, December 1998. + +6. Acknowledgments + + We would like thank the BMWG and particularly Al Morton and Curtis + Villamizar for their reviews, comments, and contributions to this + work. + + + + + + + +Poretsky, et al. Informational [Page 32] + +RFC 6414 Benchmarking Terms for Protection November 2011 + + +Authors' Addresses + + Scott Poretsky + Allot Communications + 300 TradeCenter + Woburn, MA 01801 + USA + Phone: + 1 508 309 2179 + EMail: sporetsky@allot.com + + Rajiv Papneja + Huawei Technologies + 2330 Central Expressway + Santa Clara, CA 95050 + USA + Phone: +1 571 926 8593 + EMail: rajiv.papneja@huawei.com + + Jay Karthik + Cisco Systems + 300 Beaver Brook Road + Boxborough, MA 01719 + USA + Phone: +1 978 936 0533 + EMail: jkarthik@cisco.com + + Samir Vapiwala + Cisco System + 300 Beaver Brook Road + Boxborough, MA 01719 + USA + Phone: +1 978 936 1484 + EMail: svapiwal@cisco.com + + + + + + + + + + + + + + + + + + +Poretsky, et al. Informational [Page 33] + |