draft-ietf-bmwg-protection-term-02.txt   draft-ietf-bmwg-protection-term-03.txt 
Network Working Group Network Working Group
Internet Draft Internet Draft
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 S.Vapiwala
Cisco Systems Cisco Systems
November 2007
Benchmarking Terminology for Protection Performance Benchmarking Terminology for Protection Performance
<draft-ietf-bmwg-protection-term-02.txt > <draft-ietf-bmwg-protection-term-03.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
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use time. It is inappropriate to use Internet-Drafts as reference
Internet-Drafts as reference material or to cite them other 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 IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Protection Performance
Abstract Abstract
This document provides common terminology and metrics for benchmarking This document provides common terminology and metrics for benchmarking
the performance of sub-IP layer protection mechanisms. The performance the performance of sub-IP layer protection mechanisms. The performance
benchmarks are measured at the IP-Layer, so avoid dependence on benchmarks are measured at the IP-Layer, so avoid dependence on
specific sub-IP protection mechanisms. The benchmarks and terminology specific sub-IP protection mechanisms. The benchmarks and terminology
can be applied in methodology documents for different sub-IP layer can be applied in methodology documents for different sub-IP layer
protection mechanisms such as Automatic Protection Switching (APS), protection mechanisms such as Automatic Protection Switching (APS),
Virtual Router Redundancy Protocol (VRRP), Stateful High Availability Virtual Router Redundancy Protocol (VRRP), Stateful High Availability
(HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR).
Protection Performance
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.......................................5
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. Working Path....................................6
3.1.3. Working Path....................................6 3.1.3. Primary Path....................................6
3.1.4. Primary Path....................................7 3.1.4. Protected Primary Path..........................6
3.1.5. Protected Primary Path..........................7 3.1.5. Backup Path.....................................7
3.1.6. Backup Path.....................................8 3.1.6. Standby Backup Path.............................8
3.1.7. Standby Backup Path.............................8 3.1.7. Dynamic Backup Path.............................8
3.1.8. Dynamic Backup Path.............................9 3.1.8. Disjoint Paths..................................8
3.1.9. Disjoint Paths..................................9 3.1.9. Shared Risk Link Group (SRLG)...................9
3.1.10. Shared Risk Link Group (SRLG)..................10 3.2. Protection...........................................9
3.2. Protection...........................................10 3.2.1. Protection Switching System.....................9
3.2.1. Protection Switching System.....................10 3.2.2. Link Protection.................................10
3.2.2. Link Protection.................................11 3.2.3. Node Protection.................................10
3.2.3. Node Protection.................................11 3.2.4. Path Protection.................................10
3.2.4. Path Protection.................................12 3.2.5. Backup Span.....................................11
3.2.5. Backup Span.....................................12 3.2.6 Protected Interface.............................11
3.2.6 Protected Interface.............................12 3.3. Protection Switching.................................12
3.3. Failure..............................................13 3.3.1. Failover Event..................................12
3.3.1. Failover Event..................................13 3.3.2. Failure Detection...............................12
3.3.2. Failure Detection...............................13 3.3.3. Failover........................................13
3.3.3. Failover........................................14 3.3.4. Restoration.....................................13
3.3.4. Restoration (Failover recovery).................14 3.3.5. Reversion.......................................14
3.3.5. Reversion.......................................15 3.4. Nodes................................................14
3.4. Nodes................................................15 3.4.1. Protection-Switching Node.......................14
3.4.1. Protection-Switching Node.......................15 3.4.2. Non-Protection Switching Node...................14
3.4.2. Non-Protection Switching Node...................15 3.4.3. Failover Node...................................15
3.4.3. Failover Node...................................16 3.4.4. Merge Node......................................15
3.4.4. Merge Node......................................16 3.4.5. Point of Local repair (PLR).....................16
3.4.6. Head-end Failover Node..........................16
3.5. Benchmarks...........................................17
3.5.1. Failover Packet Loss............................17
3.5.2. Reversion Packet Loss...........................17
3.5.3. Failover Time...................................18
3.5.4. Reversion Time..................................18
3.5.5. Additive Backup Latency.........................19
3.6 Failover Time Calculation Methods.....................19
3.6.1 Time-Based Loss Method...........................19
3.6.2 Packet-Loss Based Method.........................20
3.6.3 Timestamp-Based Method...........................21
4. Acknowledgments...........................................22
5. IANA Considerations.......................................22
6. Security Considerations...................................22
7. References................................................22
8. Author's Address..........................................23
Protection Performance Protection Performance
3.4.5. Point of Local repair (PLR).....................17
3.4.6. Head-end Failover Node..........................17
3.5. Metrics..............................................18
3.5.1. Failover Packet Loss............................18
3.5.2. Reversion Packet Loss...........................18
3.5.3. Primary Path Latency............................19
3.5.4. Backup Path Latency.............................19
3.6. Benchmarks...........................................20
3.6.1. Failover Time...................................20
3.6.2. Additive Backup Latency.........................21
3.6.3. Reversion Time..................................21
3.7 Failover Calculation Method...........................22
3.7.1 Time-Based Loss Method...........................22
3.7.2 Packet-Based Loss Method.........................22
3.7.3 Timestamp-Based Method...........................23
4. Acknowledgments...........................................24
5. IANA Considerations.......................................24
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
includes 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-FRR) [8].
Benchmarking terminology have been defined for IP-layer route Benchmarking terminology have been defined for IP-layer route
convergence [7]. New terminology and methodologies specific convergence [7]. New terminology and methodologies specific
to benchmarking sub-IP layer protection mechanisms are required. to benchmarking sub-IP layer protection mechanisms are required.
This will enable different implementations of the same This will enable different implementations of the same
protection mechanisms to be benchmarked and evaluated. In protection mechanisms to be benchmarked and evaluated. 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
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. The
sequence of events is as follows:
Figure 1 shows the fundamental model that is to be used in 1. Failover Event - Primary Path fails
benchmarking sub-IP protection mechanisms. The sequence of 2. Failure Detection- Failover Event is detected
events is Failover Event, Failure Detection, Failover, Restoration 3. Failover - Backup Path becomes the Working Path due to Failover
(Failover recovery), and optionally Reversion. Protection Event
Switching consists of a minimum of two Protection-Switching Nodes 4. Restoration - Primary Path recovers from a Failover Event
with a Primary Path and a Backup Path. A Failover Event occurs 5. Reversion (optional) - Primary Path becomes the Working Path
along the Primary Path. A tester is set outside the two nodes as
it sends and receives IP traffic along the Working Path. The These terms are further defined in this document. Figure 1 shows
Working Path is the Primary Path prior to the Failover Event and the fundamental model that is to be used in benchmarking sub-IP
the Backup Path following the Failover Event. If Reversion is protection mechanisms. A Protection Switching consists of a minimum
supported then the Working Path is the Primary Path after Failure of two Protection-Switching Nodes with a Primary Path and a Backup
Recovery. The tester MUST record the IP packet sequence numbers, Path. A Failover Event occurs along the Primary Path. A Tester is
departure time, and arrival time so that the metrics of Failover set outside the two nodes as it sends and receives IP traffic along
Time, Additive Latency, and Reversion Time can be measured. The the Working Path. The Working Path is the Primary Path prior to
Tester may be a single device or a test system. the Failover Event and the Backup Path after the Failover Event.
If Reversion is supported then the Working Path is the Primary Path
after Restoration (Failure Recovery) of the Primary Path. The tester
MUST record the IP packet sequence numbers, departure time, and
arrival time so that the metrics of Failover Time, Additive Latency,
Packet Reordering, Duplicate Packets, and Reversion Time can be
measured. The Tester may be a single device or a test system.
Protection Performance
+-----------+ +-----------+
+--------------------| 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
Protection Performance
2. Existing definitions 2. Existing definitions
This document uses 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]
Forwarding Delay [Ref.[4], section 3.2.4]
Jitter [Ref.[4], section 3.2.5]
Packet Loss [Ref.[7], Section 3.5] Packet Loss [Ref.[7], Section 3.5]
Packet Reordering [Ref.[10] section 3.3] Packet Reordering [Ref.[10], section 3.3]
This document has the following frequently used acronyms:
DUT Device Under Test
SUT System Under Test
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.
Protection Performance
3. Test Considerations 3. Test Considerations
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 unidirectional sequence of nodes, <R1, ..., Rn>, and links
properties: <L12,... L(n-1)n> 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.
Protection Performance a. R1 is the ingress node and forwards IP packets, which input
into DUT/SUT, to R2 as sub-IP frames over link L12.
b. Ri is a node which forwards data frames to R[i+1] over Link
Li[i+1] for all i, 1<i<n, based on information in the sub-IP
layer.
c. Rn is the egress node and it outputs sub-IP frames from
DUT/SUT as IP packets.
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 [1]. For example, the SONET/SDH path, an IP path in RFC 2026 [1]. One path may be regarded as being
the label switched path for MPLS, and optical path. One path equivalent to one IP link between two IP nodes, i.e., R1 and Rn.
may be regarded as being equivalent to one IP link between two The two IP nodes may have multiple paths for protection. A
IP nodes, i.e., R1 and Rn. The two IP nodes may have multiple packet will travel on only one path between the nodes. Packets
paths for protection. A packet will travel on only one path belonging to a microflow [9] will traverse one or more paths.
between the nodes. Packets belonging to a microflow [9] The path is unidirectional. Example paths are the SONET/SDH
will transverse one or more paths. The path is unidirectional. path and the label switched path for MPLS.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
"A bidirectional path", which transmits traffic in both "A bidirectional path", which transmits traffic in both
directions along the same nodes, consists of two unidirectional directions along the same nodes, consists of two unidirectional
paths. Therefore, the two unidirectional paths belonging to paths. Therefore, the two unidirectional paths belonging to
"one bidirectional path" will be treated independently when "one bidirectional path" will be treated independently when
benchmarking for "a bidirectional path". benchmarking for "a bidirectional path".
See Also: See Also:
3.1.2. Tunnel Protection Performance
Definition:
Tunnel is a collection of related Paths.
Discussion:
A Tunnel is used to carry a specific flow of traffic which
is generally large aggregation of microflows, but may be any
flow defined by a classifier at the ingress. A Tunnel may
include two primary paths during the MPLS make-before-break
reroute.
Measurement units: n/a
Issues: None
See Also:
Path
Primary Path
Backup Path
3.1.3. Working Path 3.1.2. Working Path
Definition: Definition:
The path that the DUT/SUT is currently using to forward The path that the DUT/SUT is currently using to forward
packets. packets.
Discussion: Discussion:
A Primary Path is a Working Path before occurrence of a A Primary Path is the Working Path before occurrence of a
Failover Event. A Backup Path becomes the Working Path after Failover Event. A Backup Path becomes the Working Path after
a Failover Event. a Failover Event.
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.3. Primary Path
Definition: Definition:
The preferred path for forwarding traffic between two or The preferred path for forwarding traffic between two or
more nodes. more nodes.
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
None
See Also: See Also:
Path Path
3.1.5. Protected Primary Path 3.1.4. Protected Primary Path
Definition: Definition:
The Primary Path that is protected with a Backup Path. A Primary Path that is protected with a Backup Path.
Discussion: Discussion:
A Protected Primary Path MUST include at least one Protection
Switching Node.
Protection Performance
Measurement units: Measurement units:
n/a n/a
Issues: Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
Protection Performance
3.1.6. Backup Path 3.1.5. Backup Path
Definition: Definition:
A path that exists to carry data traffic only if a Failover A path that exists to carry data traffic only if a Failover
Event occurs. Event occurs on a Primary Path.
Discussion: Discussion:
The Backup Path is the Working Path upon a Failover Event. The Backup Path SHALL be the Working Path upon a Failover Event.
There are various types of Backup Paths: a dedicated recovery A Path MAY have one or more Backup Paths. A Backup Path MAY
path (1+1), which has 100% redundancy for a specific ordinary protect one or more Primary Paths. There are various types of
path, a shared Backup Path (1:N), which is dedicated to the Backup Paths:
protection for more than one specific Primary Path, and an
associated shared Backup Path (M:N) for which a specific set a. dedicated recovery Backup Path (1+1), which has 100%
of Backup Paths protects a specific set of more than one redundancy for a specific ordinary path,
Primary Path. Backup path is always computed before the
failover event. A new path computed after the failover event b. shared Backup Path (1:N), which is dedicated to the
is simply reroute of the primary path. A backup may be protection for more than one specific Primary Path
signaled or unsignaled.
c. associated shared Backup Path (M:N) for which a specific
set of Backup Paths protects a specific set of more than one
Primary Path.
A Backup Path may be signaled or unsignaled. The Backup Path
MUST be created prior to the Failover Event. A new Path
computed after the Failover Event is simply Convergence [7]
to a new Primary Path.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
Protection Performance
3.1.7. Standby Backup Path 3.1.6. Standby Backup Path
Definition: Definition:
A Backup Path that is established prior to a Failover Event A Backup Path that is established prior to a Failover Event
to protect a Primary Path. to protect a Primary Path.
Protection Performance
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
Failover Event Failover Event
3.1.8. Dynamic Backup Path 3.1.7. Dynamic Backup Path
Definition: Definition:
A Backup Path that is established upon occurrence of a A Backup Path that is established upon occurrence of a
Failover Event. Failover Event.
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
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.8. Disjoint Paths
Definition: Definition:
A pair of paths is considered disjoint if they do not A pair of paths is considered disjoint if they do not
share a common link. share a common link.
Protection Performance
Discussions: Discussions:
Paths that protect a segment of a path may merge beyond the Paths that protect a segment of a path may merge beyond the
segment being protected and are considered disjoint if they segment being protected and are considered disjoint if they
do not use a link from the set of links in the protected do not use a link from the set of links in the protected
segment. A path is node disjoint if it does not share a segment. A path is node disjoint if it does not share a
common node other than the ingress and egress. common node other than the ingress and egress.
Protection Performance
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.9. Shared Risk Link Group (SRLG)
Definition: Definition:
SRLG is a set of links which are likely to fail SRLG is a set of links which share a physical resource.
concurrently due to sharing a physical resource.
Discussion: Discussion:
SRLG are considered the set of links to be avoided when SRLG is considered the set of links to be avoided when
the primary and secondary paths are considered disjoint. the primary and secondary paths are considered disjoint.
The SRLG will fail as a group if the shared resource fails.
Measurement units: Measurement units:
n/a n/a
Issues: Issues: None
See Also: See Also:
Path Path
Primary Path Primary 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 A DUT/SUT that is capable of Failure Detection and Failover
Backup Path. from a Primary Path to a Backup Path when a Failover Event
occurs.
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: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failure Detection
Failover Failover
Protection Performance
3.2.2. Link Protection 3.2.2. Link Protection
Definition: Definition:
A backup path is signal to next node avoiding protected A Backup Path that is signaled to protect for failure
interface that provide protection for link failure of interfaces and links along a Primary Path.
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: None 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 is signal to next to next node avoiding A Backup Path that is signaled to protect for failure
protected node that provide protection failure of link or of interfaces, links and nodes along a Primary Path.
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: None Issues: None
See Also: See Also:
Link Protection Link Protection
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: n/a Measurement units: n/a
Issues: None Issues: None
Protection Performance
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 numbers of hop used by backup tunnel to protected link or The numbers of hop used by a Backup Path.
node.
Discussion: Discussion:
Measurement units: number of nodes Measurement units: number of nodes
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
3.2.6 Protected Interface 3.2.6 Protected Interface
Definition: Definition:
A interface which primary path is signaled over and protected by An interface along the Primary Path that is protected by
backup tunnel a Backup Path
Discussion: Discussion:
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
Primary Path
Backup Path
Protection Performance Protection Performance
3.3. Failure
3.3. Protection Switching
3.3.1. Failover Event 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
skipping to change at page 13, line 35 skipping to change at page 12, line 35
Issues: Issues:
See Also: See Also:
Path Path
Failure Detection Failure Detection
Disjoint Path Disjoint Path
3.3.2. Failure Detection 3.3.2. Failure Detection
Definition: Definition:
To identify a Primary Path failure at a sub-IP layer. The process to identify at a sub-IP layer a Failover Event
along the Primary Path.
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 failure may affect a set of links which share a single SRLG
(e.g. port with many sub-interfaces). A failure may affect (e.g. port with many sub-interfaces). A failure may affect
multiple 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
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 The process to switch data traffic from the Protected Primary
Path upon a Failover Event. Path to the Backup Path upon Failure Detection of 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 Packet Loss [7], Out-of-order Packets [4], and Duplicate
are no longer observed. Packets [4] are no longer observed. Forwarding Delay [4]
may continue to be 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
restored following a Failover Event. recovers from a Failover Event, but is not yet forwarding
packets because the Backup Path remains the Working Path.
Discussion: Discussion:
Restoration MUST occur while 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 Restoration. Restoration produces
the service is either restored fully or partially. a Primary Path that is recovered from failure, but is
Restoration can cause congestion, but primary paths not yet forwarding traffic. Traffic is still being
rerouting avoid restoration. An unavoidable problem in any forwarded by the Backup Path functioning as the Working
restoration is the discontinuity in end to end delay when Path.
the primary and backup path delays differ significantly. If
the backup path has a shorter delay out of order delivery
may occur if restoration is fast. If the backup path is
longer then a sudden increase in delay will occur which can
affect real time applications which use playback buffers to
remove limited jitter.
Measurement units: Measurement units:
n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Failover Event Failover Event
Failure Recovery Failure Recovery
Working Path Working Path
Backup Path Backup Path
Protection Performance Protection Performance
3.3.5. Reversion 3.3.5. Reversion
Definition: Definition:
The act of restoring the Primary Path as the Working Path. The act of failover recovery in which the Primary Path becomes
the Working Path so that it is forwarding packets.
Discussion: Discussion:
Protection Switching Systems may or may not support Reversion. Protection Switching Systems may or may not support Reversion.
Reversion, if supported, MUST occur after Failure Recovery. Reversion, if supported, MUST occur after Restoration.
Packet forwarding on the Primary Path resulting from Reversion
may occur either fully or partially over the Primary Path. A
potential problem with Reversion is the discontinuity in end to
end delay when the Forwarding Delays [4] along the Primary Path
and Backup Path are different, possibly causing Out of Order
Packets [4], Duplicate Packets [4], and increased Jitter [4].
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Protection Switching System Protection Switching System
Working Path Working Path
Primary Path Primary Path
3.4. Nodes 3.4. Nodes
3.4.1. Protection-Switching Node 3.4.1. Protection-Switching Node
skipping to change at page 15, line 44 skipping to change at page 14, line 50
The Protection Switching Node MAY be an ingress or egress for The Protection Switching Node MAY be an ingress or egress for
a Primary Path or Backup Path. a Primary Path or Backup Path.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Protection Switching System Protection Switching System
Primary Path
Backup Path
3.4.2. Non-Protection Switching Node 3.4.2. Non-Protection Switching Node
Definition: Definition:
A node that not capable of participating in a Protection A node that is not capable of participating in a Protection
Switching System, however it MAY exist along the Primary Switching System, however it MAY exist along the Primary
Path or Backup Path. Path or Backup Path.
Protection Performance Protection Performance
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
skipping to change at page 16, line 44 skipping to change at page 15, 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 where backup path terminates A Node along the primary path where backup path terminates.
.
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 14 skipping to change at page 16, line 14
Protection Performance Protection Performance
Issues: Issues:
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:
A node that uses a Backup Path to protect another A node along the Primary Path that uses a Backup Path to
node or link. 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 the one-to-one backup based on the type of method used. If the one-to-one backup
method is used, the PLR is responsible for computing a method is used, the PLR is responsible for computing a
separate Backup Path for each Primary Path. In the case separate Backup Path for each Primary Path. In the case
the facility backup method is used, the PLR creates a the facility backup method is used, the PLR creates a
single Backup Path that can be used to protect multiple single Backup Path that can be used to protect multiple
Primary Paths. Primary Paths.
skipping to change at page 17, line 41 skipping to change at page 16, line 41
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 A node along the Primary Path that is capable of Failover.
of Failover.
Discussion: Discussion:
Based on the functionality of the Head-end, its role is The Head-end Failover Node is the ingress node to the Backup
defined to be as the ingress of the signaled LSP. It could Path. The Head-end Failover Node is always a PLR
also occur, that this node happens to be a PLR. In this
scenario the term head-end failover node is defined.
Measurement units: n/a Measurement units: n/a
Protection Performance
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Point of Local Repair
Failover Failover
Protection Performance
3.5. Metrics 3.5. Benchmarks
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
until Failover completes. Failover completes, where the measurement begins when the last
unimpaired packet is received by the Tester on the Protected
Primary Path and ends when the first unimpaired packet is
received by the Tester on the Backup Path.
Discussion: 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, reordered, or delayed.
delayed due to buffering. Failover Packet Loss MAY reach 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: None 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, where the
measurement begins when the last unimpaired packet is received
by the Tester on the Backup Path and ends when the first
unimpaired packet is received by the Tester on the Protected
Primary Path .
Discussion: 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, reordered, or delayed.
delayed due to buffering. Reversion Packet Loss MAY reach 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: None Issues: None
See Also: See Also:
Reversion Reversion
Protection Performance Protection Performance
3.5.3. Primary Path Latency 3.5.3. Failover Time
Definition:
Latency [2] measured along the Primary Path.
Discussion:
Measurement units:
seconds
Issues: None
See Also:
Primary Path
3.5.4. Backup Path Latency
Definition: Definition:
Latency [2] measured along the Backup Path. The amount of time it takes for Failover to successfully
complete.
Discussion: Discussion:
Failover Time can be calculated using the Time-Based Loss
Method (TBLM), Packet-Loss Based Method (PLBM), or
Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
Measurement units: Measurement units:
seconds milliseconds
Issues: None Issues: None
See Also: See Also:
Backup Path Failover
Protection Performance Failover Time
Time-Based Loss Method (TBLM)
3.6. Benchmarks Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM)
3.6.1. Failover Time 3.5.4. Reversion Time
Definition: Definition:
The amount of time it takes for Failover to complete so The amount of time it takes for Reversion to complete so
that the Backup Path is the Working Path. that the Primary Path is restored as the Working Path.
Discussion: Discussion:
Failover Time can be calculated using the Time-Based Loss Reversion Time can be calculated using the Time-Based Loss
Method (TBLM), Packet-Based Loss Method (PBLM), or Method (TBLM), Packet-Loss Based Method (PLBM), or
Timestamp-Based Method (TBM). It is RECOMMENDED that the Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used. TBM is used.
Measurement units: Measurement units:
Seconds milliseconds
Issues: None Issues: None
See Also: See Also:
Failover Reversion
Failover Time Primary Path
Working Path Working Path
Backup Path Reversion Packet Loss
Time-Based Loss Method (TBLM) Time-Based Loss Method (TBLM)
Packet-Based Loss Method (PBLM) Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM) Timestamp-Based Method (TBM)
Protection Performance Protection Performance
3.6.2. Additive Backup Latency 3.5.5. Additive Backup Delay
Definition: Definition:
The amount of increased latency resulting from data traffic The amount of increased Forwarding Delay [4] resulting
traversing the Backup Path instead of the Primary Path. from data traffic traversing the Backup Path instead of
the Primary Path.
Discussion: Discussion:
Additive Backup Latency is calculated using Equation 1 as Additive Backup Delay is calculated using Equation 1 as
shown below: shown below:
(Equation 1) Additive Backup Latency = (Equation 1)
Backup Path Latency - Primary Path Latency. Additive Backup Delay =
Forwarding Delay(Backup Path) -
Forwarding Delay(Primary Path).
Measurement units: Measurement units:
Seconds milliseconds
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 Failover Time Calculation Methods
Definition:
The amount of time it takes for Reversion to complete so
that the Primary Path is restored as the Working Path.
Discussion:
Reversion Time can be calculated using the Time-Based Loss
Method (TBLM), Packet-Based Loss Method (PBLM), or
Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
Measurement units:
Seconds
Issues: None
See Also:
Reversion
Primary Path
Working Path
Reversion Packet Loss
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) 3.6.1 Time-Based Loss Method (TBLM)
Definition: Definition:
The method to calculate Failover Time (or Reversion Time) using a The method to calculate Failover Time (or Reversion Time) using a
time scale to measure duration of packet loss. time scale on the Tester to measure the interval of Failover
Packet Loss.
Discussion: Discussion:
Traffic generators provide statistics which show the duration of The Tester MUST provide statistics which show the duration of
failure on a time scale to granularity of milliseconds based on failure on a time scale to granularity of milliseconds based on
occurrence of packet loss on a time scale. This is indicated by occurrence of packet loss on a time scale. This is indicated by
the duration of non-zero packet loss. The TBLM includes failure the duration of non-zero packet loss. The TBLM includes failure
detection time and time for data traffic to begin traversing the detection time and time for data traffic to begin traversing the
Backup Path. Backup Path. Failover Time and Reversion Time are calculated
using the TBLM as shown in Equation 2:
Protection Performance
(Equation 2)
(Equation 2a)
TBLM Failover Time = Time(Failover) - Time(Failover Event)
(Equation 2b)
TBLM Reversion Time = Time(Reversion) - Time(Restoration)
Measurement units: Measurement units:
Milliseconds milliseconds
Issues: None Issues:
None
See Also: See Also:
Failover Failover
Packet-Based Loss Method Packet-Loss Based Method
3.7.2 Packet-Based Loss Method (PBLM) 3.6.2 Packet-Loss Based Method (PLBM)
Definition: Definition:
The method used to calculate Failover Time (or Reversion Time) The method used to calculate Failover Time (or Reversion Time)
from the amount of Packet Loss. from the amount of Failover Packet Loss.
Discussion: Discussion:
Failover Time can be calculated using PBLM is from Failover PLBM includes failure detection time and time for data traffic to
Packet Loss that occurs due to a Failover Event and Failover begin traversing the Backup Path. Failover Time can be
as shown below in Equation 2: calculated using PLBM from the amount Failover Packet Loss as
shown below in Equation 3:
(Equation 2) Failover (or Reversion) Time = (Equation 3)
Number of packets drop/(rate per (Equation 3a)
second * 1000) milliseconds PLBM Failover Time =
Number of packets lost /
(Offered Load rate * 1000)
Packet based loss method includes failure detection time and (Equation 3b)
time for data traffic to begin traversing the Backup Path. PLBM Restoration Time =
Number of packets lost /
(Offered Load rate * 1000)
Units are packets/(packets/second) = seconds
Measurement units: Measurement units:
milliseconds milliseconds
Issues: Issues:
None
See Also: See Also:
Failover Failover
Time-Based Loss Method Time-Based Loss Method
Protection Performance Protection Performance
3.7.3 Timestamp-Based Method (TBM) 3.6.3 Timestamp-Based Method (TBM)
Definition: Definition:
The method to calculate Failover Time (or Reversion Time) The method to calculate Failover Time (or Reversion Time)
using a time scale to quantify the interval between using a time scale to quantify the interval between
unimpaired packets arriving in the test stream. unimpaired packets arriving in the test stream.
Discussion: Discussion:
The purpose of this method is to quantify the duration of The purpose of this method is to quantify the duration of
failure or reversion on a time scale with granularity of failure or reversion on a time scale with granularity of
milliseconds based on the observation of unimpaired packets, milliseconds based on the observation of unimpaired packets,
using Equation 3. using Equation 2 with the difference being that the time
values are obtained from the timestamp in the packet payload
(Equation 3) rather than from the Tester.
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, Unimpaired packets are normal packets that are not lost,
reordered, or duplicated. A reordered packet is defined in reordered, or duplicated. A reordered packet is defined in
[10, section 3.3]. A duplicate 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 [4, section 3.3.3]. A lost packet is defined in
[7, Section 3.5]. Unimpaired packets may be detected by checking [7, Section 3.5]. Unimpaired packets may be detected by checking
a sequence number in the payload, where the sequence number equals a sequence number in the payload, where the sequence number equals
the next expected number for an unimpaired packet. A sequence gap the next expected number for an unimpaired packet. A sequence gap
or sequence reversal may indicate impaired packets. or sequence reversal indicates impaired packets.
For calculating Failover Time, the TBM includes failure For calculating Failover Time, the TBM includes failure
detection time and time for data traffic to begin traversing the detection time and time for data traffic to begin traversing the
Backup Path. For calculating Reversion Time, the TBM includes Backup Path. For calculating Reversion Time, the TBM includes
Reversion Time and time for data traffic to begin traversing the Reversion Time and time for data traffic to begin traversing the
Primary Path. Primary Path.
Measurement units: Measurement units:
milliseconds milliseconds
skipping to change at page 24, line 45 skipping to change at page 22, line 45
Requirement Levels", RFC 2119, July 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-13, Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-13,
work in progress, July 2007. work in progress, July 2007.
[8] Pan., P. 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. Paths", RFC 4090, May 2005.
[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, [10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
7.2. Informative References 7.2. Informative References
skipping to change at page 25, line 38 skipping to change at page 23, line 38
USA USA
Phone: +1 978 936 0533 Phone: +1 978 936 0533
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
Samir Vapiwala Samir Vapiwala
Cisco System Cisco System
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 1484 Phone: +1 978 936 1484
Email: vapiwala@cisco.com Email: svapiwal@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
 End of changes. 122 change blocks. 
324 lines changed or deleted 301 lines changed or added

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