draft-ietf-bmwg-protection-term-03.txt   draft-ietf-bmwg-protection-term-04.txt 
Network Working Group Network Working Group S. Poretsky
Internet Draft Internet Draft NextPoint Networks
Intended Status: Informational Expires: August 2008
S. Poretsky Intended Status: Informational R. Papneja
Reef Point Systems
R. Papneja
Isocore Isocore
J. Karthik J. Karthik
Cisco Systems
S. Vapiwala S. Vapiwala
Cisco Systems Cisco Systems
November 2007 February 25, 2008
Benchmarking Terminology for Protection Performance Benchmarking Terminology for Protection Performance
<draft-ietf-bmwg-protection-term-03.txt >
<draft-ietf-bmwg-protection-term-04.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 45 skipping to change at page 1, line 45
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other 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 (2008).
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).
skipping to change at page 2, line 6 skipping to change at page 2, line 6
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 Protection Performance
Table of Contents Table of Contents
1. Introduction..............................................3 1. Introduction..............................................3
2. Existing definitions......................................4 2. Existing definitions......................................6
3. Test Considerations.......................................5 3. Test Considerations.......................................7
3.1. Path.................................................5 3.1. Paths................................................7
3.1.1. Path............................................5 3.1.1. Path............................................7
3.1.2. Working Path....................................6 3.1.2. Working Path....................................8
3.1.3. Primary Path....................................6 3.1.3. Primary Path....................................8
3.1.4. Protected Primary Path..........................6 3.1.4. Protected Primary Path..........................8
3.1.5. Backup Path.....................................7 3.1.5. Backup Path.....................................9
3.1.6. Standby Backup Path.............................8 3.1.6. Standby Backup Path.............................10
3.1.7. Dynamic Backup Path.............................8 3.1.7. Dynamic Backup Path.............................10
3.1.8. Disjoint Paths..................................8 3.1.8. Disjoint Paths..................................10
3.1.9. Shared Risk Link Group (SRLG)...................9 3.1.9. Point of Local repair (PLR).....................11
3.2. Protection...........................................9 3.1.10. Shared Risk Link Group (SRLG)..................11
3.2.1. Protection Switching System.....................9 3.2. Protection Mechanisms................................12
3.2.2. Link Protection.................................10 3.2.1. Link Protection.................................12
3.2.3. Node Protection.................................10 3.2.2. Node Protection.................................12
3.2.4. Path Protection.................................10 3.2.3. Path Protection.................................12
3.2.5. Backup Span.....................................11 3.2.4. Backup Span.....................................13
3.2.6 Protected Interface.............................11 3.2.5. Local Link Protection...........................13
3.3. Protection Switching.................................12 3.2.6. Redundant Node Protection.......................14
3.3.1. Failover Event..................................12 3.2.7 State Control Interface.........................14
3.3.2. Failure Detection...............................12 3.2.8. Protected Interface.............................15
3.3.3. Failover........................................13 3.3. Protection Switching.................................15
3.3.4. Restoration.....................................13 3.3.1. Protection Switching System.....................15
3.3.5. Reversion.......................................14 3.3.2. Failover Event..................................15
3.4. Nodes................................................14 3.3.3. Failure Detection...............................16
3.4.1. Protection-Switching Node.......................14 3.3.4. Failover........................................17
3.4.2. Non-Protection Switching Node...................14 3.3.5. Restoration.....................................17
3.4.3. Failover Node...................................15 3.3.6. Reversion.......................................18
3.4.4. Merge Node......................................15 3.4. Nodes................................................18
3.4.5. Point of Local repair (PLR).....................16 3.4.1. Protection-Switching Node.......................18
3.4.6. Head-end Failover Node..........................16 3.4.2. Non-Protection Switching Node...................19
3.5. Benchmarks...........................................17 3.4.3. Headend Node....................................19
3.5.1. Failover Packet Loss............................17 3.4.4. Backup Node.....................................19
3.5.2. Reversion Packet Loss...........................17 3.4.5. Merge Node......................................20
3.5.3. Failover Time...................................18 3.4.6. Primary Node....................................20
3.5.4. Reversion Time..................................18 3.4.7. Standby Node....................................21
3.5.5. Additive Backup Latency.........................19 3.5. Benchmarks...........................................21
3.6 Failover Time Calculation Methods.....................19 3.5.1. Failover Packet Loss............................21
3.6.1 Time-Based Loss Method...........................19 3.5.2. Reversion Packet Loss...........................22
3.6.2 Packet-Loss Based Method.........................20 3.5.3. Failover Time...................................22
3.6.3 Timestamp-Based Method...........................21 3.5.4. Reversion Time..................................23
4. Acknowledgments...........................................22 3.5.5. Additive Backup Latency.........................23
5. IANA Considerations.......................................22 3.6 Failover Time Calculation Methods.....................24
6. Security Considerations...................................22 3.6.1 Time-Based Loss Method...........................24
7. References................................................22 3.6.2 Packet-Loss Based Method.........................25
8. Author's Address..........................................23 3.6.3 Timestamp-Based Method...........................25
4. Acknowledgments...........................................26
5. IANA Considerations.......................................26
6. Security Considerations...................................26
7. References................................................26
8. Author's Address..........................................27
Protection Performance Protection Performance
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 Sub-IP
includes High Availability (HA) stateful failover. Virtual Router Protection technologies include High Availability (HA) stateful
Redundancy Protocol (VRRP), Automatic Link Protection (APS) for failover, Virtual Router Redundancy Protocol (VRRP), Automatic Link
SONET/SDH, Resilient Packet Ring (RPR) for Ethernet, and Fast Protection (APS) for SONET/SDH, Resilient Packet Ring (RPR) for
Reroute for Multi-Protocol Label Switching (MPLS-FRR) [8]. Ethernet, and Fast 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
skipping to change at page 3, line 42 skipping to change at page 3, line 43
methodology documents for each sub-IP protection mechanism. The methodology documents for each sub-IP protection mechanism. The
sequence of events is as follows: sequence of events is as follows:
1. Failover Event - Primary Path fails 1. Failover Event - Primary Path fails
2. Failure Detection- Failover Event is detected 2. Failure Detection- Failover Event is detected
3. Failover - Backup Path becomes the Working Path due to Failover 3. Failover - Backup Path becomes the Working Path due to Failover
Event Event
4. Restoration - Primary Path recovers from a Failover Event 4. Restoration - Primary Path recovers from a Failover Event
5. Reversion (optional) - Primary Path becomes the Working Path 5. Reversion (optional) - Primary Path becomes the Working Path
These terms are further defined in this document. Figure 1 shows These terms are further defined in this document. Figures 1
the fundamental model that is to be used in benchmarking sub-IP through 5 show fundamental models that MAY be used in
protection mechanisms. A Protection Switching consists of a minimum benchmarking Sub-IP Protection mechanisms. Sub-IP Protection
of two Protection-Switching Nodes with a Primary Path and a Backup mechanisms MUST use a Protection Switching System that consists
Path. A Failover Event occurs along the Primary Path. A Tester is of a minimum of two Protection-Switching Nodes, an Ingress Node
set outside the two nodes as it sends and receives IP traffic along known as the Headend Node and an Egress Node known as the Merge
the Working Path. The Working Path is the Primary Path prior to Node. The protection MAY be provided with either a Primary
the Failover Event and the Backup Path after the Failover Event. Path and Backup Path, as shown in Figures 1 through 4, or a
If Reversion is supported then the Working Path is the Primary Path Primary Node and Standby Node, as shown in Figure 5.
after Restoration (Failure Recovery) of the Primary Path. The tester
MUST record the IP packet sequence numbers, departure time, and A Protection Switching System may provide link protection, node
arrival time so that the metrics of Failover Time, Additive Latency, protection, path protection, local link protection, and high
Packet Reordering, Duplicate Packets, and Reversion Time can be availability, as shown in Figures 1 through 5 respectively.
measured. The Tester may be a single device or a test system. A Failover Event occurs along the Primary Path or at the Primary
Protection Performance
Node. The Working Path is the Primary Path prior to the Failover
Event and the Backup Path after the Failover Event. A Tester is
set outside the two paths or nodes as it sends and receives IP
traffic along the Working Path. The tester MUST record the IP
packet sequence numbers, departure time, and arrival time so that
the metrics of Failover Time, Additive Latency, Packet Reordering,
Duplicate Packets, and Reversion Time can be measured. The Tester
may be a single device or a test system. If Reversion is
supported then the Working Path is the Primary Path after
Restoration (Failure Recovery) of the Primary Path.
Link Protection, as shown in Figure 1, provides protection
when a Failover Event occurs on the link between two nodes along
the Primary Path. Node Protection, as shown in Figure 2,
provides protection when a Failover Event occurs at a Node along
the Primary Path. Path Protection, as shown in Figure 3,
provides protection for link or node failures for multiple hops
along the Primary Path. Local Link Protection, as shown in
Figure 4, provides Sub-IP Protection of a link between two nodes,
without a Backup Node. An example of such a Sub-IP Protection
mechanism is SONET APS. High Availability Protection, as shown
in Figure 5, provides protection of a Primary Node with a
redundant Standby Node. State Control is provided between the
Primary and Standby Nodes. Failure of the Primary Node is
detected at the Sub-IP layer to force traffic to switch to
the Standby Node, which has state maintained for zero or minimal
packet loss.
+-----------+
+--------------| Tester |<-----------------------+
| +-----------+ |
| IP Traffic | Failover IP Traffic |
| | Event |
| | |
| ------------ | ---------- |
+--->| Ingress/ | V | Egress/ |---+
|Headend Node|------------------|Merge Node| Primary
------------ ---------- Path
| ^
| --------- | Backup
+--------| Backup |-------------+ Path
| Node |
---------
Figure 1. System Under Test (SUT) for Sub-IP Link Protection
Protection Performance Protection Performance
+-----------+ +-----------+
+--------------------| Tester |<-----------------+
| +-----------+ |
| IP Traffic | Failover IP Traffic |
| | Event |
| V |
| ------------ -------- ---------- |
+--->| Ingress/ | |MidPoint| | Egress/ |---+
|Headend Node|----| Node |----|Merge Node| Primary
------------ -------- ---------- Path
| ^
| --------- | Backup
+--------| Backup |-------------+ Path
| Node |
---------
Figure 2. System Under Test (SUT) for Sub-IP Node Protection
+-----------+
+---------------------------| Tester |<----------------------+
| +-----------+ |
| IP Traffic | Failover IP Traffic |
| | Event |
| Primary Path | |
| ------------ -------- | -------- ---------- |
+--->| Ingress/ | |MidPoint| V |Midpoint| | Egress/ |---+
|Headend Node|----| Node |---| Node |---|Merge Node|
------------ -------- -------- ----------
| ^
| --------- -------- | Backup
+--------| Backup |----| Backup |--------+ Path
| Node | | Node |
--------- --------
Figure 3. System Under Test (SUT) for Sub-IP Path Protection
+-----------+
+--------------------| Tester |<-------------------+ +--------------------| Tester |<-------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| Primary | | | Primary | |
| +--------+ Path v +--------+ | | +--------+ Path v +--------+ |
| | |------------------------>| | | | | |------------------------>| | |
+--->| Node 1 | | Node 2 |----+ +--->| Ingress| | Egress |----+
| |- - - - - - - - - - - - >| | | Node |- - - - - - - - - - - - >| Node |
+--------+ Backup Path +--------+ +--------+ Backup Path +--------+
^ ^ ^ ^
| IP-Layer Forwarding | | IP-Layer Forwarding |
+-------------------------------------------+ +-------------------------------------------+
Figure 1. System Under Test (SUT) for Sub-IP Protection Mechanisms Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection
Protection Performance
+-----------+
+-----------------| Tester |<--------------------+
| +-----------+ |
| IP Traffic | Failover IP Traffic |
| | Event |
| V |
| --------- -------- ---------- |
+--->| Ingress | |Primary | | Egress/ |------+
| Node |----| Node |----|Merge Node| Primary
--------- -------- ---------- Path
| State |Control ^
| Interface |(Optional) |
| --------- |
+---------| Standby |---------+
| Node |
---------
Figure 5. System Under Test (SUT) for Sub-IP Redundant Node Protection
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]
skipping to change at page 5, line 9 skipping to change at page 7, line 9
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 Protection Performance
3. Test Considerations 3. Test Considerations
3.1. Path 3.1. Paths
3.1.1 Path 3.1.1 Path
Definition: Definition:
A unidirectional sequence of nodes, <R1, ..., Rn>, and links A unidirectional sequence of nodes, <R1, ..., Rn>, and links
<L12,... L(n-1)n> with the following properties: <L12,... L(n-1)n> with the following properties:
a. R1 is the ingress node and forwards IP packets, which input a. R1 is the ingress node and forwards IP packets, which input
into DUT/SUT, to R2 as sub-IP frames over link L12. into DUT/SUT, to R2 as sub-IP frames over link L12.
skipping to change at page 6, line 4 skipping to change at page 7, line 48
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:
Working Path
Primary Path
Backup Path
Protection Performance Protection Performance
3.1.2. 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 the Working Path before occurrence of a A Primary Path is the Working Path before occurrence of a
skipping to change at page 6, line 35 skipping to change at page 8, line 34
Primary Path Primary Path
Backup Path Backup Path
3.1.3. 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:
The Primary Path is the Path that traffic traverses
prior to a Failover Event.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
None None
See Also: See Also:
Path Path
Failover Event
3.1.4. Protected Primary Path 3.1.4. Protected Primary Path
Definition: Definition:
A 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 A Protected Primary Path MUST include at least one Protection
Switching Node. Switching Node.
skipping to change at page 8, line 13 skipping to change at page 10, line 13
Primary Path Primary Path
Protection Performance Protection Performance
3.1.6. 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.
Discussion: Discussion:
The Standby Backup Path and Dynamic Backup Path provide
protection, but are established at different times.
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Path Backup Path
Working Path
Primary Path Primary Path
Failover Event Failover Event
3.1.7. 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:
The Standby Backup Path and Dynamic Backup Path provide
protection, but are established at different times.
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Path Backup Path
Working Path Standby Backup Path
Primary Path
Failover Event Failover Event
3.1.8. 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.
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 Protection Performance
Measurement units: Measurement units: n/a
n/a
Issues: Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
SRLG SRLG
3.1.9. Shared Risk Link Group (SRLG) 3.1.9. Point of Local Repair (PLR)
Definition: Definition:
SRLG is a set of links which share a physical resource. A node along the Primary Path that uses a Backup Path to
protect another node or link.
Discussion: Discussion:
SRLG is considered the set of links to be avoided when Based on the functionality of the PLR, its role is defined
the primary and secondary paths are considered disjoint. based on the type of method used. If the one-to-one backup
The SRLG will fail as a group if the shared resource fails. method is used, the PLR is responsible for computing a
separate Backup Path for each Primary Path. In the case
the facility backup method is used, the PLR creates a
single Backup Path that can be used to protect multiple
Primary Paths. Any node from the ingress node to the
penultimate egress node MAY be a PLR. If the PLR is at
the ingress, the Backup Path is a Disjoint Path from the
ingress to egress.
Measurement units: Measurement units: n/a
n/a
Issues: None Issues: None
See Also: See Also:
Path
Primary Path Primary Path
Backup Path
Failover
3.2. Protection 3.1.10. Shared Risk Link Group (SRLG)
3.2.1. Protection Switching System
Definition: Definition:
A DUT/SUT that is capable of Failure Detection and Failover SRLG is a set of links which share a physical resource.
from a Primary Path to a Backup Path when a Failover Event
occurs.
Discussion: Discussion:
The Protection Switching System MUST have a Primary Path SRLG is considered the set of links to be avoided when
and a Backup Path. The Backup Path MAY be a Standby the primary and secondary paths are considered disjoint.
Backup Path or a dynamic Backup Path. The Protection The SRLG will fail as a group if the shared resource fails.
Switching System includes the mechanisms for both Failure
Detection and Failover.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Path
Primary Path Primary Path
Backup Path
Failover
Protection Performance Protection Performance
3.2.2. Link Protection 3.2. Protection
3.2.1. Link Protection
Definition: Definition:
A Backup Path that is signaled to protect for failure A Backup Path that is signaled to at least one Backup Node
of interfaces and links along a Primary Path. to protect for 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. Link protection is shown in Figure 1.
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.2. Node Protection
Definition: Definition:
A Backup Path that is signaled to protect for failure A Backup Path that is signaled to at least one Backup Node
of interfaces, links and nodes along a Primary Path. to protect for failure of interfaces, links, and nodes
along a Primary Path.
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.
Node Protection is shown in Figure 2.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Link Protection Link Protection
3.2.4. Path Protection 3.2.3. Path Protection
Definition: Definition:
A Backup Path that provides protection for the entire A Backup Path that is signaled to at least one Backup Node
Primary Path. to provide protection along the entire 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. Path Protection is shown in
Figure 3.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
Protection Performance 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.4. Backup Span
Definition: Definition:
The numbers of hop used by a Backup Path. The number of hops used by a Backup Path.
Discussion: Discussion:
The Backup Span is an integer obtained by counting the
number of nodes along the Backup path
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.5. Local Link Protection
Definition:
A Backup Path that is a redundant path between two nodes
which does not use a Backup Node.
Discussion:
Local Link Protection MUST be provided as a Backup Path
between two nodes along the Primary Path without the use
of a Backup Node. Local Link Protection is provided by
Protection Switching Systems such as SONET APS. Local
Link Protection is shown in Figure 4.
Measurement units: None
Issues: None
See Also:
Backup path
Headend
Protection Performance
3.2.6. Redundant Node Protection
Definition:
A Protection Switching System with a Primary Node
protected by a Standby Node along the Primary Path.
Discussion:
Redundant Node Protection is provided by Protection
Switching Systems such as VRRP and HA. The protection
mechanisms occur at Sub-IP layers to switch traffic from
a Primary Node to Backup Node upon a Failover Event at
the Primary Node. Traffic continues to traverse the
Primary Path through the Standby Node. The failover MAY
be stateful, in which the state information MAY be
exchanged in-band or over an out-of-band state control
interface. The Standby Node MAY be active or passive.
Redundant Node Protection is shown in Figure 5.
Measurement units: None
Issues: None
See Also:
Primary Path
Primary Node
Backup Node
3.2.7. State Control Interface
Definition:
An out-of-band control interface used to exchange state
information between the Primary Node and Standby Node.
Discussion:
The State Control Interface MAY be used for Redundant Node
Protection. The State Control Interface MUST be out-of-band.
It is possible to have Redundant Node Protection in which
there is no state control or state control is provided
in-band. The State Control Interface between the Primary
and Standby Node MAY be one or more hops.
Measurement units: None
Issues: None
See Also:
Primary Node
Standby Node
Protection Performance
3.2.8. Protected Interface
Definition: Definition:
An interface along the Primary Path that is protected by An interface along the Primary Path that is protected by
a Backup Path a Backup Path.
Discussion: Discussion:
A Protected Interface is an interface protected by a
Protection Switching Systems that provides Link
Protection, Node Protection, Path Protection, Local
Link Protection, and Redundant Node Protection.
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Protection Performance
3.3. Protection Switching 3.3. Protection Switching
3.3.1. Failover Event 3.3.1. Protection Switching System
Definition:
A DUT/SUT that is capable of Failure Detection and Failover
from a Primary Path to a Backup Path or Standby Node when a
Failover Event occurs.
Discussion:
The Protection Switching System MUST have a Primary Path
and a Backup Path. The Backup Path MAY be a Standby
Backup Path or a dynamic Backup Path. The Protection
Switching System includes the mechanisms for both Failure
Detection and Failover.
Measurement units: n/a
Issues: None
See Also:
Primary Path
Backup Path
Failover
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.
Protection Performance
Discussion: Discussion:
Failover Events include, but are not limited to, link failure Failover Events include, but are not limited to, link failure
and router failure. Routing changes are considered Convergence and router failure. Routing changes are considered Convergence
Events [7] and are not Failover Events. This restricts Events [7] and are not Failover Events. This restricts
Failover Events to sub-IP layers. Failover may be at the PLR or Failover Events to sub-IP layers. Failover may be at the PLR or
at the ingress. If the failover is at the ingress it is at the ingress. If the failover is at the ingress it is
generally on a disjoint path from the ingress to egress. generally on a disjoint path from the ingress to egress.
Failover Events may results from failures such as link failure
or router failure. The change in path after Failover MAY have
a Backup Span of one or more nodes. Failover Events are
distinguished from routing changes and Convergence Events [7]
by the detection of the failure and subsequent protection
switching at a sub-IP layer. Failover occurs at a Point of
Local Repair (PLR) or Primary Node.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Failure Detection Failure Detection
Disjoint Path Disjoint Path
3.3.2. Failure Detection 3.3.3. Failure Detection
Definition: Definition:
The process to identify at a sub-IP layer a Failover Event The process to identify at a sub-IP layer a Failover Event
along the Primary Path. at a Primary Node or along the Primary Path.
Discussion: Discussion:
Failure Detection occurs at the ingress node of the Primary Failure Detection occurs at the Primary Node or ingress node
Path. Failure Detection occurs via a sub-IP mechanism such of the Primary Path. Failure Detection occurs via a sub-IP
as detection of a link down event or timeout for receipt mechanism such as detection of a link down event or timeout for
of a control packet. A failure may be completely isolated. A receipt of a control packet. A failure may be completely
failure may affect a set of links which share a single SRLG isolated. A failure may affect a set of links which share a
(e.g. port with many sub-interfaces). A failure may affect single SRLG (e.g. port with many sub-interfaces). A failure may
multiple links that are not part of SRLG. affect multiple links that are not part of SRLG.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Protection Performance Protection Performance
3.3.3. Failover 3.3.4. Failover
Definition: Definition:
The process to switch data traffic from the Protected Primary The process to switch data traffic from the Protected Primary
Path to the Backup Path upon Failure Detection of a Failover Path to the Backup Path upon Failure Detection of a Failover
Event. 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
Packet Loss [7], Out-of-order Packets [4], and Duplicate Packet Loss [7], Out-of-order Packets [4], and Duplicate
skipping to change at page 13, line 30 skipping to change at page 17, line 30
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.5. Restoration
Definition: Definition:
The act of failover recovery in which the Primary Path The state of failover recovery in which the Primary Path
recovers from a Failover Event, but is not yet forwarding has recovered from a Failover Event, but is not yet
packets because the Backup Path remains the Working Path. 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 Restoration. Restoration produces Working Path during Restoration. Restoration produces
a Primary Path that is recovered from failure, but is a Primary Path that is recovered from failure, but is
not yet forwarding traffic. Traffic is still being not yet forwarding traffic. Traffic is still being
forwarded by the Backup Path functioning as the Working forwarded by the Backup Path functioning as the Working
Path. Path.
skipping to change at page 14, line 6 skipping to change at page 18, line 6
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.6. Reversion
Definition: Definition:
The act of failover recovery in which the Primary Path becomes The state of failover recovery in which the Primary Path has
the Working Path so that it is forwarding packets. become 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 Restoration. Reversion, if supported, MUST occur after Restoration.
Packet forwarding on the Primary Path resulting from Reversion Packet forwarding on the Primary Path resulting from Reversion
may occur either fully or partially over the Primary Path. A may occur either fully or partially over the Primary Path. A
potential problem with Reversion is the discontinuity in end to potential problem with Reversion is the discontinuity in end to
end delay when the Forwarding Delays [4] along the Primary Path end delay when the Forwarding Delays [4] along the Primary Path
and Backup Path are different, possibly causing Out of Order and Backup Path are different, possibly causing Out of Order
Packets [4], Duplicate Packets [4], and increased Jitter [4]. Packets [4], Duplicate Packets [4], and increased Jitter [4].
skipping to change at page 14, line 36 skipping to change at page 18, line 36
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
Definition: Definition:
A node that is capable to participate in a Protection Switching A node that is capable of participating in a Protection
System. Switching System.
Discussion: Discussion:
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, such as used for MPLS Fast
Reroute configurations. The Protection Switching Node MAY
provide Redundant Node Protection as a Primary Node in a
Redundant chassis configuration with a Standby Node, such as
used for VRRP and HA configurations.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Protection Switching System Protection Switching System
Protection Performance
3.4.2. Non-Protection Switching Node 3.4.2. Non-Protection Switching Node
Definition: Definition:
A node that is 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
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Protection Switching System Protection Switching System
Primary Path Primary Path
Backup Path Backup Path
3.4.3. Failover Node 3.4.3. Headend Node
Definition: Definition:
A node along the Primary Path that is capable of Failover. A node along the Primary Path that is capable of Failover.
Discussion: Discussion:
The Failover Node can be any node along the Primary Path The Headend Node can be any node along the Primary Path
except the egress node of the Primary Path. There can be except the egress node of the Primary Path. There can be
multiple Failover Nodes along a Primary Path. The Failover multiple Failover Nodes along a Primary Path. The Failover
Node MUST be the ingress to the Backup Path. The Failover Node MUST be the ingress to the Backup Path. The Failover
Node MAY also be the ingress of the Primary Path. Node MAY also be the ingress of the Primary Path. The Headend
Failover Node is always a PLR.
Measurement units: Measurement units: n/a
n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Point of Local Repair
Failover Failover
3.4.4. Merge Node 3.4.4. Backup Node
Definition:
A node along the Backup Path.
Discussion:
The Backup Node can be any node along the Backup Path.
There MAY be one or more Backup Nodes along the Backup Path.
A Backup Node MAY be the ingress, mid-point, or egress of
the Backup Path. If the Backup Path has only one Backup
Node, then that Backup Node is the ingress and egress of the
Backup Path.
Protection Performance
Measurement units: n/a
Issues:
See Also:
Backup Path
3.4.5. 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).
Measurement units: Measurement units:
n/a n/a
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.6. Primary Node
Definition: Definition:
A node along the Primary Path that uses a Backup Path to A node along the Primary Path that is capable of Failover to a
protect another node or link. redundant Standby Node.
Discussion: Discussion:
Based on the functionality of the PLR, its role is defined The Primary Node MAY be used for Protection Switching Systems
based on the type of method used. If the one-to-one backup that provide Redundant Node Protection, such as VRRP and HA
method is used, the PLR is responsible for computing a
separate Backup Path for each Primary Path. In the case
the facility backup method is used, the PLR creates a
single Backup Path that can be used to protect multiple
Primary Paths.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Protection Switching System
Backup Path Redundant Node Protection
Failover Standby Node
Protection Performance
3.4.6. Head-end Failover Node 3.4.7. Standby Node
Definition: Definition:
A node along the Primary Path that is capable of Failover. A redundant node to a Primary Node that forwards traffic along
the Primary Path upon Failure Detection of the Primary Node.
Discussion: Discussion:
The Head-end Failover Node is the ingress node to the Backup The Standby Node MUST be used for Protection Switching
Path. The Head-end Failover Node is always a PLR Systems that provide Redundant Node Protection, such as VRRP
and HA. The Standby Node MUST provide protection along the
same Primary Path. If the failover is to a Disjoint Path then
it is a Backup Node. The Standby Node MAY be configured
for 1:1 or N:1 protection.
The communication between the Primary Node and Standby Node
MAY be in-band or across an out-of-band State Control
interface. The Standby Node MAY be geographically dispersed
from the Primary Node. When geographically dispersed, the
number of hops of separation may increase failover time.
The Standby Node MAY be passive or active. The Passive Standby
Node is not offered traffic and does not forward traffic until
Failure Detection of the Primary Node. Upon Failure Detection
of the Primary Node, traffic offered to the Primary Node is
instead offered to the Passive Standby Node. The Active
Standby Node is offered traffic and forwards traffic along the
Primary Path while the Primary Node is also active. Upon
Failure Detection of the Primary Node, traffic offered to the
Primary Node is switched to the Active Standby Node.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Node
Point of Local Repair State Control Interface
Failover
Protection Performance
3.5. Benchmarks 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 until The amount of packet loss produced by a Failover Event until
Failover completes, where the measurement begins when the last Failover completes, where the measurement begins when the last
unimpaired packet is received by the Tester on the Protected unimpaired packet is received by the Tester on the Protected
Primary Path and ends when the first unimpaired packet is Primary Path and ends when the first unimpaired packet is
received by the Tester on the Backup Path. received by the Tester on the Backup Path.
Protection Performance
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, reordered, or delayed. Loss includes packets that were lost, reordered, or delayed.
Failover Packet Loss MAY reach 100% of the offered load. Failover Packet Loss MAY reach 100% of the offered load.
Measurement units: Measurement units:
Number of Packets Number of Packets
Issues: None Issues: None
skipping to change at page 18, line 4 skipping to change at page 22, line 43
traffic from the maximum forwarding rate. Reversion Packet traffic from the maximum forwarding rate. Reversion Packet
Loss includes packets that were lost, reordered, or delayed. Loss includes packets that were lost, reordered, or delayed.
Reversion Packet Loss MAY reach 100% of the offered load. Reversion Packet Loss MAY reach 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
3.5.3. Failover Time 3.5.3. Failover Time
Definition: Definition:
The amount of time it takes for Failover to successfully The amount of time it takes for Failover to successfully
complete. complete.
Discussion: Discussion:
Failover Time can be calculated using the Time-Based Loss Failover Time can be calculated using the Time-Based Loss
Method (TBLM), Packet-Loss Based Method (PLBM), 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.
Protection Performance
Measurement units: Measurement units:
milliseconds milliseconds
Issues: None Issues: None
See Also: See Also:
Failover Failover
Failover Time Failover Time
Time-Based Loss Method (TBLM) Time-Based Loss Method (TBLM)
Packet-Loss Based Method (PLBM) Packet-Loss Based Method (PLBM)
skipping to change at page 19, line 4 skipping to change at page 23, line 44
Issues: None Issues: None
See Also: See Also:
Reversion Reversion
Primary Path Primary Path
Working Path Working Path
Reversion Packet Loss Reversion Packet Loss
Time-Based Loss Method (TBLM) Time-Based Loss Method (TBLM)
Packet-Loss Based Method (PLBM) Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM) Timestamp-Based Method (TBM)
Protection Performance
3.5.5. Additive Backup Delay 3.5.5. Additive Backup Delay
Definition: Definition:
The amount of increased Forwarding Delay [4] resulting The amount of increased Forwarding Delay [4] resulting
from data traffic traversing the Backup Path instead of from data traffic traversing the Backup Path instead of
the Primary Path. the Primary Path.
Discussion: Discussion:
Additive Backup Delay is calculated using Equation 1 as Additive Backup Delay is calculated using Equation 1 as
shown below: shown below:
(Equation 1) (Equation 1)
Additive Backup Delay = Additive Backup Delay =
Forwarding Delay(Backup Path) - Forwarding Delay(Backup Path) -
Forwarding Delay(Primary Path). Forwarding Delay(Primary Path).
Protection Performance
Measurement units: Measurement units:
milliseconds 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
skipping to change at page 20, line 5 skipping to change at page 24, line 39
Discussion: Discussion:
The Tester MUST 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. Failover Time and Reversion Time are calculated Backup Path. Failover Time and Reversion Time are calculated
using the TBLM as shown in Equation 2: using the TBLM as shown in Equation 2:
Protection Performance
(Equation 2) (Equation 2)
(Equation 2a) (Equation 2a)
TBLM Failover Time = Time(Failover) - Time(Failover Event) TBLM Failover Time = Time(Failover) - Time(Failover Event)
(Equation 2b) (Equation 2b)
TBLM Reversion Time = Time(Reversion) - Time(Restoration) TBLM Reversion Time = Time(Reversion) - Time(Restoration)
Measurement units: Measurement units:
milliseconds milliseconds
Issues: Issues:
None None
See Also: See Also:
Failover Failover
Packet-Loss Based Method Packet-Loss Based Method
Protection Performance
3.6.2 Packet-Loss Based Method (PLBM) 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 Failover Packet Loss. from the amount of Failover Packet Loss.
Discussion: Discussion:
PLBM includes failure detection time and time for data traffic to PLBM includes failure detection time and time for data traffic to
begin traversing the Backup Path. Failover Time can be begin traversing the Backup Path. Failover Time can be
skipping to change at page 21, line 4 skipping to change at page 25, line 40
Measurement units: Measurement units:
milliseconds milliseconds
Issues: Issues:
None None
See Also: See Also:
Failover Failover
Time-Based Loss Method Time-Based Loss Method
Protection Performance
3.6.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 2 with the difference being that the time using Equation 2 with the difference being that the time
values are obtained from the timestamp in the packet payload values are obtained from the timestamp in the packet payload
rather than from the Tester. rather than from the Tester.
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
Protection Performance
[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 indicates 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
skipping to change at page 22, line 4 skipping to change at page 26, line 29
Measurement units: Measurement units:
milliseconds milliseconds
Issues: None Issues: None
See Also: See Also:
Failover Failover
Failover Time Failover Time
Reversion Reversion
Reversion Time Reversion Time
Protection Performance
4. Acknowledgements 4. Acknowledgements
We would like thank the BMWG and particularly Al Morton and Curtis We would like thank the BMWG and particularly Al Morton and Curtis
Villamizar for their reviews, comments, and contributions to this Villamizar for their reviews, comments, and contributions to this
work. work.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA considerations. This document requires no IANA considerations.
6. Security Considerations 6. Security Considerations
skipping to change at page 22, line 34 skipping to change at page 27, line 5
[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] Poretsky, S., et al., "Terminology for Benchmarking [4] Poretsky, S., et al., "Terminology for Benchmarking
Network-layer Traffic Control Mechanisms", RFC 4689, Network-layer Traffic Control Mechanisms", RFC 4689,
November 2006. November 2006.
Protection Performance
[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, 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-15,
work in progress, July 2007. work in progress, February 2008.
[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
Paths", 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.
skipping to change at page 22, line 55 skipping to change at page 27, line 28
Paths", 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
None None
Protection Performance
8. Author's Address 8. Author's Address
Scott Poretsky Scott Poretsky
Reef Point Systems NextPoint Networks
8 New England Executive Park 3 Federal Street
Burlington, MA 01803 Billerica, MA 01821
USA USA
Phone: + 1 508 439 9008 Phone: + 1 508 439 9008
EMail: sporetsky@reefpoint.com EMail: sporetsky@nextpointnetworks.com
Rajiv Papneja Rajiv Papneja
Isocore Isocore
12359 Sunrise Valley Drive 12359 Sunrise Valley Drive
Reston, VA 22102 Reston, VA 22102
USA USA
Phone: 1 703 860 9273 Phone: 1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Jay Karthik Jay Karthik
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0533 Phone: +1 978 936 0533
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
Protection Performance
Samir Vapiwala 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: svapiwal@cisco.com Email: svapiwal@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Protection Performance
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 108 change blocks. 
211 lines changed or deleted 473 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/