draft-ietf-bmwg-protection-term-01.txt   draft-ietf-bmwg-protection-term-02.txt 
Network Working Group Network Working Group
Internet Draft Internet Draft
Expires: September 2007 Expires: January 2008
Intended Status: Informational Intended Status: Informational
S. Poretsky S. Poretsky
Reef Point Systems Reef Point Systems
R. Papneja R. Papneja
Isocore Isocore
J. Karthik J. Karthik
S.Vapiwala
Cisco Systems Cisco Systems
Benchmarking Terminology for Protection Performance Benchmarking Terminology for Protection Performance
<draft-ietf-bmwg-protection-term-01.txt > <draft-ietf-bmwg-protection-term-02.txt >
Intellectual Property Rights (IPR) statement: Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 8 skipping to change at page 2, line 8
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Protection Performance Protection Performance
Abstract Abstract
This document provides common terminology and metrics for This document provides common terminology and metrics for benchmarking
benchmarking the performance of sub-IP layer protection the performance of sub-IP layer protection mechanisms. The performance
mechanisms. The performance benchmarks are measured at the benchmarks are measured at the IP-Layer, so avoid dependence on
IP-Layer, so avoid dependence on specific sub-IP protections specific sub-IP protection mechanisms. The benchmarks and terminology
mechanisms. The benchmarks and terminology can be applied in can be applied in methodology documents for different sub-IP layer
methodology documents for different sub-IP layer protection protection mechanisms such as Automatic Protection Switching (APS),
mechanisms such as Automatic Protection Switching (APS), Virtual Router Redundancy Protocol (VRRP), Stateful High Availability
Virtual Router Redundancy Protocol (VRRP), and Multi-Protocol (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR).
Label Switching Fast Reroute (MPLS-FRR).
Table of Contents Table of Contents
1. Introduction..............................................3 1. Introduction..............................................3
2. Existing definitions......................................4 2. Existing definitions......................................4
3. Test Considerations.......................................4 3. Test Considerations.......................................4
3.1. Path.................................................5 3.1. Path.................................................5
3.1.1. Path............................................5 3.1.1. Path............................................5
3.1.2. Tunnel..........................................6 3.1.2. Tunnel..........................................6
3.1.3. Working Path....................................6 3.1.3. Working Path....................................6
3.1.4. Primary Path....................................7 3.1.4. Primary Path....................................7
skipping to change at page 2, line 39 skipping to change at page 2, line 38
3.1.7. Standby Backup Path.............................8 3.1.7. Standby Backup Path.............................8
3.1.8. Dynamic Backup Path.............................9 3.1.8. Dynamic Backup Path.............................9
3.1.9. Disjoint Paths..................................9 3.1.9. Disjoint Paths..................................9
3.1.10. Shared Risk Link Group (SRLG)..................10 3.1.10. Shared Risk Link Group (SRLG)..................10
3.2. Protection...........................................10 3.2. Protection...........................................10
3.2.1. Protection Switching System.....................10 3.2.1. Protection Switching System.....................10
3.2.2. Link Protection.................................11 3.2.2. Link Protection.................................11
3.2.3. Node Protection.................................11 3.2.3. Node Protection.................................11
3.2.4. Path Protection.................................12 3.2.4. Path Protection.................................12
3.2.5. Backup Span.....................................12 3.2.5. Backup Span.....................................12
3.2.6 Protected Interface.............................12
3.3. Failure..............................................13 3.3. Failure..............................................13
3.3.1. Failure Detection...............................13 3.3.1. Failover Event..................................13
3.3.2. Failover Event..................................13 3.3.2. Failure Detection...............................13
3.3.3. Failover........................................14 3.3.3. Failover........................................14
3.3.4. Restoration (Failover recovery).................14 3.3.4. Restoration (Failover recovery).................14
3.3.5. Reversion.......................................15 3.3.5. Reversion.......................................15
3.4. Nodes................................................15 3.4. Nodes................................................15
3.4.1. Protection-Switching Node.......................15 3.4.1. Protection-Switching Node.......................15
3.4.2. Non-Protection Switching Node...................15 3.4.2. Non-Protection Switching Node...................15
3.4.3. Failover Node...................................16 3.4.3. Failover Node...................................16
3.4.4. Merge Node......................................16 3.4.4. Merge Node......................................16
Protection Performance Protection Performance
3.4.5. Point of Local repair (PLR).....................17 3.4.5. Point of Local repair (PLR).....................17
3.4.6. Head-end Failover Node..........................17 3.4.6. Head-end Failover Node..........................17
3.5. Metrics..............................................18 3.5. Metrics..............................................18
3.5.1. Failover Packet Loss............................18 3.5.1. Failover Packet Loss............................18
3.5.2. Reversion Packet Loss...........................18 3.5.2. Reversion Packet Loss...........................18
3.5.3. Primary Path Latency............................19 3.5.3. Primary Path Latency............................19
3.5.4. Backup Path Latency.............................19 3.5.4. Backup Path Latency.............................19
3.6. Benchmarks...........................................19 3.6. Benchmarks...........................................20
3.6.1. Failover Time...................................19 3.6.1. Failover Time...................................20
3.6.2. Additive Backup Latency.........................20 3.6.2. Additive Backup Latency.........................21
3.6.3. Reversion Time..................................21 3.6.3. Reversion Time..................................21
4. Acknowledgments...........................................22 3.7 Failover Calculation Method...........................22
5. IANA Considerations.......................................22 3.7.1 Time-Based Loss Method...........................22
6. Security Considerations...................................22 3.7.2 Packet-Based Loss Method.........................22
7. References................................................22 3.7.3 Timestamp-Based Method...........................23
7.1. Normative References.................................22 4. Acknowledgments...........................................24
7.2. Informative References...............................23 5. IANA Considerations.......................................24
8. Author's Address..........................................23 6. Security Considerations...................................24
7. References................................................24
7.1. Normative References.................................24
7.2. Informative References...............................24
8. Author's Address..........................................25
1. Introduction 1. Introduction
The IP network layer provides route convergence to protect data The IP network layer provides route convergence to protect data
traffic against planned and unplanned failures in the internet. traffic against planned and unplanned failures in the internet.
Fast convergence times are critical to maintain reliable network Fast convergence times are critical to maintain reliable network
connectivity and performance. Technologies that function at sub-IP connectivity and performance. Technologies that function at sub-IP
layers can be enabled to provide further protection of IP layers can be enabled to provide further protection of IP
traffic by providing the failure recovery at the sub-IP layers so traffic by providing the failure recovery at the sub-IP layers so
that the outage is not observed at the IP-layer. Such technologies that the outage is not observed at the IP-layer. Such technologies
skipping to change at page 4, line 12 skipping to change at page 4, line 12
protection mechanisms are measured at the IP layer, so that the protection mechanisms are measured at the IP layer, so that the
results are always measured in reference to IP and independent of results are always measured in reference to IP and independent of
Protection Performance Protection Performance
the specific protection mechanism being used. The purpose of this the specific protection mechanism being used. The purpose of this
document is to provide a single terminology for benchmarking sub-IP document is to provide a single terminology for benchmarking sub-IP
protection mechanisms. It is intended that there can exist unique protection mechanisms. It is intended that there can exist unique
methodology documents for each sub-IP protection mechanism. methodology documents for each sub-IP protection mechanism.
Figure 1 shows the fundamental model that is to be used in Figure 1 shows the fundamental model that is to be used in
benchmarking sub-IP protection mechanisms. Protection Switching benchmarking sub-IP protection mechanisms. The sequence of
consists of a minimum of two Protection-Switching Nodes with a events is Failover Event, Failure Detection, Failover, Restoration
Primary Path and a Backup Path. A Failover Event occurs along the (Failover recovery), and optionally Reversion. Protection
Primary Path. A tester is set outside the two nodes as it sends Switching consists of a minimum of two Protection-Switching Nodes
and receives IP traffic along the Working Path. The Working Path with a Primary Path and a Backup Path. A Failover Event occurs
is the Primary Path prior to the Failover Event and the Backup Path along the Primary Path. A tester is set outside the two nodes as
following the Failover Event. If Reversion is supported then the 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 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.
+-----------+ +-----------+
+--------------------| Tester |<-------------------+ +--------------------| Tester |<-------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| Primary | | | Primary | |
| +--------+ Path v +--------+ | | +--------+ Path v +--------+ |
| | |------------------------>| | | | | |------------------------>| | |
+--->| Node 1 | | Node 2 |----+ +--->| Node 1 | | Node 2 |----+
| |- - - - - - - - - - - - >| | | |- - - - - - - - - - - - >| |
+--------+ Backup Path +--------+ +--------+ Backup Path +--------+
| | | |
| IP-Layer Forwarding | | IP-Layer Forwarding |
+-------------------------------------------+ +-------------------------------------------+
Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms
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.
Protection Performance Protection Performance
2. Existing definitions 2. Existing definitions
This document draws on existing terminology defined in other BMWG This document uses existing terminology defined in other BMWG
work. Examples include, but are not limited to: work. Examples include, but are not limited to:
Latency [Ref.[2], section 3.8] Latency [Ref.[2], section 3.8]
Frame Loss Rate [Ref.[2], section 3.6] Frame Loss Rate [Ref.[2], section 3.6]
Throughput [Ref.[2], section 3.17] Throughput [Ref.[2], section 3.17]
Device Under Test (DUT) [Ref.[3], section 3.1.1] Device Under Test (DUT) [Ref.[3], section 3.1.1]
System Under Test (SUT) [Ref.[3], section 3.1.2] System Under Test (SUT) [Ref.[3], section 3.1.2]
Out-of-order Packet [Ref.[4], section 3.3.2] Out-of-order Packet [Ref.[4], section 3.3.2]
Duplicate Packet [Ref.[4], section 3.3.3] Duplicate Packet [Ref.[4], section 3.3.3]
Packet Loss [Ref.[7], Section 3.5]
Packet Reordering [Ref.[10] section 3.3]
This document adopts the definition format in Section 2 of RFC 1242 This document adopts the definition format in Section 2 of RFC 1242
[2]. [2].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [5]. document are to be interpreted as described in BCP 14, RFC 2119 [5].
RFC 2119 defines the use of these key words to help make the RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
3. Test Considerations 3. Test Considerations
This section discusses the fundamentals of MPLS Protection
testing:
-The types of network events that causes failover
-Indications for failover
-the use of data traffic
-Traffic generation
-LSP Scaling
-Reversion of LSP
-IGP Selection
3.1. Path 3.1. Path
3.1.1 Path 3.1.1 Path
Definition: Definition:
A sequence of nodes, <R1, ..., Rn>, with the following A sequence of nodes, <R1, ..., Rn>, with the following
properties: properties:
- R1 is the ingress node and forwards IP packets, which input - R1 is the ingress node and forwards IP packets, which input
into DUT/SUT, to R2 as sub-IP frames. into DUT/SUT, to R2 as sub-IP frames.
- Ri is a node which forwards data frames to R[i+1] for all i, - Ri is a node which forwards data frames to R[i+1] for all i,
skipping to change at page 11, line 14 skipping to change at page 11, line 14
Protection Performance Protection Performance
Discussion: Discussion:
The Protection Switching System MUST have a Primary Path The Protection Switching System MUST have a Primary Path
and a Backup Path. The Backup Path MAY be a Standby and a Backup Path. The Backup Path MAY be a Standby
Backup Path or a dynamic Backup Path. The Protection Backup Path or a dynamic Backup Path. The Protection
Switching System includes the mechanisms for both Failure Switching System includes the mechanisms for both Failure
Detection and Failover. Detection and Failover.
Measurement units: Measurement units: n/a
Issues: Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failure Detection Failure Detection
Failover Failover
3.2.2. Link Protection 3.2.2. Link Protection
Definition: Definition:
A Backup Path that provides protection for link failure. A backup path is signal to next node avoiding protected
interface that provide protection for link failure
Discussion: Discussion:
Link Protection may or may not protect the entire Primary Link Protection may or may not protect the entire Primary
Path. Path.
Measurement units: n/a Measurement units: n/a
Issues: Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
3.2.3. Node Protection 3.2.3. Node Protection
Definition: Definition:
A Backup Path that provides protection for failure of a A backup path is signal to next to next node avoiding
single node and its directly connected links. protected node that provide protection failure of link or
node.
Discussion: Discussion:
Node Protection may or may not protect the entire Primary Node Protection may or may not protect the entire Primary
Path. Node Protection also provides Link Protection. Path. Node Protection also provides Link Protection.
Measurement units: n/a Measurement units: n/a
Issues: Issues: None
See Also: See Also:
Primary Path
Backup Path
Link Protection Link Protection
Protection Performance Protection Performance
3.2.4. Path Protection 3.2.4. Path Protection
Definition: Definition:
A Backup Path that provides protection for the entire A Backup Path that provides protection for the entire
Primary Path. Primary Path.
Discussion: Discussion:
Path Protection provides Node Protection and Link Protection Path Protection provides Node Protection and Link Protection
for every node and link along the Primary Path. A Backup for every node and link along the Primary Path. A Backup
Path providing Path Protection MUST have the same ingress Path providing Path Protection MUST have the same ingress
node as the Primary Path. node as the Primary Path.
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Node Protection Node Protection
Link protection Link protection
3.2.5. Backup Span 3.2.5. Backup Span
Definition: Definition:
The number of nodes in the Primary Path that are protected The numbers of hop used by backup tunnel to protected link or
by a Backup Path. node.
Discussion: Discussion:
Measurement units: Measurement units: number of nodes
number of nodes
Issues: Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Protection Performance
3.3. Failure
3.3.1. Failure Detection 3.2.6 Protected Interface
Definition: Definition:
To identify a Primary Path failure at a sub-IP layer. A interface which primary path is signaled over and protected by
backup tunnel
Discussion: Discussion:
Failure Detection occurs at the 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 may affect a set of links which share a single SRLG
(e.g. port with many sub-interfaces). A failure may affect
multiple links that are not part of SRLG.
Measurement units: Measurement units: None
n/a
Issues: Issues: None
See Also: See Also:
Primary Path
3.3.2. Failover Event Protection Performance
3.3. Failure
3.3.1. Failover Event
Definition: Definition:
The occurrence of a planned or unplanned action in the network The occurrence of a planned or unplanned action in the network
that results in a change in the Path that data traffic traverses. that results in a change in the Path that data traffic traverses.
Discussion: Discussion:
Failover Events include, but are not limited to, link failure Failover Events include, but are not limited to, link failure
and router failure. Routing changes are considered Convergence and router failure. Routing changes are considered Convergence
Events [7] and are not Failover Events. This restricts Events [7] and are not Failover Events. This restricts
Failover Events to sub-IP layers. Failover may be at the PLR or Failover Events to sub-IP layers. Failover may be at the PLR or
skipping to change at page 14, line 4 skipping to change at page 13, line 31
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Failure Detection Failure Detection
Disjoint Path Disjoint Path
3.3.2. 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 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 may affect a set of links which share a single SRLG
(e.g. port with many sub-interfaces). A failure may affect
multiple links that are not part of SRLG.
Measurement units:
n/a
Issues:
See Also:
Primary Path
Protection Performance Protection Performance
3.3.3. Failover 3.3.3. Failover
Definition: Definition:
To switch data traffic from the Primary Path to the Backup To switch data traffic from the Primary Path to the Backup
Path upon a Failover Event. Path upon a Failover Event.
Discussion: Discussion:
Failover to a Backup Path provides Link Protection, Node Failover to a Backup Path provides Link Protection, Node
Protection, or Path Protection. Failover is complete when Protection, or Path Protection. Failover is complete when
Lost Packets, Out-of-Order Packets, and Duplicate Packets Lost Packets, Out-of-Order Packets, and Duplicate Packets
skipping to change at page 14, line 28 skipping to change at page 14, line 29
n/a n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Event Failover Event
3.3.4. Restoration 3.3.4. Restoration
Definition: Definition:
The act of Failover Recovery in which the Primary Path is The act of Failover Recovery in which the Primary Path is
restored following a Failover Event. restored following a Failover Event.
Discussion: Discussion:
Failure Recovery MUST occur when the Backup Path is the Restoration MUST occur while the Backup Path is the
Working Path. The Backup Path is maintained as the Working Path. The Backup Path is maintained as the
Working Path during Failure Recovery. This implies that Working Path during Failure Recovery. This implies that
the service is either restored fully or partially. Usually, the service is either restored fully or partially.
FRR restoration can cause congestion, but primary paths Restoration can cause congestion, but primary paths
rerouting avoid restoration. An unavoidable problem in any rerouting avoid restoration. An unavoidable problem in any
restoration is the discontinuity in end to end delay when restoration is the discontinuity in end to end delay when
the primary and backup path delays differ significantly. If the primary and backup path delays differ significantly. If
the backup path has a shorter delay out of order delivery the backup path has a shorter delay out of order delivery
may occur if restoration is fast. If the backup path is may occur if restoration is fast. If the backup path is
longer then a sudden increase in delay will occur which can longer then a sudden increase in delay will occur which can
affect real time applications which use playback buffers to affect real time applications which use playback buffers to
remove limited jitter. remove limited jitter.
Measurement units: Measurement units:
skipping to change at page 16, line 44 skipping to change at page 16, line 44
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
3.4.4. Merge Node 3.4.4. Merge Node
Definition: Definition:
A node along the Primary Path that is also the egress node A Node along the primary path where backup path terminates
of the Backup Path. .
Discussion: Discussion:
The Merge Node can be any node along the Primary Path The Merge Node can be any node along the Primary Path
except the ingress node of the Primary Path. There can be except the ingress node of the Primary Path. There can be
multiple Merge Nodes along a Primary Path. A Merge Node multiple Merge Nodes along a Primary Path. A Merge Node
can be the egress node for a single or multiple Backup can be the egress node for a single or multiple Backup
Paths. The Merge Node MUST be the egress to the Backup Paths. The Merge Node MUST be the egress to the Backup
Path. The Merge Node MAY also be the egress of the Path. The Merge Node MAY also be the egress of the
Primary Path or point of local repair (PLR). Primary Path or point of local repair (PLR).
skipping to change at page 17, line 17 skipping to change at page 17, line 17
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
PLR PLR
Failover Failover
3.4.5. Point of Local repair (PLR) 3.4.5. Point of Local repair (PLR)
Definition: Definition:
The head-end LSR of a backup tunnel or a detour LSP. A node that uses a Backup Path to protect another
node or link.
Discussion: Discussion:
Based on the functionality of the PLR, its role is defined Based on the functionality of the PLR, its role is defined
based on the type of method used. If it is one-to-one based on the type of method used. If the one-to-one backup
backup method, the PLR is responsible for computing a method is used, the PLR is responsible for computing a
separate backup LSP, called a detour LSP for each LSP that separate Backup Path for each Primary Path. In the case
PLR is protecting. In the case the facility backup method the facility backup method is used, the PLR creates a
is used, the PLR creates a single bypass tunnel that can single Backup Path that can be used to protect multiple
be used to protect multiple LSPs. Primary Paths.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
skipping to change at page 18, line 31 skipping to change at page 18, line 31
Discussion: Discussion:
Packet loss can be observed as a reduction of forwarded Packet loss can be observed as a reduction of forwarded
traffic from the maximum forwarding rate. Failover Packet traffic from the maximum forwarding rate. Failover Packet
Loss includes packets that were lost and packets that were Loss includes packets that were lost and packets that were
delayed due to buffering. Failover Packet Loss MAY reach delayed due to buffering. Failover Packet Loss MAY reach
100% of the offered load. 100% of the offered load.
Measurement units: Measurement units:
Number of Packets Number of Packets
Issues: Issues: None
See Also: See Also:
Failover Event Failover Event
Failover Failover
3.5.2. Reversion Packet Loss 3.5.2. Reversion Packet Loss
Definition: Definition:
The amount of packet loss produced by Reversion. The amount of packet loss produced by Reversion.
Discussion: Discussion:
Packet loss can be observed as a reduction of forwarded Packet loss can be observed as a reduction of forwarded
traffic from the maximum forwarding rate. Reversion Packet traffic from the maximum forwarding rate. Reversion Packet
Loss includes packets that were lost and packets that were Loss includes packets that were lost and packets that were
delayed due to buffering. Reversion Packet Loss MAY reach delayed due to buffering. Reversion Packet Loss MAY reach
100% of the offered load. 100% of the offered load.
Measurement units: Number of Packets Measurement units: Number of Packets
Issues: Issues: None
See Also: See Also:
Reversion Reversion
Protection Performance Protection Performance
3.5.3. Primary Path Latency 3.5.3. Primary Path Latency
Definition: Definition:
Latency [2] measured along the Primary Path. Latency [2] measured along the Primary Path.
Discussion: Discussion:
Measurement units: Measurement units:
seconds seconds
Issues: Issues: None
See Also: See Also:
Primary Path Primary Path
3.5.4. Backup Path Latency 3.5.4. Backup Path Latency
Definition: Definition:
Latency [2] measured along the Backup Path. Latency [2] measured along the Backup Path.
Discussion: Discussion:
Measurement units: Measurement units:
seconds seconds
Issues: Issues: None
See Also: See Also:
Backup Path Backup Path
Protection Performance
3.6. Benchmarks 3.6. Benchmarks
3.6.1. Failover Time 3.6.1. Failover Time
Definition: Definition:
The amount of time it takes for Failover to complete so The amount of time it takes for Failover to complete so
that the Backup Path is the Working Path. that the Backup Path is the Working Path.
Protection Performance
Discussion: Discussion:
Failover Time can be calculated from Failover Packet Loss Failover Time can be calculated using the Time-Based Loss
that occurs due to a Failover Event and Failover as shown Method (TBLM), Packet-Based Loss Method (PBLM), or
below in Equation 1: Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
(Equation 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: Measurement units:
Seconds Seconds
Issues: Issues: None
See Also: See Also:
Failover Failover
Failover Packet loss Failover Time
Working Path Working Path
Backup Path Backup Path
Time-Based Loss Method (TBLM)
Packet-Based Loss Method (PBLM)
Timestamp-Based Method (TBM)
Protection Performance
3.6.2. Additive Backup Latency 3.6.2. Additive Backup Latency
Definition: Definition:
The amount of increased latency resulting from data traffic The amount of increased latency resulting from data traffic
traversing the Backup Path instead of the Primary Path. traversing the Backup Path instead of the Primary Path.
Discussion: Discussion:
Additive Backup Latency is calculated using Equation 2 as Additive Backup Latency is calculated using Equation 1 as
shown below: shown below:
(Equation 2) Additive Backup Latency = (Equation 1) Additive Backup Latency =
Backup Path Latency - Primary Path Latency. Backup Path Latency - Primary Path Latency.
Measurement units: Measurement units:
Seconds Seconds
Protection Performance
Issues: Issues:
Additive Backup Latency MAY be a negative result. Additive Backup Latency MAY be a negative result.
This is theoretically possible, but could be indicative This is theoretically possible, but could be indicative
of a sub-optimum network configuration . of a sub-optimum network configuration .
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Primary Path Latency Primary Path Latency
Backup Path Latency Backup Path Latency
3.6.3. Reversion Time 3.6.3. Reversion Time
Definition: Definition:
The amount of time it takes for Reversion to complete so The amount of time it takes for Reversion to complete so
that the Primary Path is restored as the Working Path. that the Primary Path is restored as the Working Path.
Discussion: Discussion:
Reversion Time can be calculated from Reversion Packet Reversion Time can be calculated using the Time-Based Loss
Loss that occurs due to a Failure Recovery as shown Method (TBLM), Packet-Based Loss Method (PBLM), or
below in Equation 3: Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
(Equation 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.
Measurement units: Measurement units:
Seconds Seconds
Issues: Issues: None
See Also: See Also:
Reversion Reversion
Primary Path Primary Path
Working Path Working Path
Reversion Packet Loss Reversion Packet Loss
Failure Recovery Time-Based Loss Method (TBLM)
Packet-Based Loss Method (PBLM)
Timestamp-Based Method (TBM)
Protection Performance
3.7 Failover Calculation Method
3.7.1 Time-Based Loss Method (TBLM)
Definition:
The method to calculate Failover Time (or Reversion Time) using a
time scale to measure duration of packet loss.
Discussion:
Traffic generators provide statistics which show the duration of
failure on a time scale to granularity of milliseconds 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.
Measurement units:
Milliseconds
Issues: None
See Also:
Failover
Packet-Based Loss Method
3.7.2 Packet-Based Loss Method (PBLM)
Definition:
The method used to calculate Failover Time (or Reversion Time)
from the amount of Packet Loss.
Discussion:
Failover Time can be calculated using PBLM is from Failover
Packet Loss that occurs due to a Failover Event and Failover
as shown below in Equation 2:
(Equation 2) Failover (or Reversion) Time =
Number of packets drop/(rate per
second * 1000) milliseconds
Packet based loss method includes failure detection time and
time for data traffic to begin traversing the Backup Path.
Measurement units:
milliseconds
Issues:
See Also:
Failover
Time-Based Loss Method
Protection Performance
3.7.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 with granularity of
milliseconds based on the observation of unimpaired packets,
using Equation 3.
(Equation 3)
Failover (or Reversion) Time = Time2 - Time1
where
Time1 is the arrival time of the last unimpaired packet before
the effects of Failover (or Reversion) are observed in the packet
stream.
Time2 is the arrival time of the first unimpaired packet
following the observation of impaired packets due to Failover
(or Reversion) in the packet stream.
Unimpaired packets are normal packets that are not lost,
reordered, or duplicated. A reordered packet is defined in
[10, section 3.3]. A duplicate packet is defined in
[4, section 3.3.3]. A lost packet is defined in
[7, Section 3.5]. Unimpaired packets may be detected by checking
a sequence number in the payload, where the sequence number equals
the next expected number for an unimpaired packet. A sequence gap
or sequence reversal may indicate 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
Protection Performance Protection Performance
4. Acknowledgements 4. Acknowledgements
We would like thank Curtis Villamizar for providing input to the We would like thank the BMWG and particularly Al Morton and Curtis
existing definitions, and proposing text for the new definitions Villamizar for their reviews, comments, and contributions to this
on the BMWG mailing list. work.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA considerations. This document requires no IANA considerations.
6. Security Considerations 6. Security Considerations
This document only addresses terminology for the performance This document only addresses terminology for the performance
benchmarking of protection systems, and the information contained benchmarking of protection systems, and the information contained
in this document has no effect on the security of the Internet. in this document has no effect on the security of the Internet.
7. References 7. References
skipping to change at page 22, line 35 skipping to change at page 24, line 35
Network Interconnection Devices", RFC 1242, July 1991. Network Interconnection Devices", RFC 1242, July 1991.
[3] Mandeville, R., "Benchmarking Terminology for LAN [3] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
[4] Poretsky, S., et al., "Terminology for Benchmarking [4] Poretsky, S., et al., "Terminology for Benchmarking
Network-layer Traffic Control Mechanisms", RFC 4689, Network-layer Traffic Control Mechanisms", RFC 4689,
November 2006. November 2006.
[5] Bradner, S., "Key words for use in RFCs to Indicate [5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, July 1997.
[6] Paxson, V., et al., "Framework for IP Performance Metrics", [6] Paxson, V., et al., "Framework for IP Performance Metrics",
RFC 2330, May 1998. RFC 2330, May 1998.
[7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP [7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-12, Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-13,
work in progress, February 2007. work in progress, July 2007.
[8] P. Pan., et al., "Fast Reroute Extensions to RSVP-TE for LSP [8] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC 4090, May 2005. Tunnels", RFC 4090, May 2005.
Protection Performance
[9] Nichols, K., et al, "Definition of the Differentiated [9] Nichols, K., et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998. RFC 2474, December 1998.
[10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
November 2006.
7.2. Informative References 7.2. Informative References
None.
None
Protection Performance
8. Author's Address 8. Author's Address
Scott Poretsky Scott Poretsky
Reef Point Systems Reef Point Systems
8 New England Executive Park 8 New England Executive Park
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 508 439 9008 Phone: + 1 508 439 9008
EMail: sporetsky@reefpoint.com EMail: sporetsky@reefpoint.com
skipping to change at page 24, line 4 skipping to change at page 25, line 31
Phone: 1 703 860 9273 Phone: 1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Jay Karthik Jay Karthik
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0533 Phone: +1 978 936 0533
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
Protection Performance
Samir Vapiwala
Cisco System
300 Beaver Brook Road
Boxborough, MA 01719
USA
Phone: +1 978 936 1484
Email: vapiwala@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Protection Performance
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 66 change blocks. 
141 lines changed or deleted 259 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/