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 and links
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
RFC, FYI, BCP