Internet Engineering Task Force
INTERNET-DRAFT Scott Poretsky
Expires in: January 2006 Reef Point Systems
Rajiv Papneja
Isocore
Takumi Kimura
NTT SIL
July 2005
Benchmarking Terminology for Protection Performance
<draft-poretsky-protection-term-00.txt>
Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 1]
INTERNET-DRAFT Protection Performance Terminology July 2005
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, so avoid
dependence on specific sub-IP protections mechanisms. The benchmarks
and terminology can be applied in methodology documents for different
sub-IP layer protection mechanisms such as Automatic Link Protection
(APS) for SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and
Fast Reroute for Multi-Protocol Label Switching (MPLS).
Table of Contents
1. Introduction .............................................. 3
2. Existing definitions ...................................... 4
3. Term definitions .......................................... 4
3.1 Paths
3.1.1 Path ............................................... 4
3.1.2 Working Path ....................................... 5
3.1.3 Primary Path ....................................... 5
3.1.4 Protected Primary Path .............................. 6
3.1.5 Backup Path ........................................ 6
3.1.6 Standby Backup Path ................................ 6
3.1.7 Dynamic Backup Path ................................ 7
3.2 Protection
3.2.1 Protection Switching System ......................... 7
3.2.2 Link Protection .................................... 8
3.2.3 Node Protection .................................... 8
3.2.4 Path Protection .................................... 8
3.2.5 Backup Span ........................................ 9
3.3 Failure
3.3.1 Failure Detection .................................. 9
3.3.2 Failover ........................................... 10
3.3.3 Failover Event ...................................... 10
3.3.4 Failure Recovery ................................... 10
3.3.5 Reversion .......................................... 11
3.4 Nodes
3.4.1 Protection-Switching Node .......................... 11
3.4.2 Non-Protection-Switching Node ...................... 12
3.4.3 Failover Node ...................................... 12
3.4.4 Merge Node ......................................... 12
3.5 Metrics
3.5.1 Failover Packet Loss ............................... 13
3.5.2 Reversion Packet Loss ...............................13
3.5.3 Primary Path Latency ............................... 14
3.5.4 Backup Path Latency ................................ 14
3.6 Benchmarks
3.6.1 Failover Time ...................................... 14
3.6.2 Additive Backup Latency ............................. 15
3.6.3 Reversion Time ...................................... 15
4. IANA Considerations ........................................ 16
5. Security Considerations ................................... 16
6. References ................................................ 16
7. Authors' Addresses ........................................ 17
Poretsky, Papneja, and Kimura Expires July 2005 [Page 2]
INTERNET-DRAFT Protection Performance Terminology July 2005
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. 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 technologies
include High Availability (HA) stateful failover. Virtual Router
Redundancy Protocol (VRRP), Automatic Link Protection (APS) for
SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast
Reroute for Multi-Protocol Label Switching (MPLS).
Benchmarking terminology and methodology have been defined for
IP-layer route convergence [7,8,9]. New terminology and
methodologies specific to benchmarking sub-IP layer protection
mechanisms are required. This will enable different implementations
of the same protection mechanisms to be benchmarked and evaluated.
In addition, different protection mechanisms can be benchmarked and
evaluated. 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. It is intended that there can exist unique
methodology documents for each sub-IP protection mechanism.
Figure 1 shows the fundamental model that is to be used in
benchmarking sub-IP protection mechanisms. Protection Switching
consists of a minimum of two Protection-Switching Nodes with a
Primary Path and a Backup Path. A Failover Event occurs along the
Primary Path. A tester is set outside the two nodes as it sends
and receives IP traffic along the Working Path. The Working Path
is the Primary Path prior to the Failover Event and the Backup Path
following the Failover Event. If Reversion is supported then the
+-----------+
+--------------------| Tester |<-------------------+
| +-----------+ |
| IP Traffic | Failover IP Traffic |
| | Event |
| Primary | |
| +--------+ Path v +--------+ |
| | |------------------------>| | |
+--->| Node 1 | | Node 2 |----+
| |- - - - - - - - - - - - >| |
+--------+ Backup Path +--------+
| IP-Layer Forwarding |
+-------------------------------------------+
Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms
Poretsky, Papneja, and Kimura Expires July 2005 [Page 3]
INTERNET-DRAFT Protection Performance Terminology July 2005
Working Path is the Primary Path after Failure Recovery. The
tester MUST record the IP packet sequence numbers, departure time,
and arrival time so that the metrics of Failover Time, Additive
Latency, and Reversion Time can be measured. The Tester may be a
single device or a test system.
2. Existing definitions
This document draws on existing terminology defined in other BMWG
work. Examples include, but are not limited to:
Latency [RFC 1242, section 3.8]
Frame Loss Rate [RFC 1242, section 3.6]
Throughput [RFC 1242, section 3.17]
Device Under Test (DUT) [RFC 2285, section 3.1.1]
System Under Test (SUT) [RFC 2285, section 3.1.2]
Out-of-order Packet [Ref.[4], section 3.3.2]
Duplicate Packet [Ref.[4], section 3.3.3]
This document adopts the definition format in Section 2 of RFC 1242.
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 RFC 2119.
3. Term definitions
3.1 Path
3.1.1 Path
Definition:
A sequence of nodes, <R1, ..., Rn>, with the following
properties:
- R1 is the ingress node and forwards IP packets, which input
into DUT/SUT, to R2 as sub-IP frames.
- Ri is a node which forwards data frames to R[i+1] for all i,
1<i<n, based on information in the sub-IP layer.
- Rn is the egress node and it outputs sub-IP frames from
DUT/SUT as IP packets.
Discussion:
The path is defined in the sub-IP layer in this document, unlike
an IP path in RFC 2026. For example, the SONET/SDH path, the
label switched path for MPLS, and optical path. 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 (RFC 2474)
will transverse one or more paths. The path is unidirectional.
Measurement units:
n/a
Poretsky, Papneja, and Kimura Expires July 2005 [Page 4]
INTERNET-DRAFT Protection Performance Terminology July 2005
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:
3.1.2 Working Path
Definition:
The path that the DUT/SUT is currently using to forward packets.
Discussion:
A Primary Path is a Working Path before occurrence of a
Failover Event. A Backup Path becomes the Working Path
after a Failover Event.
Measurement units:
n/a
Issues:
See Also:
Path
Primary Path
Backup Path
3.1.3 Primary Path
Definition:
The preferred path for forwarding traffic between two or more
nodes.
Discussion:
Measurement units:
n/a
Issues:
See Also:
Path
Poretsky, Papneja, and Kimura Expires July 2005 [Page 5]
INTERNET-DRAFT Protection Performance Terminology July 2005
3.1.4 Protected Primary Path
Definition:
The Primary Path that is protected with a Backup Path.
Discussion:
Measurement units:
n/a
Issues:
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.
Discussion:
The Backup Path is the Working Path upon a Failover Event.
There are various types of Backup Paths: a dedicated recovery
path (1+1), which has 100% redundancy for a specific ordinary
path, a shared Backup Path (1:N), which is dedicated to the
protection for more than one specific Primary Path, and an
associated shared Backup Path (M:N) for which a specific set
of Backup Paths protects a specific set of more than one
Primary Path.
Measurement units:
n/a
Issues:
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:
Measurement units:
n/a
Poretsky, Papneja, and Kimura Expires July 2005 [Page 6]
INTERNET-DRAFT Protection Performance Terminology July 2005
Issues:
See Also:
Path
Working 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:
Measurement units:
n/a
Issues:
See Also:
Path
Working Path
Primary Path
Failover Event
3.2 Protection
3.2.1 Protection Switching System
Definition:
A SUT that is capable of Failover from a Primary to a Backup
Path.
Discussion:
The Protection Switching System MUST have a Primary Path and a
Backup Path. The Backup Path MAY be a Standby Backup Path or
a Dymanic Backup Path. The Protection Switching System includes
the mechanisms for both Failure Detection and Failover.
Measurement units:
Issues:
See Also:
Primary Path
Backup Path
Failure Detection
Failover
Poretsky, Papneja, and Kimura Expires July 2005 [Page 7]
INTERNET-DRAFT Protection Performance Terminology July 2005
3.2.2 Link Protection
Definition:
A Backup Path that provides protection for link failure.
Discussion:
Link Protection may or may not protect the entire Primary Path.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Backup Path
3.2.3 Node Protection
Definition:
A Backup Path that provides protection for failure of a single node
and its directly connected links.
Discussion:
Node Protection may or may not protect the entire Primary Path.
Node Protection also provides Link Protection.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Backup Path
Link Protection
3.2.4 Path Protection
Definition:
A Backup Path that provides protection for 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 MUST have the same ingress node as the
Primary Path.
Measurement units:
n/a
Issues:
Poretsky, Papneja, and Kimura Expires July 2005 [Page 8]
INTERNET-DRAFT Protection Performance Terminology July 2005
See Also:
Primary Path
Backup Path
Node Protection
Link protection
3.2.5 Backup Span
Definition:
The number of nodes in the Primary Path that are protected by a
Backup Path.
Discussion:
Measurement units:
number of nodes
Issues:
See Also:
Primary Path
Backup Path
3.3 Failure
3.3.1 Failure Detection
Definition:
To identify a Primary Path failure at a sub-IP layer.
Discussion:
Failure Detection occurs at the ingress node of the Primary
Path. Failure Dection occurs via a sub-IP mechanism such
as detection of a link down event or timeout for receipt
of a control packet.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Poretsky, Papneja, and Kimura Expires July 2005 [Page 9]
INTERNET-DRAFT Protection Performance Terminology July 2005
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 [7] and are not Failover Events. This restricts
Failover Events to sub-IP layers.
Measurement units:
n/a
Issues:
See Also:
Path
Failure Detection
3.3.3 Failover
Definition:
To switch data traffic from the Primary Path to the Backup Path
upon a Failover Event.
Discussion:
Failover to a Backup Path provides Link Protection, Node Protection,
or Path Protection. Failover is complete when Lost Packets,
Out-of-Order Packets, and Duplicate Packets are no longer observed.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Backup Path
Failover Event
3.3.4 Failure Recovery
Definition:
The act of the Primary Path being restored following a
Failover Event.
Discussion:
Failure Recovery MUST occur when the Backup Path is the
Working Path. The Backup Path is maintained as the
Working Path during Failure Recovery.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 10]
INTERNET-DRAFT Protection Performance Terminology July 2005
Measurement units:
Issues:
See Also:
Primary Path
Failover Event
Failure Recovery
Working Path
Backup Path
3.3.5 Reversion
Definition:
The act of restoring the Primary Path as the Working Path.
Discussion:
Protection Switching Systems may or may not support Reversion.
Reversion, if supported, MUST occur after Failure Recovery.
Measurement units:
n/a
Issues:
See Also:
Protection Switching System
Working Path
Primary Path
3.4 Nodes
3.4.1 Protection-Switching Node
Definition:
A node that is capable to participate in a Protection Switching
System.
Discussion:
The Protection Switching Node MAY be an ingress or egress for
a Primary Path or Backup Path.
Measurement units:
n/a
Issues:
See Also:
Protection Switching System
Primary Path
Backup Path
Poretsky, Papneja, and Kimura Expires July 2005 [Page 11]
INTERNET-DRAFT Protection Performance Terminology July 2005
3.4.2 Non-Protection Switching Node
Definition:
A node that not capable of participating in a Protection
Switching System, however it MAY exist along the Primary
Path or Backup Path.
Discussion:
Measurement units:
n/a
Issues:
See Also:
Protection Switching System
Primary Path
Backup Path
3.4.3 Failover Node
Definition:
A node along the Primary Path that is capable of Failover.
Discussion:
The Failover Node can be any node along the Primary Path
except the egress node of the Primary Path. There can be
multiple Failover Nodes along a Primary Path. The Failover
Node MUST be the ingress to the Backup Path. The Failover
Node MAY also be the ingress of the Primary Path.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Backup Path
Failover
3.4.4 Merge Node
Definition:
A node along the Primary Path that is also the egress node
of the Backup Path.
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 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.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 12]
INTERNET-DRAFT Protection Performance Terminology July 2005
Measurement units:
n/a
Issues:
See Also:
Primary Path
Backup Path
Failover
3.5 Metrics
3.5.1 Failover Packet Loss
Definition:
The amount of packet loss produced by a Failover Event
until Failover completes.
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 and packets that were delayed due to
buffering. Failover Packet Loss MAY reach 100% of the offered
load.
Measurement units:
Number of Packets
Issues:
See Also:
Failover Event
Failover
3.5.2 Reversion Packet Loss
Definition:
The amount of packet loss produced by Reversion.
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 and packets that were delayed due to
buffering. Reversion Packet Loss MAY reach 100% of the offered
load.
Measurement units:
Number of Packets
Issues:
See Also:
Reversion
Poretsky, Papneja, and Kimura Expires July 2005 [Page 13]
INTERNET-DRAFT Protection Performance Terminology July 2005
3.5.3 Primary Path Latency
Definition:
Latency [2] measured along the Primary Path.
Discussion:
Measurement units:
seconds
Issues:
See Also:
Primary Path
3.5.4 Backup Path Latency
Definition:
Latency [2] measured along the Backup Path.
Discussion:
Measurement units:
seconds
Issues:
See Also:
Backup Path
3.6 Benchmarks
3.6.1 Failover Time
Definition:
The amount of time it takes for Failover to complete so that
the Backup Path is the Working Path.
Discussion:
Failover Time can be calculated from Failover Packet Loss
that occurs due to a Failover Event and Failover as shown
below in Equation 1:
(eq 1) Failover Time =
Failover Packets Loss / Offered Load
NOTE: Units for this measurement are
packets / packets/second = seconds
Failover Time includes failure detection time and time for
data traffic to begin traversing the Backup Path.
Measurement units:
Seconds
Poretsky, Papneja, and Kimura Expires July 2005 [Page 14]
INTERNET-DRAFT Protection Performance Terminology July 2005
Issues:
See Also:
Failover
Failover Packet loss
Working Path
Bakup Path
3.6.2 Additive Backup Latency
Definition:
The amount of increased latency resulting from data traffic
traversing the Backup Path instead of the Primary Path.
Discussion:
Additive Backup Latency is calculated using Equation 2 as
shown below:
(eq 2) Additive Backup Latency =
Backup Path Latency - Primary Path Latency.
Measurement units:
Seconds
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.3 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 from Reversion Packet
Loss that occurs due to a Failure Recovery as shown
below in Equation 3:
(eq 3) Reversion Time =
Reversion Packets Loss / Offered Load
NOTE: Units for this measurement are
packets / packets/second = seconds
Reversion Time starts upon completion of Failure Recovery
and includes the time for data traffic to begin traversing
the Primary Path.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 15]
INTERNET-DRAFT Protection Performance Terminology July 2005
Measurement units:
Seconds
Issues:
See Also:
Reversion
Primary Path
Working Path
Reversion Packet Loss
Failure Recovery
4. IANA Considerations
This document requires no IANA considerations.
5. Security Considerations
This document only addresses terminology for the performance
benchmarking of protection systems, and the information contained in
this document has no effect on the security of the Internet.
6. References
6.1 Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[2] Bradner, S., Editor, "Benchmarking Terminology for
Network Interconnection Devices", RFC 1242, July 1991.
[3] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998.
[4] Perser, J., et al., "Terminology for Benchmarking Network-layer
Traffic Control Mechanisms",
Internet Draft, Work in Progress,
draft-ietf-bmwg-dsmterm-05.txt, February 2003.
[5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[6] Paxson, V., et al., "Framework for IP Performance Metrics",
RFC 2026, May 1998.
[7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-07, work
in progress, July 2005.
[8] Berkowitz, H., et al, "Terminology for Benchmarking BGP Device
Convergence in the Control Plane", RFC 4098, June 2005.
[9] White, R., et al, "OSPF Benchmarking Terminology and Concepts",
RFC 4062, April 2005.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 16]
INTERNET-DRAFT Protection Performance Terminology July 2005
7. Authors' Addresses
Scott Poretsky
Reef Point Systems
8 New England Executive Park
Burlington, MA 01803
USA
Phone: + 1 508 439 9008
EMail: sporetsky@reefpoint.com
Rajiv Papneja
Isocore
12359 Sunrise Valley Drive
Reston, VA 22102
USA
Phone: 1 703 860 9273
Email: rpapneja@isocore.com
Takumi Kimura
NTT Service Integration Laboratories
3-9-11 Midori-cho
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3026
EMail: takumi.kimura@lab.ntt.co.jp
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 17]
INTERNET-DRAFT Protection Performance Terminology July 2005
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Poretsky, Papneja, and Kimura Expires July 2005 [Page 18]