draft-ietf-bmwg-protection-term-08.txt   draft-ietf-bmwg-protection-term-09.txt 
Network Working Group S. Poretsky Network Working Group S. Poretsky
Internet Draft Allot Communications Internet Draft Allot Communications
Expires: June 2010 Rajiv Papneja Expires: Jan 2011 Rajiv Papneja
Intended Status: Informational Isocore J. Karthik Intended Status: Informational Isocore
J. Karthik
S. Vapiwala S. Vapiwala
Cisco Systems Cisco Systems
July 2010
December 2009
Benchmarking Terminology Benchmarking Terminology
for Protection Performance for Protection Performance
<draft-ietf-bmwg-protection-term-08.txt > <draft-ietf-bmwg-protection-term-09.txt >
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
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.
This Internet-Draft will expire on April 15, 2010. This Internet-Draft will expire on 7 Jan, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described
in Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s)
controlling the copyright in such materials, this document may not
be modified outside the IETF Standards Process, and derivative
works of it may not be created outside the IETF Standards Process,
except to format it for publication as an RFC or to translate it
into languages other than English.
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, avoiding dependence on benchmarks are measured at the IP-Layer with protection may be
specific sub-IP protection mechanisms. The benchmarks and terminology provided at the Sub-IP layer. The benchmarks and terminology can be
can be applied in methodology documents for different sub-IP layer applied in methodology documents for different sub-IP layer protection
protection mechanisms such as Automatic Protection Switching (APS), mechanisms such as Automatic Protection Switching (APS), Virtual Router
Virtual Router Redundancy Protocol (VRRP), Stateful High Availability Redundancy Protocol (VRRP), Stateful High Availability (HA), and
(HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). 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......................................6 2. Existing definitions......................................6
3. Test Considerations.......................................7 3. Test Considerations.......................................7
3.1. Paths................................................7 3.1. Paths................................................7
3.1.1. Path............................................7 3.1.1. Path............................................7
3.1.2. Working Path....................................8 3.1.2. Working Path....................................8
3.1.3. Primary Path....................................8 3.1.3. Primary Path....................................8
skipping to change at page 3, line 11 skipping to change at page 4, line 11
6. Security Considerations...................................26 6. Security Considerations...................................26
7. References................................................26 7. References................................................26
8. Authors' Addresses........................................27 8. Authors' Addresses........................................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. Fast traffic against planned and unplanned failures in the internet. Fast
convergence times are critical to maintain reliable network convergence times are critical to maintain reliable network
connectivity and performance. Convergence Events [7] are recognized connectivity and performance. Convergence Events [6] are recognized
at the IP Layer so that Route Convergence [7] occurs. Technologies at the IP Layer so that Route Convergence [6] occurs. Technologies
that function at sub-IP layers can be enabled to provide further that function at sub-IP layers can be enabled to provide further
protection of IP traffic by providing the failure recovery at the protection of IP traffic by providing the failure recovery at the
sub-IP layers so that the outage is not observed at the IP-layer. sub-IP layers so that the outage is not observed at the IP-layer.
Such sub-IP protection technologies include, but are not limited to, Such sub-IP protection technologies include, but are not limited to,
High Availability (HA) stateful failover, Virtual Router Redundancy High Availability (HA) stateful failover, Virtual Router Redundancy
Protocol (VRRP) [11], Automatic Link Protection (APS) for SONET/SDH, Protocol (VRRP) [8], Automatic Link Protection (APS) for SONET/SDH,
Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for
Multi-Protocol Label Switching (MPLS-FRR) [8]. Multi-Protocol Label Switching (MPLS-FRR) [9].
1.1 Scope 1.1 Scope
Benchmarking terminology was defined for IP-layer convergence in Benchmarking terminology was defined for IP-layer convergence in
[7]. Different terminology and methodologies specific to [6]. Different terminology and methodologies specific to
benchmarking sub-IP layer protection mechanisms are required. The benchmarking sub-IP layer protection mechanisms are required. The
metrics for benchmarking the performance of sub-IP protection metrics for benchmarking the performance of sub-IP protection
mechanisms are measured at the IP layer, so that the results are mechanisms are measured at the IP layer, so that the results are
always measured in reference to IP and independent of the specific always measured in reference to IP and independent of the specific
protection mechanism being used. The purpose of this document is protection mechanism being used. The purpose of this document is
to provide a single terminology for benchmarking sub-IP protection to provide a single terminology for benchmarking sub-IP protection
mechanisms. mechanisms.
A common terminology for Sub-IP layer protection mechanism A common terminology for Sub-IP layer protection mechanism
benchmarking enables different implementations of a protection benchmarking enables different implementations of a protection
skipping to change at page 5, line 53 skipping to change at page 6, line 53
+--------------------| Tester |<-------------------+ +--------------------| Tester |<-------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| Primary | | | Primary | |
| +--------+ Path v +--------+ | | +--------+ Path v +--------+ |
| | |------------------------>| | | | | |------------------------>| | |
+--->| Ingress| | Egress |----+ +--->| Ingress| | Egress |----+
| Node |- - - - - - - - - - - - >| Node | | Node |- - - - - - - - - - - - >| Node |
+--------+ Backup Path +--------+ +--------+ Backup Path +--------+
^ ^ | |
| IP-Layer Forwarding | | IP-Layer Forwarding |
+-------------------------------------------+ +<----------------------------------------->+
Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection Figure 4. System Under Test (SUT) for Sub-IP Local Link Protection
Protection Performance Protection Performance
+-----------+ +-----------+
+-----------------| Tester |<--------------------+ +-----------------| Tester |<--------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| V | | V |
skipping to change at page 6, line 46 skipping to change at page 7, line 46
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]
Offered Load [Ref.[3], section 3.5.2] Offered Load [Ref.[3], section 3.5.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] Forwarding Delay [Ref.[4], section 3.2.4]
Jitter [Ref.[4], section 3.2.5] Jitter [Ref.[4], section 3.2.5]
Packet Loss [Ref.[7], Section 3.5] Packet Loss [Ref.[6], Section 3.5]
Packet Reordering [Ref.[10], section 3.3] Packet Reordering [Ref.[7], section 3.3]
This document has the following frequently used acronyms: This document has the following frequently used acronyms:
DUT Device Under Test DUT Device Under Test
SUT System 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]. Terms defined in this document are capitalized when used [2]. Terms defined in this document are capitalized when used
within this document. within this document.
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].
Protection Performance
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. Paths 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.
b. Ri is a node which forwards data frames to R[i+1] over Link 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 Li(i+1) for all i, 1<i<n-1, based on information in the sub-IP
layer. layer.
c. Rn is the egress node and it outputs sub-IP frames from c. Rn is the egress node and it outputs sub-IP frames from
DUT/SUT as IP packets. DUT/SUT as IP packets. L(n-1)n is the link between the R(n-1)
and Rn.
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]. One path may be regarded as being an IP path in RFC 2026 [1]. One path may be regarded as being
equivalent to one IP link between two IP nodes, i.e., R1 and Rn. equivalent to one IP link between two IP nodes, i.e., R1 and Rn.
The two IP nodes may have multiple paths for protection. A The two IP nodes may have multiple paths for protection. A
packet will travel on only one path between the nodes. Packets packet will travel on only one path between the nodes. Packets
belonging to a microflow [9] will traverse one or more paths. belonging to a microflow [10] will traverse one or more paths.
The path is unidirectional. For example, the link between R1 The path is unidirectional. For example, the link between R1
and R2 in the direction from R1 to R2 is L12. For traffic and R2 in the direction from R1 to R2 is L12. For traffic
flowing in the reverse direction from R2 to R1, the link is L21. flowing in the reverse direction from R2 to R1, the link is L21.
Example paths are the SONET/SDH path and the label switched path Example paths are the SONET/SDH path and the label switched path
for MPLS. for MPLS.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
skipping to change at page 8, line 14 skipping to change at page 9, line 14
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
Failover Event. A Backup Path SHALL become the Working Path Failover Event. A Backup Path shall become the Working Path
after a Failover Event. after a Failover Event.
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.3. Primary Path 3.1.3. Primary Path
Definition: Definition:
The preferred path for forwarding traffic between two or The preferred point to point path for forwarding traffic
more nodes. between two or more nodes.
Discussion: Discussion:
The Primary Path is the Path that traffic traverses The Primary Path is the Path that traffic traverses
prior to a Failover Event. prior to a Failover Event.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
None None
skipping to change at page 8, line 53 skipping to change at page 9, line 53
See Also: See Also:
Path Path
Failover Event 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.
Protection Performance Protection Performance
Measurement units: Measurement units:
n/a n/a
Issues: None Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
3.1.5. 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 on a Primary Path. Event occurs on a Primary Path.
Discussion: Discussion:
The Backup Path SHALL become the Working Path upon a Failover The Backup Path shall become the Working Path upon a Failover
Event. A Path MAY have one or more Backup Paths. A Backup Event. A Path may have one or more Backup Paths. A Backup
Path MAY protect one or more Primary Paths. There are various Path may protect one or more Primary Paths. There are various
types of Backup Paths: types of Backup Paths:
a. dedicated recovery Backup Path (1+1), which has 100% a. dedicated recovery Backup Path (1+1) or (1:1), which has
redundancy for a specific ordinary path, 100% redundancy for a specific ordinary path,
b. shared Backup Path (1:N), which is dedicated to the b. shared Backup Path (1:N), which is dedicated to the
protection for more than one specific Primary Path protection for more than one specific Primary Path
c. associated shared Backup Path (M:N) for which a specific c. associated shared Backup Path (M:N) for which a specific
set of Backup Paths protects a specific set of more than one set of Backup Paths protects a specific set of more than one
Primary Path. Primary Path.
A Backup Path may be signaled or unsignaled. The Backup Path A Backup Path may be signaled or unsignaled. The Backup Path
MUST be created prior to the Failover Event. The backup path must be created prior to the Failover Event. The backup path
generally originates at the point of failure, and terminates at generally originates at the point of local repair (PLR), and
a node along a primary path. terminates at a node along a 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
skipping to change at page 10, line 47 skipping to change at page 11, line 47
Issues: None Issues: None
See Also: See Also:
Backup Path Backup Path
Standby Backup Path Standby Backup Path
Failover Event Failover Event
3.1.8. Disjoint Paths 3.1.8. Disjoint Paths
Definition: Definition:
A pair of paths that do not share a common link. A pair of paths that do not share a common link or nodes.
Discussion: Discussion:
Two paths are disjoint if they do not share a common node other Two paths are disjoint if they do not share a common node or link
than the ingress and egress. other than the ingress and egress.
Protection Performance Protection Performance
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
SRLG SRLG
3.1.9. Point of Local Repair (PLR) 3.1.9. Point of Local Repair (PLR)
Definition: Definition:
A node capable of Failover along the Primary Path that is A node capable of Failover along the Primary Path that is
also the ingress node for the Backup Path to protect another also the ingress node for the Backup Path to protect another
node or link. node or link.
Discussion: Discussion:
Any node along the Primary Path from the ingress node to Any node along the Primary Path from the ingress node to
the penultimate egress node MAY be a PLR. The PLR MAY use the penultimate node may be a PLR. The PLR may use
a single Backup Path for protecting one or more Primary a single Backup Path for protecting one or more Primary
Paths. There can be multiple PLRs along a Primary Path. Paths. There can be multiple PLRs along a Primary Path.
The PLR MUST be an ingress to a Backup Path. The PLR can The PLR must be an ingress to a Backup Path. The PLR can
be any node along the Primary Path except the egress node be any node along the Primary Path except the egress node
of the Primary Path. The PLR MAY simultaneously be a of the Primary Path. The PLR may simultaneously be a
Headend Node when it is serving the role as ingress to Headend Node when it is serving the role as ingress to
the Primary Path and the Backup Path. If the PLR is the Primary Path and the Backup Path. If the PLR is
also the Headend Node, then the Backup Path is a Disjoint also the Headend Node, then the Backup Path is a Disjoint
Path from the ingress to the Merge Node. Path from the ingress to the Merge Node.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
3.1.10. Shared Risk Link Group (SRLG) 3.1.10. Shared Risk Link Group (SRLG)
Definition: Definition:
SRLG is a set of links which share a physical resource. SRLG is a set of links which share the same risk (physical
or logical) within a network.
Discussion: Discussion:
SRLG is 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. The SRLG will fail as a group if the shared resource
(physical or anything abstract such as software version)
fails.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Path Path
Primary Path Primary Path
Protection Performance Protection Performance
skipping to change at page 12, line 51 skipping to change at page 13, line 51
Link Protection Link Protection
3.2.3. Path Protection 3.2.3. Path Protection
Definition: Definition:
A Backup Path that is signaled to at least one Backup Node A Backup Path that is signaled to at least one Backup Node
to provide protection along the entire 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 may have the same ingress
node as the Primary Path. Path Protection is shown in node as the Primary Path. Path Protection is shown in
Figure 3. 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
skipping to change at page 13, line 38 skipping to change at page 14, line 38
Primary Path Primary Path
Backup Path Backup Path
3.2.5. Local Link Protection 3.2.5. Local Link Protection
Definition: Definition:
A Backup Path that is a redundant path between two nodes A Backup Path that is a redundant path between two nodes
which does not use a Backup Node. which does not use a Backup Node.
Discussion: Discussion:
Local Link Protection MUST be provided as a Backup Path Local Link Protection must be provided as a Backup Path
between two nodes along the Primary Path without the use between two nodes along the Primary Path without the use
of a Backup Node. Local Link Protection is provided by of a Backup Node. Local Link Protection is provided by
Protection Switching Systems such as SONET APS. Local Protection Switching Systems such as SONET APS. Local
Link Protection is shown in Figure 4. Link Protection is shown in Figure 4.
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
skipping to change at page 14, line 18 skipping to change at page 15, line 18
Definition: Definition:
A Protection Switching System with a Primary Node A Protection Switching System with a Primary Node
protected by a Standby Node along the Primary Path. protected by a Standby Node along the Primary Path.
Discussion: Discussion:
Redundant Node Protection is provided by Protection Redundant Node Protection is provided by Protection
Switching Systems such as VRRP and HA. The protection Switching Systems such as VRRP and HA. The protection
mechanisms occur at Sub-IP layers to switch traffic from mechanisms occur at Sub-IP layers to switch traffic from
a Primary Node to Backup Node upon a Failover Event at a Primary Node to Backup Node upon a Failover Event at
the Primary Node. Traffic continues to traverse the the Primary Node. Traffic continues to traverse the
Primary Path through the Standby Node. The failover MAY Primary Path through the Standby Node. The failover may
be stateful, in which the state information MAY be be stateful, in which the state information may be
exchanged in-band or over an out-of-band state control exchanged in-band or over an out-of-band state control
interface. The Standby Node MAY be active or passive. interface. The Standby Node may be active or passive.
Redundant Node Protection is shown in Figure 5. Redundant Node Protection is shown in Figure 5.
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Primary Node Primary Node
Standby Node Standby Node
3.2.7. State Control Interface 3.2.7. State Control Interface
Definition: Definition:
An out-of-band control interface used to exchange state An out-of-band control interface used to exchange state
information between the Primary Node and Standby Node. information between the Primary Node and Standby Node.
Discussion: Discussion:
The State Control Interface MAY be used for Redundant Node The State Control Interface may be used for Redundant Node
Protection. The State Control Interface MUST be out-of-band. Protection. The State Control Interface should be out-of-band.
It is possible to have Redundant Node Protection in which It is possible to have Redundant Node Protection in which
there is no state control or state control is provided there is no state control or state control is provided
in-band. The State Control Interface between the Primary in-band. The State Control Interface between the Primary
and Standby Node MAY be one or more hops. and Standby Node may be one or more hops.
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
Primary Node Primary Node
Standby Node Standby Node
Protection Performance Protection Performance
skipping to change at page 15, line 36 skipping to change at page 16, line 36
3.3. Protection Switching 3.3. Protection Switching
3.3.1. Protection Switching System 3.3.1. Protection Switching System
Definition: Definition:
A DUT/SUT that is capable of Failure Detection and Failover A DUT/SUT that is capable of Failure Detection and Failover
from a Primary Path to a Backup Path or Standby Node when a from a Primary Path to a Backup Path or Standby Node when a
Failover Event occurs. Failover Event occurs.
Discussion: Discussion:
The Protection Switching System MUST include either a The Protection Switching System must include either a
Primary Path and Backup Path, as shown in Figures 1 through Primary Path and Backup Path, as shown in Figures 1 through
4, or a Primary Node and Standby Node, as shown in Figure 4, or a Primary Node and Standby Node, as shown in Figure
5. The Backup Path MAY be a Standby Backup Path or a 5. The Backup Path may be a Standby Backup Path or a
dynamic Backup Path. The Protection Switching System dynamic Backup Path. The Protection Switching System
includes the mechanisms for both Failure Detection and includes the mechanisms for both Failure Detection and
Failover. Failover.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
skipping to change at page 16, line 10 skipping to change at page 17, line 10
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 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 [6] 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 Failover Events may results from failures such as link failure
or router failure. The change in path after Failover MAY have or router failure. The change in path after Failover may have
a Backup Span of one or more nodes. Failover Events are a Backup Span of one or more nodes. Failover Events are
distinguished from routing changes and Convergence Events [7] distinguished from routing changes and Convergence Events [6]
by the detection of the failure and subsequent protection by the detection of the failure and subsequent protection
switching at a sub-IP layer. Failover occurs at a Point of switching at a sub-IP layer. Failover occurs at a Point of
Local Repair (PLR) or Primary Node. Local Repair (PLR) or Primary Node.
Measurement units: Measurement units:
n/a n/a
Issues: None Issues: None
See Also: See Also:
skipping to change at page 17, line 16 skipping to change at page 18, line 16
3.3.4. 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 [6], Out-of-order Packets [4], and Duplicate
Packets [4] are no longer observed. Forwarding Delay [4] Packets [4] are no longer observed. Forwarding Delay [4]
may continue to be observed. may continue to be observed.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
skipping to change at page 17, line 39 skipping to change at page 18, line 39
3.3.5. Restoration 3.3.5. Restoration
Definition: Definition:
The state of failover recovery in which the Primary Path The state of failover recovery in which the Primary Path
has recovered from a Failover Event, but is not yet has recovered from a Failover Event, but is not yet
forwarding packets because the Backup Path remains the forwarding packets because the Backup Path remains the
Working Path. 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.
Measurement units: Measurement units:
n/a n/a
skipping to change at page 18, line 14 skipping to change at page 19, line 14
Protection Performance Protection Performance
3.3.6. Reversion 3.3.6. Reversion
Definition: Definition:
The state of failover recovery in which the Primary Path has The state of failover recovery in which the Primary Path has
become 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].
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
skipping to change at page 18, line 40 skipping to change at page 19, line 40
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 of participating in a Protection A node that is capable of participating in a Protection
Switching 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, such as used for MPLS Fast a Primary Path or Backup Path, such as used for MPLS Fast
Reroute configurations. The Protection Switching Node MAY Reroute configurations. The Protection Switching Node may
provide Redundant Node Protection as a Primary Node in a provide Redundant Node Protection as a Primary Node in a
Redundant chassis configuration with a Standby Node, such as Redundant chassis configuration with a Standby Node, such as
used for VRRP and HA configurations. 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 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, but MAY exist along the Primary Path or Switching System, but may exist along the Primary Path or
Backup Path. Backup Path.
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
skipping to change at page 19, line 48 skipping to change at page 20, line 48
Primary Path Primary Path
Point of Local Repair (PLR) Point of Local Repair (PLR)
Failover Failover
3.4.4. Backup Node 3.4.4. Backup Node
Definition: Definition:
A node along the Backup Path. A node along the Backup Path.
Discussion: Discussion:
The Backup Node can be any node along the Backup Path. The Backup Node can be any node along the Backup Path.
There MAY be one or more Backup Nodes 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 A Backup Node may be the ingress, mid-point, or egress of
the Backup Path. If the Backup Path has only one Backup the Backup Path. If the Backup Path has only one Backup
Node, then that Backup Node is the ingress and egress of the Node, then that Backup Node is the ingress and egress of the
Backup Path. Backup Path.
Protection Performance Protection Performance
Measurement units: n/a Measurement units: n/a
Issues: Issues:
skipping to change at page 20, line 23 skipping to change at page 21, line 23
3.4.5. Merge Node 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
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
PLR PLR
Failover Failover
3.4.6. Primary Node 3.4.6. Primary Node
Definition: Definition:
A node along the Primary Path that is capable of Failover to a A node along the Primary Path that is capable of Failover to a
redundant Standby Node. redundant Standby Node.
Discussion: Discussion:
The Primary Node MAY be used for Protection Switching Systems The Primary Node may be used for Protection Switching Systems
that provide Redundant Node Protection, such as VRRP and HA that provide Redundant Node Protection, such as VRRP and HA
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Protection Switching System Protection Switching System
Redundant Node Protection Redundant Node Protection
Standby Node Standby Node
Protection Performance Protection Performance
3.4.7. Standby Node 3.4.7. Standby Node
Definition: Definition:
A redundant node to a Primary Node that forwards traffic along A redundant node to a Primary Node that forwards traffic along
the Primary Path upon Failure Detection of the Primary Node. the Primary Path upon Failure Detection of the Primary Node.
Discussion: Discussion:
The Standby Node MUST be used for Protection Switching The Standby Node must be used for Protection Switching
Systems that provide Redundant Node Protection, such as VRRP Systems that provide Redundant Node Protection, such as VRRP
and HA. The Standby Node MUST provide protection along the and HA. The Standby Node must provide protection along the
same Primary Path. If the failover is to a Disjoint Path then same Primary Path. If the failover is to a Disjoint Path then
it is a Backup Node. The Standby Node MAY be configured it is a Backup Node. The Standby Node may be configured
for 1:1 or N:1 protection. for 1:1 or N:1 protection.
The communication between the Primary Node and Standby Node The communication between the Primary Node and Standby Node
MAY be in-band or across an out-of-band State Control may be in-band or across an out-of-band State Control
interface. The Standby Node MAY be geographically dispersed interface. The Standby Node may be geographically dispersed
from the Primary Node. When geographically dispersed, the from the Primary Node. When geographically dispersed, the
number of hops of separation may increase failover time. number of hops of separation may increase failover time.
The Standby Node MAY be passive or active. The Passive Standby The Standby Node may be passive or active. The Passive Standby
Node is not offered traffic and does not forward traffic until Node is not offered traffic and does not forward traffic until
Failure Detection of the Primary Node. Upon Failure Detection Failure Detection of the Primary Node. Upon Failure Detection
of the Primary Node, traffic offered to the Primary Node is of the Primary Node, traffic offered to the Primary Node is
instead offered to the Passive Standby Node. The Active instead offered to the Passive Standby Node. The Active
Standby Node is offered traffic and forwards traffic along the Standby Node is offered traffic and forwards traffic along the
Primary Path while the Primary Node is also active. Upon Primary Path while the Primary Node is also active. Upon
Failure Detection of the Primary Node, traffic offered to the Failure Detection of the Primary Node, traffic offered to the
Primary Node is switched to the Active Standby Node. Primary Node is switched to the Active Standby Node.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Node Primary Node
State Control Interface State Control Interface
3.5. Benchmarks 3.5. Benchmarks
The following Benchmarks MAY be assessed on a per-flow basis
using at least 16 flows spread over the routing table (more
flows is better). Otherwise, the impact of a prefix-dependency
in the implementation of a particular protection technology
could be missed. However, the test designer must be aware of
the number of packets per second sent to each prefix, as this
establishes sampling of the path and the time resolution for
measurement of Failover time on a per-flow basis.
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 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
See Also: See Also:
Failover Event Failover Event
Failover Failover
skipping to change at page 22, line 35 skipping to change at page 23, line 35
The amount of packet loss produced by Reversion, where the The amount of packet loss produced by Reversion, where the
measurement begins when the last unimpaired packet is received measurement begins when the last unimpaired packet is received
by the Tester on the Backup Path and ends when the first by the Tester on the Backup Path and ends when the first
unimpaired packet is received by the Tester on the Protected unimpaired packet is received by the Tester on the Protected
Primary Path . 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, 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
3.5.3. Failover Time 3.5.3. Failover Time
skipping to change at page 24, line 11 skipping to change at page 25, line 11
Additive Backup Delay = Additive Backup Delay =
Forwarding Delay(Backup Path) - Forwarding Delay(Backup Path) -
Forwarding Delay(Primary Path). Forwarding Delay(Primary Path).
Protection Performance 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
Backup Path Backup Path
Primary Path Latency Primary Path Latency
Backup Path Latency Backup Path Latency
3.6 Failover Time Calculation Methods 3.6 Failover Time Calculation Methods
The following Methods MAY be assessed on a per-flow basis using The following Methods may be assessed on a per-flow basis using
at least 16 flows spread over the routing table (more flows is at least 16 flows spread over the routing table (more flows is
better). Otherwise, the impact of a prefix-dependency in the better). Otherwise, the impact of a prefix-dependency in the
implementation of a particular protection technology could be implementation of a particular protection technology could be
missed. However, the test designer must be aware of the number missed. However, the test designer must be aware of the number
of packets per second sent to each prefix, as this establishes of packets per second sent to each prefix, as this establishes
sampling of the path and the time resolution for measurement sampling of the path and the time resolution for measurement
of Failover time on a per-flow basis. of Failover time on a per-flow basis.
3.6.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 on the Tester to measure the interval of Failover time scale on the Tester to measure the interval of Failover
Packet Loss. Packet Loss.
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 based on occurrence of packet loss on failure on a time scale based on occurrence of packet loss on
a time scale. This is indicated by the duration of non-zero a time scale. This is indicated by the duration of non-zero
packet loss. The TBLM includes failure detection time and packet loss. The TBLM includes failure detection time and
time for data traffic to begin traversing the Backup Path. time for data traffic to begin traversing the Backup Path.
Failover Time and Reversion Time are calculated using the Failover Time and Reversion Time are calculated using the
TBLM as shown in Equation 2: TBLM as shown in Equation 2:
(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)
Where as Time(Failover)= Time on the tester at the receipt of the
first unimpaired packet at egress node after the backup path
became the working path
Time(Failover Event)= Time on the tester at the receipt of the
last unimpaired packet at egress node on the primary path
before failure
Measurement units: Measurement units:
milliseconds milliseconds
Issues: Issues:
None None
Protection Performance
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
calculated using PLBM from the amount Failover Packet Loss as calculated using PLBM from the amount Failover Packet Loss as
shown below in Equation 3. Note: If traffic is sent to more than 1 shown below in Equation 3. Note: If traffic is sent to more than 1
skipping to change at page 25, line 53 skipping to change at page 26, line 56
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 based on the failure or reversion on a time scale based on the
observation of unimpaired packets, The TBM is calculated observation of unimpaired packets. The TBM is calculated
from Equation 2 with the values obtained from the timestamp from Equation 2 with the values obtained from the timestamp
in the packet payload, rather than from the Tester clock as in the packet payload, rather than from the Tester clock as
is used for the values when using the TBLM. is used for the values when using the TBLM.
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 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
skipping to change at page 26, line 58 skipping to change at page 28, line 5
management network. management network.
Further, benchmarking is performed on a "black-box" basis, relying Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT. solely on measurements observable external to the DUT/SUT.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production from the DUT/SUT SHOULD be identical in the lab and in production
networks. networks.
Protection Performance
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[2] Bradner, S., Editor, "Benchmarking Terminology for [2] Bradner, S., Editor, "Benchmarking Terminology for
Network Interconnection Devices", RFC 1242, July 1991. Network Interconnection Devices", RFC 1242, July 1991.
[3] Mandeville, R., "Benchmarking Terminology for LAN [3] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
Protection Performance
[4] Poretsky, S., et al., "Terminology for Benchmarking [4] Poretsky, S., et al., "Terminology for Benchmarking
Network-layer Traffic Control Mechanisms", RFC 4689, Network-layer Traffic Control Mechanisms", RFC 4689,
November 2006. November 2006.
[5] Bradner, S., "Key words for use in RFCs to Indicate [5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, July 1997. Requirement Levels", RFC 2119, July 1997.
[6] Not used. [6] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-21,
work in progress, May 2010.
[7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP [7] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-16, November 2006.
work in progress, October 2009.
[8] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP [8] Hinden, R., "Virtual Router Redundancy Protocol", RFC 5798,
March 2010.
7.2. Informative References
[9] 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 [10] Nichols, K., et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998. RFC 2474, December 1998.
[10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
November 2006.
[11] Hinden, R., "Virtual Router Redundancy Protocol", RFC 3768,
April 2004.
7.2. Informative References
None
8. Authors' Addresses 8. Authors' Addresses
Scott Poretsky Scott Poretsky
Allot Communications Allot Communications
67 South Bedford Street, Suite 400 67 South Bedford Street, Suite 400
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 508 309 2179 Phone: + 1 508 309 2179
Email: sporetsky@allot.com Email: sporetsky@allot.com
Protection Performance
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
Protection Performance
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
Samir Vapiwala Samir Vapiwala
 End of changes. 77 change blocks. 
118 lines changed or deleted 136 lines changed or added

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