draft-ietf-bmwg-protection-term-00.txt   draft-ietf-bmwg-protection-term-01.txt 
Network Working Group Network Working Group
Internet Draft Internet Draft
Expires: September 2007
Intended Status: Informational
S. Poretsky S. Poretsky
Reef Point Systems Reef Point Systems
R. Papneja R. Papneja
Isocore Isocore
J. Karthik J. Karthik
Cisco Systems Cisco Systems
October 2006
Benchmarking Terminology for Protection Performance Benchmarking Terminology for Protection Performance
<draft-ietf-bmwg-protection-term-00.txt > <draft-ietf-bmwg-protection-term-01.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 1, line 44 skipping to change at page 1, line 44
Internet-Drafts as reference material or to cite them other Internet-Drafts as reference material or to cite them other
than as "work in progress." than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
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 Internet Society (2006). 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 the performance of sub-IP layer protection benchmarking the performance of sub-IP layer protection
mechanisms. The performance benchmarks are measured at the mechanisms. The performance benchmarks are measured at the
IP-Layer, so avoid dependence on specific sub-IP protections IP-Layer, so avoid dependence on specific sub-IP protections
mechanisms. The benchmarks and terminology can be applied in mechanisms. The benchmarks and terminology can be applied in
methodology documents for different sub-IP layer protection methodology documents for different sub-IP layer protection
mechanisms such as Automatic Protection Switching (APS), mechanisms such as Automatic Protection Switching (APS),
Virtual Router Redundancy Protocol (VRRP), and Multi-Protocol Virtual Router Redundancy Protocol (VRRP), 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.......................................5 3. Test Considerations.......................................4
3.1. Path.................................................6 3.1. Path.................................................5
3.1.1. Path............................................6 3.1.1. Path............................................5
3.1.2. Tunnel..........................................7 3.1.2. Tunnel..........................................6
3.1.3. Working Path....................................7 3.1.3. Working Path....................................6
3.1.4. Primary Path....................................8 3.1.4. Primary Path....................................7
3.1.5. Protected Primary Path..........................8 3.1.5. Protected Primary Path..........................7
3.1.6. Backup Path.....................................9 3.1.6. Backup Path.....................................8
3.1.7. Standby Backup Path.............................9 3.1.7. Standby Backup Path.............................8
3.1.8. Dynamic Backup Path.............................10 3.1.8. Dynamic Backup Path.............................9
3.1.9. Disjoint Paths..................................10 3.1.9. Disjoint Paths..................................9
3.1.10. Shared Risk Link Group (SRLG)..................11 3.1.10. Shared Risk Link Group (SRLG)..................10
3.2. Protection...........................................11 3.2. Protection...........................................10
3.2.1. Protection Switching System.....................11 3.2.1. Protection Switching System.....................10
3.2.2. Link Protection.................................12 3.2.2. Link Protection.................................11
3.2.3. Node Protection.................................12 3.2.3. Node Protection.................................11
3.2.4. Path Protection.................................13 3.2.4. Path Protection.................................12
3.2.5. Backup Span.....................................13 3.2.5. Backup Span.....................................12
3.3. Failure..............................................14 3.3. Failure..............................................13
3.3.1. Failure Detection...............................14 3.3.1. Failure Detection...............................13
3.3.2. Failover Event..................................14 3.3.2. Failover Event..................................13
3.3.3. Failover........................................15 3.3.3. Failover........................................14
3.3.4. Restoration (Failover recovery).................16 3.3.4. Restoration (Failover recovery).................14
3.3.5. Reversion.......................................16 3.3.5. Reversion.......................................15
3.4. Nodes................................................17 3.4. Nodes................................................15
3.4.1. Protection-Switching Node.......................17 3.4.1. Protection-Switching Node.......................15
3.4.2. Non-Protection Switching Node...................17 3.4.2. Non-Protection Switching Node...................15
3.4.3. Failover Node...................................18 3.4.3. Failover Node...................................16
3.4.4. Merge Node......................................19 3.4.4. Merge Node......................................16
Protection Performance Protection Performance
3.4.5. Point of Local repair (PLR).....................19 3.4.5. Point of Local repair (PLR).....................17
3.4.6. Head-end Failover Node..........................20 3.4.6. Head-end Failover Node..........................17
3.5. Metrics..............................................20 3.5. Metrics..............................................18
3.5.1. Failover Packet Loss............................20 3.5.1. Failover Packet Loss............................18
3.5.2. Reversion Packet Loss...........................21 3.5.2. Reversion Packet Loss...........................18
3.5.3. Primary Path Latency............................22 3.5.3. Primary Path Latency............................19
3.5.4. Backup Path Latency.............................22 3.5.4. Backup Path Latency.............................19
3.5.5. Metrics.........................................22 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 4. Acknowledgments...........................................22
5. IANA Considerations.......................................22 5. IANA Considerations.......................................22
6. Security Considerations...................................22 6. Security Considerations...................................22
7. References................................................23 7. References................................................22
7.1. Normative References.................................23 7.1. Normative References.................................22
7.2. Informative References...............................24 7.2. Informative References...............................23
8. Author's Address..........................................24 8. Author's Address..........................................23
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
include High Availability (HA) stateful failover. Virtual Router includes High Availability (HA) stateful failover. Virtual Router
Redundancy Protocol (VRRP), Automatic Link Protection (APS) for Redundancy Protocol (VRRP), Automatic Link Protection (APS) for
SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast
Reroute for Multi-Protocol Label Switching (MPLS). Reroute for Multi-Protocol Label Switching (MPLS).
Benchmarking terminology and methodology have been defined for Benchmarking terminology have been defined for IP-layer route
IP-layer route convergence [7,8,9]. New terminology and convergence [7]. New terminology and methodologies specific
methodologies specific to benchmarking sub-IP layer protection to benchmarking sub-IP layer protection mechanisms are required.
mechanisms are required. This will enable different implementations This will enable different implementations of the same
of the same protection mechanisms to be benchmarked and evaluated. protection mechanisms to be benchmarked and evaluated. In
In addition, different protection mechanisms can be benchmarked and addition, different protection mechanisms can be benchmarked and
evaluated. The metrics for benchmarking the performance of sub-IP evaluated. The metrics for benchmarking the performance of sub-IP
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.
skipping to change at page 5, line 11 skipping to change at page 5, line 11
and arrival time so that the metrics of Failover Time, Additive and arrival time so that the metrics of Failover Time, Additive
Latency, and Reversion Time can be measured. The Tester may be a Latency, and Reversion Time can be measured. The Tester may be a
single device or a test system. 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 draws on existing terminology defined in other BMWG
work. Examples include, but are not limited to: work. Examples include, but are not limited to:
Latency [RFC 1242, section 3.8] Latency [Ref.[2], section 3.8]
Frame Loss Rate [RFC 1242, section 3.6] Frame Loss Rate [Ref.[2], section 3.6]
Throughput [RFC 1242, section 3.17] Throughput [Ref.[2], section 3.17]
Device Under Test (DUT) [RFC 2285, section 3.1.1] Device Under Test (DUT) [Ref.[3], section 3.1.1]
System Under Test (SUT) [RFC 2285, 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]
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].
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. 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
3.1. Path This section discusses the fundamentals of MPLS Protection
testing:
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 micro flow (RFC 2474)
will transverse one or more paths. The path is unidirectional.
Protection Performance
Measurement units:
n/a
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:
This section discusses the fundamentals of MPLS Protection testing:
-The types of network events that causes failover -The types of network events that causes failover
-Indications for failover -Indications for failover
-the use of data traffic -the use of data traffic
-Traffic generation -Traffic generation
-LSP Scaling -LSP Scaling
-Reversion of LSP -Reversion of LSP
-IGP Selection -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,
1<i<n, based on information in the sub-IP layer. 1<i<n, based on information in the sub-IP layer.
- Rn is the egress node and it outputs sub-IP frames from - Rn is the egress node and it outputs sub-IP frames from
DUT/SUT as IP packets. DUT/SUT as IP packets.
Protection Performance Protection Performance
Discussion: Discussion:
The path is defined in the sub-IP layer in this document, unlike 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 an IP path in RFC 2026 [1]. For example, the SONET/SDH path,
label switched path for MPLS, and optical path. One path may be the label switched path for MPLS, and optical path. One path
regarded as being equivalent to one IP link between two IP may be regarded as being equivalent to one IP link between two
nodes, i.e., R1 and Rn. The two IP nodes may have multiple 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 paths for protection. A packet will travel on only one path
between the nodes. Packets belonging to a microflow (RFC 2474) between the nodes. Packets belonging to a microflow [9]
will transverse one or more paths. The path is unidirectional. will transverse one or more paths. The path is unidirectional.
Measurement units: Measurement units:
n/a n/a
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. Tunnel 3.1.2. Tunnel
Definition: Definition:
Tunnel is a collection of related Paths. Tunnel is a collection of related Paths.
Discussion: Discussion:
A tunnel is used to carry a specific flow of traffic which is A Tunnel is used to carry a specific flow of traffic which
generally large aggregation of microflows, but may be any flow is generally large aggregation of microflows, but may be any
defined by a classifier at the ingress. A Tunnel may include two flow defined by a classifier at the ingress. A Tunnel may
primary paths during the MPLS make-before-break reroute. include two primary paths during the MPLS make-before-break
reroute.
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
Backup Path Backup Path
3.1.3. Working Path 3.1.3. Working Path
Definition: Definition:
The path that the DUT/SUT is currently using to forward packets. The path that the DUT/SUT is currently using to forward
packets.
Discussion: Discussion:
A Primary Path is a Working Path before occurrence of a A Primary Path is a Working Path before occurrence of a
Failover Event. A Backup Path becomes the Working Path Failover Event. A Backup Path becomes the Working Path after
after a Failover Event. a Failover Event.
Protection Performance Protection Performance
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Primary Path Primary Path
Backup Path Backup Path
3.1.4. Primary Path 3.1.4. Primary Path
Definition: Definition:
The preferred path for forwarding traffic between two or more The preferred path for forwarding traffic between two or
nodes. more nodes.
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
skipping to change at page 9, line 20 skipping to change at page 8, line 20
Event occurs. Event occurs.
Discussion: Discussion:
The Backup Path is the Working Path upon a Failover Event. The Backup Path is the Working Path upon a Failover Event.
There are various types of Backup Paths: a dedicated recovery There are various types of Backup Paths: a dedicated recovery
path (1+1), which has 100% redundancy for a specific ordinary path (1+1), which has 100% redundancy for a specific ordinary
path, a shared Backup Path (1:N), which is dedicated to the path, a shared Backup Path (1:N), which is dedicated to the
protection for more than one specific Primary Path, and an protection for more than one specific Primary Path, and an
associated shared Backup Path (M:N) for which a specific set associated shared Backup Path (M:N) for which a specific set
of Backup Paths protects a specific set of more than one of Backup Paths protects a specific set of more than one
Primary Path. Backup path is always computed before the failover Primary Path. Backup path is always computed before the
event. A new path computed after the failover event is simply failover event. A new path computed after the failover event
reroute of the primary path. A backup may be signaled or is simply reroute of the primary path. A backup may be
unsignalled. signaled or unsignaled.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
skipping to change at page 10, line 42 skipping to change at page 9, line 42
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
Failover Event Failover Event
3.1.9. Disjoint Paths 3.1.9. Disjoint Paths
Definition: Definition:
A pair of paths are considered disjoint if they do not share a A pair of paths is considered disjoint if they do not
common link. share a common link.
Discussions:
Protection Performance Protection Performance
Paths that protect a segment of a path may merge beyond the segment Discussions:
being protected and are considered disjoint if they do not use a Paths that protect a segment of a path may merge beyond the
link from the set of links in the protected segment. A path is node segment being protected and are considered disjoint if they
disjoint if it does not share a common node other than the ingress do not use a link from the set of links in the protected
and egress. segment. A path is node disjoint if it does not share a
common node other than the ingress and egress.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Primary Path Primary Path
SRLG SRLG
3.1.10. Shared Risk Link Group (SRLG) 3.1.10. Shared Risk Link Group (SRLG)
Definition: Definition:
SRLG is a set of links which are likely to fail concurrently due to SRLG is a set of links which are likely to fail
sharing a physical resource. concurrently due to sharing a physical resource.
Discussion: Discussion:
SRLG are considered the set of links to be avoided when the SRLG are considered the set of links to be avoided when
primary and secondary paths are considered disjoint. the primary and secondary paths are considered disjoint.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Primary Path Primary Path
Disjoint Path Disjoint Path
3.2. Protection 3.2. Protection
3.2.1. Protection Switching System 3.2.1. Protection Switching System
Definition: Definition:
A SUT that is capable of Failover from a Primary to a Backup A SUT that is capable of Failover from a Primary to a
Path. Backup Path.
Protection Performance Protection Performance
Discussion: Discussion:
The Protection Switching System MUST have a Primary Path and a The Protection Switching System MUST have a Primary Path
Backup Path. The Backup Path MAY be a Standby Backup Path or and a Backup Path. The Backup Path MAY be a Standby
a dynamic Backup Path. The Protection Switching System includes Backup Path or a dynamic Backup Path. The Protection
the mechanisms for both Failure Detection and Failover. Switching System includes the mechanisms for both Failure
Detection and Failover.
Measurement units: Measurement units:
Issues: Issues:
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 that provides protection for link failure.
Discussion: Discussion:
Link Protection may or may not protect the entire Primary Path. Link Protection may or may not protect the entire Primary
Path.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
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 single A Backup Path that provides protection for failure of a
node and its directly connected links. single node and its directly connected links.
Discussion: Discussion:
Node Protection may or may not protect the entire Primary Path. Node Protection may or may not protect the entire Primary
Node Protection also provides Link Protection. Path. Node Protection also provides Link Protection.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup 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 Primary A Backup Path that provides protection for the entire
Path. Primary Path.
Discussion: Discussion:
Path Protection provides Node Protection and Link Protection for Path Protection provides Node Protection and Link Protection
every node and link along the Primary Path. A Backup Path for every node and link along the Primary Path. A Backup
providing Path Protection MUST have the same ingress node as the Path providing Path Protection MUST have the same ingress
Primary Path. node as the Primary Path.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
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 by a The number of nodes in the Primary Path that are protected
Backup Path. by a Backup Path.
Discussion: Discussion:
Measurement units: Measurement units:
number of nodes number of nodes
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
skipping to change at page 14, line 18 skipping to change at page 13, line 18
3.3.1. Failure Detection 3.3.1. Failure Detection
Definition: Definition:
To identify a Primary Path failure at a sub-IP layer. To identify a Primary Path failure at a sub-IP layer.
Discussion: Discussion:
Failure Detection occurs at the ingress node of the Primary Failure Detection occurs at the ingress node of the Primary
Path. Failure Detection occurs via a sub-IP mechanism such Path. Failure Detection occurs via a sub-IP mechanism such
as detection of a link down event or timeout for receipt as detection of a link down event or timeout for receipt
of a control packet. A failure may be completely isolated. A 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. failure may affect a set of links which share a single SRLG
port with many sub-interfaces). A failure may affect multiple (e.g. port with many sub-interfaces). A failure may affect
links that are not part of SRLG. multiple links that are not part of SRLG.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
3.3.2. Failover Event 3.3.2. 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 at Failover Events to sub-IP layers. Failover may be at the PLR or
the ingress. If the failover is at the ingress it is generally on a at the ingress. If the failover is at the ingress it is
disjoint path from the ingress to egress. generally on a disjoint path from the ingress to egress.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Failure Detection Failure Detection
Disjoint Path Disjoint 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 Path To switch data traffic from the Primary Path to the Backup
upon a Failover Event. Path upon a Failover Event.
Discussion: Discussion:
Failover to a Backup Path provides Link Protection, Node Protection, Failover to a Backup Path provides Link Protection, Node
or Path Protection. Failover is complete when Lost Packets, Protection, or Path Protection. Failover is complete when
Out-of-Order Packets, and Duplicate Packets are no longer observed. Lost Packets, Out-of-Order Packets, and Duplicate Packets
are no longer observed.
Measurement units: Measurement units:
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 Failure Recovery MUST occur when 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 the Working Path during Failure Recovery. This implies that
service is either restored fully or partially. Usually, FRR the service is either restored fully or partially. Usually,
restoration can cause congestion, but primary paths rerouting FRR restoration can cause congestion, but primary paths
avoid restoration. An unavoidable problem in any restoration is rerouting avoid restoration. An unavoidable problem in any
the discontinuity in end to end delay when the primary and restoration is the discontinuity in end to end delay when
backup path delays differ significantly. If the backup path has the primary and backup path delays differ significantly. If
a shorter delay out of order delivery may occur if restoration the backup path has a shorter delay out of order delivery
is fast. If the backup path is longer then a sudden may occur if restoration is fast. If the backup path is
increase in delay will occur which can affect real time longer then a sudden increase in delay will occur which can
applications which use playback buffers to remove limited affect real time applications which use playback buffers to
jitter. remove limited jitter.
Measurement units: Measurement units:
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Failover Event Failover Event
Failure Recovery Failure Recovery
Working Path Working Path
skipping to change at page 18, line 20 skipping to change at page 17, line 20
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. The head-end LSR of a backup tunnel or a detour LSP.
Discussion: Discussion:
Based on the functionality of the PLR, its role is defined based Based on the functionality of the PLR, its role is defined
on the type of method used. If it is one-to-one backup method, based on the type of method used. If it is one-to-one
the PLR is responsible for computing a separate backup LSP, backup method, the PLR is responsible for computing a
called a detour LSP for each LSP that PLR is protecting. And in separate backup LSP, called a detour LSP for each LSP that
case if facility backup method is used, the PLR creates a single PLR is protecting. In the case the facility backup method
bypass tunnel that can be used to protect multiple LSPs. is used, the PLR creates a single bypass tunnel that can
be used to protect multiple LSPs.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
3.4.6. Head-end Failover Node 3.4.6. Head-end Failover Node
Definition: Definition:
A node that is ingress to the Primary Path that is capable of A node that is ingress to the Primary Path that is capable
Failover. of Failover.
Discussion: Discussion:
Based on the functionality of the Head-end, its role is defined to Based on the functionality of the Head-end, its role is
be as the ingress of the signaled LSP. It could also occur, that defined to be as the ingress of the signaled LSP. It could
this node happens to be a PLR. In this scenario the term head-end also occur, that this node happens to be a PLR. In this
failover node is defined. scenario the term head-end failover node is defined.
Measurement units: n/a Measurement units: n/a
Protection Performance Protection Performance
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
3.5. Metrics 3.5. Metrics
3.5.1. Failover Packet Loss 3.5.1. Failover Packet Loss
Definition: Definition:
The amount of packet loss produced by a Failover Event The amount of packet loss produced by a Failover Event
until Failover completes. until Failover completes.
Discussion: Discussion:
Packet loss can be observed as a reduction of forwarded traffic Packet loss can be observed as a reduction of forwarded
from the maximum forwarding rate. Failover Packet Loss includes traffic from the maximum forwarding rate. Failover Packet
packets that were lost and packets that were delayed due to Loss includes packets that were lost and packets that were
buffering. Failover Packet Loss MAY reach 100% of the offered delayed due to buffering. Failover Packet Loss MAY reach
load. 100% of the offered load.
Measurement units: Number of Packets Measurement units:
Number of Packets
Issues: Issues:
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 traffic Packet loss can be observed as a reduction of forwarded
from the maximum forwarding rate. Reversion Packet Loss includes traffic from the maximum forwarding rate. Reversion Packet
packets that were lost and packets that were delayed due to Loss includes packets that were lost and packets that were
buffering. Reversion Packet Loss MAY reach 100% of the offered delayed due to buffering. Reversion Packet Loss MAY reach
load. 100% of the offered load.
Measurement units: Number of Packets Measurement units: Number of Packets
Issues: Issues:
See Also: See Also:
Reversion Reversion
Protection Performance Protection Performance
3.5.3. Primary Path Latency 3.5.3. Primary Path Latency
skipping to change at page 20, line 41 skipping to change at page 19, line 41
Issues: Issues:
See Also: See Also:
Backup Path Backup Path
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 that The amount of time it takes for Failover to complete so
the Backup Path is the Working Path. that the Backup Path is the Working Path.
Protection Performance Protection Performance
Discussion: Discussion:
Failover Time can be calculated from Failover Packet Loss Failover Time can be calculated from Failover Packet Loss
that occurs due to a Failover Event and Failover as shown that occurs due to a Failover Event and Failover as shown
below in Equation 1: below in Equation 1:
(eq 1) Failover Time = (Equation 1) Failover Time =
Failover Packets Loss / Offered Load Failover Packets Loss / Offered Load
NOTE: Units for this measurement are NOTE: Units for this measurement are
packets / packets/second = seconds packets / packets/second = seconds
Failover Time includes failure detection time and time for Failover Time includes failure detection time and time
data traffic to begin traversing the Backup Path. for data traffic to begin traversing the Backup Path.
Measurement units: Measurement units:
Seconds Seconds
Issues: Issues:
See Also: See Also:
Failover Failover
Failover Packet loss Failover Packet loss
Working Path Working Path
skipping to change at page 21, line 41 skipping to change at page 20, line 41
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 2 as
shown below: shown below:
(eq 2) Additive Backup Latency = (Equation 2) Additive Backup Latency =
Backup Path Latency - Primary Path Latency. Backup Path Latency - Primary Path Latency.
Measurement units: Measurement units:
Seconds Seconds
Protection Performance Protection Performance
Issues: Issues:
Additive Backup Latency MAY be a negative result. This is Additive Backup Latency MAY be a negative result.
theoretically possible, but could be indicative of a This is theoretically possible, but could be indicative
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 from Reversion Packet
Loss that occurs due to a Failure Recovery as shown Loss that occurs due to a Failure Recovery as shown
below in Equation 3: below in Equation 3:
(eq 3) Reversion Time = (Equation 3) Reversion Time =
Reversion Packets Loss / Offered Load Reversion Packets Loss / Offered Load
NOTE: Units for this measurement are NOTE: Units for this measurement are
packets / packets/second = seconds packets / packets/second = seconds
Reversion Time starts upon completion of Failure Recovery Reversion Time starts upon completion of Failure Recovery
and includes the time for data traffic to begin traversing and includes the time for data traffic to begin traversing
the Primary Path. the Primary Path.
Measurement units: Measurement units:
Seconds Seconds
skipping to change at page 23, line 8 skipping to change at page 22, line 8
See Also: See Also:
Reversion Reversion
Primary Path Primary Path
Working Path Working Path
Reversion Packet Loss Reversion Packet Loss
Failure Recovery Failure Recovery
Protection Performance Protection Performance
4. Acknowledgements 4. Acknowledgements
We would like thank Curtis Villamizar for providing input to the We would like thank Curtis Villamizar for providing input to the
existing definitions, and proposing text for the new definitions on existing definitions, and proposing text for the new definitions
the BMWG mailing list. on the BMWG mailing list.
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 in benchmarking of protection systems, and the information contained
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
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[2] Bradner, S., Editor, "Benchmarking Terminology for [2] Bradner, S., Editor, "Benchmarking Terminology for
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] Perser, J., et al., "Terminology for Benchmarking Network-layer [4] Poretsky, S., et al., "Terminology for Benchmarking
Traffic Control Mechanisms", Internet Draft, Work in Progress, Network-layer Traffic Control Mechanisms", RFC 4689,
draft-ietf-bmwg-dsmterm-13.txt, July 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, March 1997.
[6] Paxson, V., et al., "Framework for IP Performance Metrics", [6] Paxson, V., et al., "Framework for IP Performance Metrics",
RFC 2026, 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-09, work Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-12,
in progress, January 2006. work in progress, February 2007.
[8] P. Pan., et al., "Fast Reroute Extensions to RSVP-TE for LSP [8] P. Pan., et al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", RFC 4090, May 2005. Tunnels", RFC 4090, May 2005.
Protection Performance Protection Performance
[9] Nichols, K., et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
7.2. Informative References 7.2. Informative References
None. None.
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
skipping to change at page 25, line 8 skipping to change at page 24, line 8
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 Protection Performance
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). 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 on an This document and the information contained herein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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
 End of changes. 61 change blocks. 
229 lines changed or deleted 211 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/