draft-ietf-bmwg-protection-term-09.txt   rfc6414.txt 
Network Working Group S. Poretsky
Internet Draft Allot Communications
Expires: Jan 2011 Rajiv Papneja
Intended Status: Informational Isocore
J. Karthik
S. Vapiwala
Cisco Systems
July 2010
Benchmarking Terminology Internet Engineering Task Force (IETF) S. Poretsky
for Protection Performance Request for Comments: 6414 Allot Communications
<draft-ietf-bmwg-protection-term-09.txt > Category: Informational R. Papneja
ISSN: 2070-1721 Huawei
J. Karthik
S. Vapiwala
Cisco Systems
November 2011
Status of this Memo Benchmarking Terminology for Protection Performance
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Abstract
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document provides common terminology and metrics for
and may be updated, replaced, or obsoleted by other documents at any benchmarking the performance of sub-IP layer protection mechanisms.
time. It is inappropriate to use Internet-Drafts as reference The performance benchmarks are measured at the IP layer; protection
material or to cite them other than as "work in progress." may be provided at the sub-IP layer. The benchmarks and terminology
can be applied in methodology documents for different sub-IP layer
protection mechanisms such as Automatic Protection Switching (APS),
Virtual Router Redundancy Protocol (VRRP), Stateful High Availability
(HA), and Multiprotocol Label Switching Fast Reroute (MPLS-FRR).
The list of current Internet-Drafts can be accessed at Status of This Memo
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on 7 Jan, 2011. This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6414.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2011 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described include Simplified BSD License text as described in Section 4.e of
in Section 4.e of the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided without warranty as
without warranty as described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) Without obtaining an adequate license from the person(s) controlling
controlling the copyright in such materials, this document may not the copyright in such materials, this document may not be modified
be modified outside the IETF Standards Process, and derivative outside the IETF Standards Process, and derivative works of it may
works of it may not be created outside the IETF Standards Process, not be created outside the IETF Standards Process, except to format
except to format it for publication as an RFC or to translate it it for publication as an RFC or to translate it into languages other
into languages other than English. than English.
Protection Performance
Abstract Table of Contents
This document provides common terminology and metrics for benchmarking
the performance of sub-IP layer protection mechanisms. The performance
benchmarks are measured at the IP-Layer with protection may be
provided at the Sub-IP layer. The benchmarks and terminology can be
applied in methodology documents for different sub-IP layer protection
mechanisms such as Automatic Protection Switching (APS), Virtual Router
Redundancy Protocol (VRRP), Stateful High Availability (HA), and
Multi-Protocol Label Switching Fast Reroute (MPLS-FRR).
Protection Performance 1. Introduction ....................................................4
Table of Contents 1.1. Scope ......................................................4
1. Introduction..............................................3 1.2. General Model ..............................................5
2. Existing definitions......................................6 2. Existing Definitions ............................................8
3. Test Considerations.......................................7 3. Test Considerations .............................................9
3.1. Paths................................................7 3.1. Paths ......................................................9
3.1.1. Path............................................7 3.1.1. Path ................................................9
3.1.2. Working Path....................................8 3.1.2. Working Path .......................................10
3.1.3. Primary Path....................................8 3.1.3. Primary Path .......................................10
3.1.4. Protected Primary Path..........................8 3.1.4. Protected Primary Path .............................11
3.1.5. Backup Path.....................................9 3.1.5. Backup Path ........................................11
3.1.6. Standby Backup Path.............................10 3.1.6. Standby Backup Path ................................12
3.1.7. Dynamic Backup Path.............................10 3.1.7. Dynamic Backup Path ................................12
3.1.8. Disjoint Paths..................................10 3.1.8. Disjoint Paths .....................................13
3.1.9. Point of Local repair (PLR).....................11 3.1.9. Point of Local Repair (PLR) ........................13
3.1.10. Shared Risk Link Group (SRLG)..................11 3.1.10. Shared Risk Link Group (SRLG) .....................14
3.2. Protection Mechanisms................................12 3.2. Protection ................................................14
3.2.1. Link Protection.................................12 3.2.1. Link Protection ....................................14
3.2.2. Node Protection.................................12 3.2.2. Node Protection ....................................15
3.2.3. Path Protection.................................12 3.2.3. Path Protection ....................................15
3.2.4. Backup Span.....................................13 3.2.4. Backup Span ........................................16
3.2.5. Local Link Protection...........................13 3.2.5. Local Link Protection ..............................16
3.2.6. Redundant Node Protection.......................14 3.2.6. Redundant Node Protection ..........................17
3.2.7 State Control Interface.........................14 3.2.7. State Control Interface ............................17
3.2.8. Protected Interface.............................15 3.2.8. Protected Interface ................................18
3.3. Protection Switching.................................15 3.3. Protection Switching ......................................18
3.3.1. Protection Switching System.....................15 3.3.1. Protection-Switching System ........................18
3.3.2. Failover Event..................................15 3.3.2. Failover Event .....................................19
3.3.3. Failure Detection...............................16 3.3.3. Failure Detection ..................................19
3.3.4. Failover........................................17 3.3.4. Failover ...........................................20
3.3.5. Restoration.....................................17 3.3.5. Restoration ........................................20
3.3.6. Reversion.......................................18 3.3.6. Reversion ..........................................21
3.4. Nodes................................................18 3.4. Nodes .....................................................22
3.4.1. Protection-Switching Node.......................18 3.4.1. Protection-Switching Node ..........................22
3.4.2. Non-Protection Switching Node...................19 3.4.2. Non-Protection-Switching Node ......................22
3.4.3. Headend Node....................................19 3.4.3. Headend Node .......................................23
3.4.4. Backup Node.....................................19 3.4.4. Backup Node ........................................23
3.4.5. Merge Node......................................20 3.4.5. Merge Node .........................................24
3.4.6. Primary Node....................................20 3.4.6. Primary Node .......................................24
3.4.7. Standby Node....................................21 3.4.7. Standby Node .......................................25
3.5. Benchmarks...........................................21 3.5. Benchmarks ................................................26
3.5.1. Failover Packet Loss............................21 3.5.1. Failover Packet Loss ...............................26
3.5.2. Reversion Packet Loss...........................22 3.5.2. Reversion Packet Loss ..............................26
3.5.3. Failover Time...................................22 3.5.3. Failover Time ......................................27
3.5.4. Reversion Time..................................23 3.5.4. Reversion Time .....................................27
3.5.5. Additive Backup Delay...........................23 3.5.5. Additive Backup Delay ..............................28
3.6 Failover Time Calculation Methods.....................24 3.6. Failover Time Calculation Methods .........................28
3.6.1 Time-Based Loss Method...........................24 3.6.1. Time-Based Loss Method (TBLM) ......................29
3.6.2 Packet-Loss Based Method.........................25 3.6.2. Packet-Loss-Based Method (PLBM) ....................29
3.6.3 Timestamp-Based Method...........................25 3.6.3. Timestamp-Based Method (TBM) .......................30
4. Acknowledgments...........................................26 4. Security Considerations ........................................31
5. IANA Considerations.......................................26 5. References .....................................................32
6. Security Considerations...................................26 5.1. Normative References ......................................32
7. References................................................26 5.2. Informative References ....................................32
8. Authors' Addresses........................................27 6. Acknowledgments ................................................32
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 [6] are recognized connectivity and performance. Convergence Events [6] are recognized
at the IP Layer so that Route Convergence [6] 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) [8], 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) [9]. Multiprotocol Label Switching (MPLS-FRR) [9].
1.1 Scope 1.1. Scope
Benchmarking terminology was defined for IP-layer convergence in
[6]. Different terminology and methodologies specific to
benchmarking sub-IP layer protection mechanisms are required. The
metrics for benchmarking the performance of sub-IP protection
mechanisms are measured at the IP layer, so that the results are
always measured in reference to IP and independent of the specific
protection mechanism being used. The purpose of this document is
to provide a single terminology for benchmarking sub-IP protection
mechanisms.
A common terminology for Sub-IP layer protection mechanism Benchmarking terminology was defined for IP-layer convergence in [6].
Different terminology and methodologies specific to benchmarking sub-
IP layer protection mechanisms are required. The metrics for
benchmarking the performance of sub-IP protection mechanisms are
measured at the IP layer, so that the results are always measured in
reference to IP and independent of the specific protection mechanism
being used. The purpose of this document is to provide a single
terminology for benchmarking sub-IP protection mechanisms.
A common terminology for sub-IP layer protection mechanism
benchmarking enables different implementations of a protection benchmarking enables different implementations of a protection
mechanism to be benchmarked and evaluated. In addition, mechanism to be benchmarked and evaluated. In addition,
implementations of different protection mechanisms can be implementations of different protection mechanisms can be benchmarked
benchmarked and evaluated. It is intended that there can exist and evaluated. It is intended that there can exist unique
unique methodology documents for each sub-IP protection mechanism methodology documents for each sub-IP protection mechanism based upon
based upon this common terminology document. The terminology this common terminology document. The terminology can be applied to
can be applied to methodologies that benchmark sub-IP protection methodologies that benchmark sub-IP protection mechanism performance
mechanism performance with a single stream of traffic or with a single stream of traffic or multiple streams of traffic. The
multiple streams of traffic. The traffic flow may be traffic flow may be unidirectional or bidirectional as to be
uni-directional or bi-directional as to be indicated in the indicated in the methodology.
methodology.
1.2 General Model 1.2. General Model
The sequence of events to benchmark the performance of Sub-IP
Protection Mechanisms is as follows: The sequence of events to benchmark the performance of sub-IP
protection mechanisms 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. These terms are further defined in this document.
Protection Performance
Figures 1 through 5 show models that MAY be used when benchmarking Figures 1 through 5 show models that MAY be used when benchmarking
Sub-IP Protection mechanisms, which MUST use a Protection Switching sub-IP protection mechanisms, which MUST use a Protection-Switching
System that consists of a minimum of two Protection-Switching Nodes, System that consists of a minimum of two Protection-Switching Nodes,
an Ingress Node known as the Headend Node and an Egress Node known an Ingress Node known as the Headend Node and an Egress Node known as
as the Merge Node. The Protection Switching System MUST include the Merge Node. The Protection-Switching System MUST include either
either a Primary Path and Backup Path, as shown in Figures 1 through a Primary Path and Backup Path, as shown in Figures 1 through 4, or a
4, or a Primary Node and Standby Node, as shown in Figure 5. A Primary Node and Standby Node, as shown in Figure 5. A Protection-
Protection Switching System may provide link protection, node Switching System may provide link protection, node protection, path
protection, path protection, local link protection, and high protection, local link protection, and high availability, as shown in
availability, as shown in Figures 1 through 5 respectively. A Figures 1 through 5, respectively. A Failover Event occurs along the
Failover Event occurs along the Primary Path or at the Primary Node. Primary Path or at the Primary Node. The Working Path is the Primary
The Working Path is the Primary Path prior to the Failover Event and Path prior to the Failover Event and the Backup Path after the
the Backup Path after the Failover Event. A Tester is set outside Failover Event. A Tester is set outside the two paths or nodes as it
the two paths or nodes as it sends and receives IP traffic along the sends and receives IP traffic along the Working Path. The tester
Working Path. The tester MUST record the IP packet sequence numbers, MUST record the IP packet sequence numbers, departure time, and
departure time, and arrival time so that the metrics of Failover arrival time so that the metrics of Failover Time, Additive Latency,
Time, Additive Latency, Packet Reordering, Duplicate Packets, and Packet Reordering, Duplicate Packets, and Reversion Time can be
Reversion Time can be measured. The Tester may be a single device measured. The Tester may be a single device or a test system. If
or a test system. If Reversion is supported then the Working Path is Reversion is supported, then the Working Path is the Primary Path
the Primary Path after Restoration (Failure Recovery) of the Primary after Restoration (Failure Recovery) of the Primary Path.
Path.
Link Protection, as shown in Figure 1, provides protection when a Link Protection, as shown in Figure 1, provides protection when a
Failover Event occurs on the link between two nodes along the Primary Failover Event occurs on the link between two nodes along the Primary
Path. Node Protection, as shown in Figure 2, provides protection Path. Node Protection, as shown in Figure 2, provides protection
when a Failover Event occurs at a Node along the Primary Path. when a Failover Event occurs at a Node along the Primary Path. Path
Path Protection, as shown in Figure 3, provides protection for link Protection, as shown in Figure 3, provides protection for link or
or node failures for multiple hops along the Primary Path. Local node failures for multiple hops along the Primary Path. Local Link
Link Protection, as shown in Figure 4, provides Sub-IP Protection of Protection, as shown in Figure 4, provides sub-IP protection of a
a link between two nodes, without a Backup Node. An example of such link between two nodes, without a Backup Node. An example of such a
a Sub-IP Protection mechanism is SONET APS. High Availability sub-IP protection mechanism is SONET APS. High Availability
Protection, as shown in Figure 5, provides protection of a Primary Protection, as shown in Figure 5, provides protection of a Primary
Node with a redundant Standby Node. State Control is provided Node with a redundant Standby Node. State Control is provided
between the Primary and Standby Nodes. Failure of the Primary Node 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 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 Standby Node, which has state maintained for zero or minimal packet
loss. loss.
+-----------+ +-----------+
+--------------| Tester |<-----------------------+ +--------------| Tester |<-----------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| ------------ | ---------- | | ------------ | ---------- |
+--->| Ingress/ | V | Egress/ |---+ +--->| Ingress/ | V | Egress/ |---+
|Headend Node|------------------|Merge Node| Primary |Headend Node|------------------|Merge Node| Primary
------------ ---------- Path ------------ ---------- Path
| ^ | ^
| --------- | Backup | --------- | Backup
+--------| Backup |-------------+ Path +--------| Backup |-------------+ Path
| Node | | Node |
--------- ---------
Figure 1. System Under Test (SUT) for Sub-IP Link Protection
Protection Performance Figure 1. System Under Test (SUT) for Sub-IP Link Protection
+-----------+ +-----------+
+--------------------| Tester |<-----------------+ +--------------------| Tester |<-----------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| V | | V |
| ------------ -------- ---------- | | ------------ -------- ---------- |
+--->| Ingress/ | |MidPoint| | Egress/ |---+ +--->| Ingress/ | |Midpoint| | Egress/ |---+
|Headend Node|----| Node |----|Merge Node| Primary |Headend Node|----| Node |----|Merge Node| Primary
------------ -------- ---------- Path ------------ -------- ---------- Path
| ^ | ^
| --------- | Backup | --------- | Backup
+--------| Backup |-------------+ Path +--------| Backup |-------------+ Path
| Node | | Node |
--------- ---------
Figure 2. System Under Test (SUT) for Sub-IP Node Protection Figure 2. System Under Test (SUT) for Sub-IP Node Protection
+-----------+
+-----------+
+---------------------------| Tester |<----------------------+ +---------------------------| Tester |<----------------------+
| +-----------+ | | +-----------+ |
| IP Traffic | Failover IP Traffic | | IP Traffic | Failover IP Traffic |
| | Event | | | Event |
| Primary Path | | | Primary Path | |
| ------------ -------- | -------- ---------- | | ------------ -------- | -------- ---------- |
+--->| Ingress/ | |MidPoint| V |Midpoint| | Egress/ |---+ +--->| Ingress/ | |Midpoint| V |Midpoint| | Egress/ |---+
|Headend Node|----| Node |---| Node |---|Merge Node| |Headend Node|----| Node |---| Node |---|Merge Node|
------------ -------- -------- ---------- ------------ -------- -------- ----------
| ^ | ^
| --------- -------- | Backup | --------- -------- | Backup
+--------| Backup |----| Backup |--------+ Path +--------| Backup |----| Backup |--------+ Path
| Node | | Node | | Node | | Node |
--------- -------- --------- --------
Figure 3. System Under Test (SUT) for Sub-IP Path Protection 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 +--------+ |
| | |------------------------>| | | | | |------------------------>| | |
+--->| 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 +-----------+
+-----------------| 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)
+-----------------| Tester |<--------------------+ for Sub-IP Redundant Node Protection
| +-----------+ |
| 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 Some protection-switching technologies may use a series of steps that
differ from the general model. The specific differences SHOULD be
highlighted in each technology-specific methodology. Note that some
protection-switching technologies are endowed with the ability to re-
optimize the working path after a node or link failure.
Some protection switching technologies may use a series of 2. Existing Definitions
steps that differ from the general model. The specific differences
SHOULD be highlighted in each technology-specific methodology.
Note that some protection switching technologies are endowed
with the ability to re-optimize the working path after a
node or link failure.
2. Existing definitions This document uses existing terminology defined in other BMWG work.
This document uses existing terminology defined in other BMWG Examples include, but are not limited to:
work. Examples include, but are not limited to:
Latency [Ref.[2], section 3.8] Latency [2], Section 3.8
Frame Loss Rate [Ref.[2], section 3.6] Frame Loss Rate [2], Section 3.6
Throughput [Ref.[2], section 3.17] Throughput [2], Section 3.17
Device Under Test (DUT) [Ref.[3], section 3.1.1] Device Under Test (DUT) [3], Section 3.1.1
System Under Test (SUT) [Ref.[3], section 3.1.2] System Under Test (SUT) [3], Section 3.1.2
Offered Load [Ref.[3], section 3.5.2] Offered Load [3], Section 3.5.2
Out-of-order Packet [Ref.[4], section 3.3.2] Out-of-order Packet [4], Section 3.3.4
Duplicate Packet [Ref.[4], section 3.3.3] Duplicate Packet [4], Section 3.3.5
Forwarding Delay [Ref.[4], section 3.2.4] Forwarding Delay [4], Section 3.2.4
Jitter [Ref.[4], section 3.2.5] Jitter [4], Section 3.2.5
Packet Loss [Ref.[6], Section 3.5] Packet Loss [6], Section 3.5
Packet Reordering [Ref.[7], section 3.3] Packet Reordering [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
within this document. this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [5]. document are to be interpreted as described in BCP 14, RFC 2119 [5].
RFC 2119 defines the use of these keywords to help make the intent of
Standards Track documents as clear as possible. While this document
uses these keywords, this document is not a Standards Track document.
Protection Performance 3. Test Considerations
RFC 2119 defines the use of these key words to help make the 3.1. Paths
intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track
document.
3. Test Considerations 3.1.1. Path
3.1. Paths Definition:
A unidirectional sequence of nodes <R1, ..., Rn> and links
<L12,... L(n-1)n> with the following properties:
3.1.1 Path a. R1 is the ingress node and forwards IP packets, which input
into DUT/SUT, to R2 as sub-IP frames over link L12.
Definition: b. Ri is a node which forwards data frames to R(i+1) over Link
A unidirectional sequence of nodes, <R1, ..., Rn>, and links Li(i+1) for all i, 1<i<n-1, based on information in the sub-IP
<L12,... L(n-1)n> with the following properties: layer.
a. R1 is the ingress node and forwards IP packets, which input c. Rn is the egress node, and it outputs sub-IP frames from
into DUT/SUT, to R2 as sub-IP frames over link L12. DUT/SUT as IP packets. L(n-1)n is the link between the R(n-1)
and Rn.
b. Ri is a node which forwards data frames to R(i+1) over Link Discussion:
Li(i+1) for all i, 1<i<n-1, based on information in the sub-IP The path is defined in the sub-IP layer in this document, unlike
layer. 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.
The two IP nodes may have multiple paths for protection. A packet
will travel on only one path between the nodes. Packets belonging
to a microflow [10] will traverse one or more paths. The path is
unidirectional. For example, the link between R1 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. Example paths
are the SONET/SDH path and the label switched path for MPLS.
c. Rn is the egress node and it outputs sub-IP frames from Measurement Units:
DUT/SUT as IP packets. L(n-1)n is the link between the R(n-1) n/a
and Rn.
Discussion: Issues:
The path is defined in the sub-IP layer in this document, unlike "A bidirectional path", which transmits traffic in both directions
an IP path in RFC 2026 [1]. One path may be regarded as being along the same nodes, consists of two unidirectional paths.
equivalent to one IP link between two IP nodes, i.e., R1 and Rn. Therefore, the two unidirectional paths belonging to "one
The two IP nodes may have multiple paths for protection. A bidirectional path" will be treated independently when
packet will travel on only one path between the nodes. Packets benchmarking for "a bidirectional path".
belonging to a microflow [10] will traverse one or more paths.
The path is unidirectional. For example, the link between R1
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.
Example paths are the SONET/SDH path and the label switched path
for MPLS.
Measurement units: See Also:
n/a Working Path
Primary Path
Backup Path
Issues: 3.1.2. Working Path
"A bidirectional path", which transmits traffic in both
directions along the same nodes, consists of two unidirectional
paths. Therefore, the two unidirectional paths belonging to
"one bidirectional path" will be treated independently when
benchmarking for "a bidirectional path".
See Also: Definition:
Working Path The path that the DUT/SUT is currently using to forward packets.
Primary Path
Backup Path
Protection Performance
3.1.2. Working Path Discussion:
A Primary Path is the Working Path before occurrence of a Failover
Event. A Backup Path shall become the Working Path after a
Failover Event.
Definition: Measurement Units:
The path that the DUT/SUT is currently using to forward n/a
packets.
Discussion: Issues:
A Primary Path is the Working Path before occurrence of a None.
Failover Event. A Backup Path shall become the Working Path
after a Failover Event.
Measurement units: See Also:
n/a Path
Primary Path
Backup Path
Issues: 3.1.3. Primary Path
See Also: Definition:
Path The preferred point-to-point path for forwarding traffic between
Primary Path two or more nodes.
Backup Path
3.1.3. Primary Path Discussion:
The Primary Path is the Path that traffic traverses prior to a
Failover Event.
Definition: Measurement Units:
The preferred point to point path for forwarding traffic n/a
between two or more nodes.
Discussion: Issues:
The Primary Path is the Path that traffic traverses None.
prior to a Failover Event.
Measurement units: See Also:
n/a Path
Failover Event
Issues: 3.1.4. Protected Primary Path
None
See Also: Definition:
Path A Primary Path that is protected with a Backup Path.
Failover Event
3.1.4. Protected Primary Path Discussion:
A Protected Primary Path must include at least one Protection-
Switching Node.
Definition: Measurement Units:
A Primary Path that is protected with a Backup Path. n/a
Discussion: Issues:
A Protected Primary Path must include at least one Protection None.
Switching Node.
Protection Performance See Also:
Path
Primary Path
Measurement units: 3.1.5. Backup Path
n/a
Issues: None Definition:
A path that exists to carry data traffic only if a Failover Event
occurs on a Primary Path.
See Also: Discussion:
Path The Backup Path shall become the Working Path upon a Failover
Primary Path Event. A Path may have one or more Backup Paths. A Backup Path
may protect one or more Primary Paths. There are various types of
Backup Paths:
3.1.5. Backup Path a. dedicated recovery Backup Path (1+1) or (1:1), which has 100%
redundancy for a specific ordinary path
Definition: b. shared Backup Path (1:N), which is dedicated to the protection
A path that exists to carry data traffic only if a Failover for more than one specific Primary Path
Event occurs on a Primary Path.
Discussion: c. associated shared Backup Path (M:N) for which a specific set of
The Backup Path shall become the Working Path upon a Failover Backup Paths protects a specific set of more than one Primary
Event. A Path may have one or more Backup Paths. A Backup Path
Path may protect one or more Primary Paths. There are various
types of Backup Paths:
a. dedicated recovery Backup Path (1+1) or (1:1), which has A Backup Path may be signaled or unsignaled. The Backup Path must
100% redundancy for a specific ordinary path, be created prior to the Failover Event. The Backup Path generally
originates at the point of local repair (PLR) and terminates at a
node along a primary path.
b. shared Backup Path (1:N), which is dedicated to the Measurement Units:
protection for more than one specific Primary Path n/a
c. associated shared Backup Path (M:N) for which a specific Issues:
set of Backup Paths protects a specific set of more than one None.
Primary Path.
A Backup Path may be signaled or unsignaled. The Backup Path See Also:
must be created prior to the Failover Event. The backup path Path
generally originates at the point of local repair (PLR), and Working Path
terminates at a node along a primary path. Primary Path
Measurement units: 3.1.6. Standby Backup Path
n/a
Issues: Definition:
A Backup Path that is established prior to a Failover Event to
protect a Primary Path.
See Also: Discussion:
Path The Standby Backup Path and Dynamic Backup Path provide
Working Path protection, but are established at different times.
Primary Path
Protection Performance
3.1.6. Standby Backup Path Measurement Units:
n/a
Definition: Issues:
A Backup Path that is established prior to a Failover Event None.
to protect a Primary Path.
Discussion: See Also:
The Standby Backup Path and Dynamic Backup Path provide Backup Path
protection, but are established at different times. Primary Path
Failover Event
Measurement units: n/a 3.1.7. Dynamic Backup Path
Issues: None Definition:
A Backup Path that is established upon occurrence of a Failover
Event.
See Also: Discussion:
Backup Path The Standby Backup Path and Dynamic Backup Path provide
Primary Path protection, but are established at different times.
Failover Event
3.1.7. Dynamic Backup Path Measurement Units:
n/a
Definition: Issues:
A Backup Path that is established upon occurrence of a None.
Failover Event.
Discussion: See Also:
The Standby Backup Path and Dynamic Backup Path provide Backup Path
protection, but are established at different times. Standby Backup Path
Failover Event
Measurement units: n/a 3.1.8. Disjoint Paths
Issues: None Definition:
A pair of paths that do not share a common link or nodes.
See Also: Discussion:
Backup Path Two paths are disjoint if they do not share a common node or link
Standby Backup Path other than the ingress and egress.
Failover Event
3.1.8. Disjoint Paths Measurement Units:
n/a
Definition: Issues:
A pair of paths that do not share a common link or nodes. None.
Discussion: See Also:
Two paths are disjoint if they do not share a common node or link Path
other than the ingress and egress. Primary Path
SRLG
Protection Performance 3.1.9. Point of Local Repair (PLR)
Measurement units: n/a Definition:
A node capable of Failover along the Primary Path that is also the
ingress node for the Backup Path to protect another node or link.
Issues: None Discussion:
Any node along the Primary Path from the ingress node to the
penultimate node may be a PLR. The PLR may use a single Backup
Path for protecting one or more Primary Paths. There can be
multiple PLRs along a Primary Path. The PLR must be an ingress to
a Backup Path. The PLR can be any node along the Primary Path
except the egress node of the Primary Path. The PLR may
simultaneously be a Headend Node when it is serving the role as
ingress to the Primary Path and the Backup Path. If the PLR is
also the Headend Node, then the Backup Path is a Disjoint Path
from the ingress to the Merge Node.
See Also: Measurement Units:
Path n/a
Primary Path
SRLG
3.1.9. Point of Local Repair (PLR) Issues:
Definition: None.
A node capable of Failover along the Primary Path that is
also the ingress node for the Backup Path to protect another
node or link.
Discussion: See Also:
Any node along the Primary Path from the ingress node to Primary Path
the penultimate node may be a PLR. The PLR may use Backup Path
a single Backup Path for protecting one or more Primary Failover
Paths. There can be multiple PLRs along a Primary Path.
The PLR must be an ingress to a Backup Path. The PLR can
be any node along the Primary Path except the egress node
of the Primary Path. The PLR may simultaneously be a
Headend Node when it is serving the role as ingress to
the Primary Path and the Backup Path. If the PLR is
also the Headend Node, then the Backup Path is a Disjoint
Path from the ingress to the Merge Node.
Measurement units: n/a 3.1.10. Shared Risk Link Group (SRLG)
Issues: None Definition:
SRLG is a set of links that share the same risk (physical or
logical) within a network.
See Also: Discussion:
Primary Path SRLG is considered the set of links to be avoided when the primary
Backup Path and secondary paths are considered disjoint. The SRLG will fail
Failover as a group if the shared resource (physical or anything abstract
such as software version) fails.
3.1.10. Shared Risk Link Group (SRLG) Measurement Units:
Definition: n/a
SRLG is a set of links which share the same risk (physical
or logical) within a network.
Discussion: Issues:
SRLG is considered the set of links to be avoided when None.
the primary and secondary paths are considered disjoint.
The SRLG will fail as a group if the shared resource
(physical or anything abstract such as software version)
fails.
Measurement units: n/a See Also:
Path Primary Path
Issues: None 3.2. Protection
See Also: 3.2.1. Link Protection
Path
Primary Path
Protection Performance
3.2. Protection Definition:
3.2.1. Link Protection A Backup Path that is signaled to at least one Backup Node to
Definition: protect for failure of interfaces and links along a Primary Path.
A Backup Path that is signaled to at least one Backup Node
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. 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.2. Node Protection 3.2.2. Node Protection
Definition:
A Backup Path that is signaled to at least one Backup Node
to protect for failure of interfaces, links, and nodes
along a Primary Path.
Discussion: Definition:
Node Protection may or may not protect the entire Primary A Backup Path that is signaled to at least one Backup Node to
Path. Node Protection also provides Link Protection. protect for failure of interfaces, links, and nodes along a
Node Protection is shown in Figure 2. Primary Path.
Measurement units: n/a Discussion:
Node Protection may or may not protect the entire Primary Path.
Node Protection also provides Link Protection. Node Protection is
shown in Figure 2.
Issues: None Measurement Units:
n/a
See Also: Issues:
Link Protection None.
3.2.3. Path Protection See Also:
Definition: Link Protection
A Backup Path that is signaled to at least one Backup Node
to provide protection along the entire Primary Path.
Discussion: 3.2.3. Path Protection
Path Protection provides Node Protection and Link Protection
for every node and link along the Primary Path. A Backup
Path providing Path Protection may have the same ingress
node as the Primary Path. Path Protection is shown in
Figure 3.
Measurement units: n/a Definition:
A Backup Path that is signaled to at least one Backup Node to
provide protection along the entire Primary Path.
Issues: None Discussion:
Protection Performance Path Protection provides Node Protection and Link Protection for
every node and link along the Primary Path. A Backup Path
providing Path Protection may have the same ingress node as the
Primary Path. Path Protection is shown in Figure 3.
See Also: Measurement Units:
Primary Path n/a
Backup Path
Node Protection
Link protection
3.2.4. Backup Span Issues:
None.
Definition: See Also:
The number of hops used by a Backup Path. Primary Path
Backup Path
Node Protection
Link Protection
Discussion: 3.2.4. Backup Span
The Backup Span is an integer obtained by counting the
number of nodes along the Backup Path.
Measurement units: Definition:
number of nodes The number of hops used by a Backup Path.
Issues: Discussion:
None The Backup Span is an integer obtained by counting the number of
nodes along the Backup Path.
See Also: Measurement Units:
Primary Path number of nodes
Backup Path
3.2.5. Local Link Protection Issues:
None.
Definition: See Also:
A Backup Path that is a redundant path between two nodes Primary Path
which does not use a Backup Node. Backup Path
Discussion: 3.2.5. Local Link Protection
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 Definition:
A Backup Path that is a redundant path between two nodes and does
not use a Backup Node.
Issues: None 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.
See Also: Measurement Units:
Backup Path n/a
Backup Node
Protection Performance
3.2.6. Redundant Node Protection Issues:
None.
Definition: See Also:
A Protection Switching System with a Primary Node Backup Path
protected by a Standby Node along the Primary Path. Backup Node
Discussion: 3.2.6. Redundant Node Protection
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 Definition:
A Protection-Switching System with a Primary Node protected by a
Standby Node along the Primary Path.
Issues: None 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.
See Also: Measurement Units:
Primary Path n/a
Primary Node
Standby Node
3.2.7. State Control Interface Issues:
None.
Definition: See Also:
An out-of-band control interface used to exchange state Primary Path
information between the Primary Node and Standby Node. Primary Node
Standby Node
Discussion: 3.2.7. State Control Interface
The State Control Interface may be used for Redundant Node
Protection. The State Control Interface should 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 Definition:
An out-of-band control interface used to exchange state
information between the Primary Node and Standby Node.
Issues: None Discussion:
The State Control Interface may be used for Redundant Node
Protection. The State Control Interface should 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.
See Also: Measurement Units:
Primary Node n/a
Standby Node
Protection Performance
3.2.8. Protected Interface Issues:
None.
Definition: See Also:
An interface along the Primary Path that is protected by Primary Node
a Backup Path. Standby Node
Discussion: 3.2.8. Protected Interface
A Protected Interface is an interface protected by a
Protection Switching System that provides Link
Protection, Node Protection, Path Protection, Local
Link Protection, and Redundant Node Protection.
Measurement units: None Definition:
An interface along the Primary Path that is protected by a Backup
Path.
Issues: None Discussion:
A Protected Interface is an interface protected by a Protection-
Switching System that provides Link Protection, Node Protection,
Path Protection, Local Link Protection, and Redundant Node
Protection.
See Also: Measurement Units:
Primary Path n/a
Backup Path
3.3. Protection Switching Issues:
None.
3.3.1. Protection Switching System See Also:
Primary Path
Backup Path
Definition: 3.3. Protection Switching
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: 3.3.1. Protection-Switching System
The Protection Switching System must include either a
Primary Path and Backup Path, as shown in Figures 1 through
4, or a Primary Node and Standby Node, as shown in Figure
5. 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 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.
Issues: None Discussion:
The Protection-Switching System must include either a Primary Path
and Backup Path, as shown in Figures 1 through 4, or a Primary
Node and Standby Node, as shown in Figure 5. 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.
See Also: Measurement Units:
Primary Path n/a
Backup Path
Failover
3.3.2. Failover Event Issues:
None.
Definition: See Also:
The occurrence of a planned or unplanned action in the network Primary Path Backup Path Failover
that results in a change in the Path that data traffic traverses.
Protection Performance 3.3.2. Failover Event
Discussion: Definition:
Failover Events include, but are not limited to, link failure The occurrence of a planned or unplanned action in the network
and router failure. Routing changes are considered Convergence that results in a change in the Path that data traffic traverses.
Events [6] and are not Failover Events. This restricts
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
generally on a disjoint path from the ingress to egress.
Failover Events may results from failures such as link failure Discussion:
or router failure. The change in path after Failover may have Failover Events include, but are not limited to, link failure and
a Backup Span of one or more nodes. Failover Events are router failure. Routing changes are considered Convergence Events
distinguished from routing changes and Convergence Events [6] [6] and are not Failover Events. This restricts Failover Events
by the detection of the failure and subsequent protection to sub-IP layers. Failover may be at the PLR or at the ingress.
switching at a sub-IP layer. Failover occurs at a Point of If the failover is at the ingress, it is generally on a disjoint
Local Repair (PLR) or Primary Node. path from the ingress to egress.
Measurement units: Failover Events may result from failures such as link failure or
n/a 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 [6] by
the detection of the failure and subsequent protection switching
at a sub-IP layer. Failover occurs at a PLR or Primary Node.
Issues: None Measurement Units:
n/a
See Also: Issues:
Path None.
Failure Detection
Disjoint Path
3.3.3. Failure Detection See Also:
Path
Failure Detection
Disjoint Path
Definition: 3.3.3. Failure Detection
The process to identify at a sub-IP layer a Failover Event
at a Primary Node or along the Primary Path.
Discussion: Definition:
Failure Detection occurs at the Primary Node or ingress node The process to identify at a sub-IP layer a Failover Event at a
of the Primary Path. Failure Detection occurs via a sub-IP Primary Node or along the Primary Path.
mechanism such as detection of a link down event or timeout for
receipt of a control packet. A failure may be completely
isolated. A failure may affect a set of links which share a
single SRLG (e.g. port with many sub-interfaces). A failure may
affect multiple links that are not part of SRLG.
Measurement units: n/a Discussion:
Failure Detection occurs at the Primary Node or ingress node of
the Primary Path. Failure Detection occurs via a sub-IP mechanism
such as detection of a link down event or timeout for receipt of a
control packet. A failure may be completely isolated. A failure
may affect a set of links that share a single SRLG (e.g., port
with many sub-interfaces). A failure may affect multiple links
that are not part of the SRLG.
Issues: Measurement Units:
n/a
See Also: Issues:
Primary Path None.
Protection Performance
3.3.4. Failover See Also:
Primary Path
Definition: 3.3.4. Failover
The process to switch data traffic from the protected Primary
Path to the Backup Path upon Failure Detection of a Failover
Event.
Discussion: Definition:
Failover to a Backup Path provides Link Protection, Node The process to switch data traffic from the protected Primary Path
Protection, or Path Protection. Failover is complete when to the Backup Path upon Failure Detection of a Failover Event.
Packet Loss [6], Out-of-order Packets [4], and Duplicate
Packets [4] are no longer observed. Forwarding Delay [4]
may continue to be observed.
Measurement units: Discussion:
n/a Failover to a Backup Path provides Link Protection, Node
Protection, or Path Protection. Failover is complete when Packet
Loss [6], Out-of-order Packets [4], and Duplicate Packets [4] are
no longer observed. Forwarding Delay [4] may continue to be
observed.
Issues: Measurement Units:
n/a
See Also: Issues:
Primary Path None.
Backup Path
Failover Event
3.3.5. Restoration See Also:
Primary Path Backup Path Failover Event
Definition: 3.3.5. Restoration
The state of failover recovery in which the Primary Path
has recovered from a Failover Event, but is not yet
forwarding packets because the Backup Path remains the
Working Path.
Discussion: Definition:
Restoration must occur while the Backup Path is the The state of failover recovery in which the Primary Path has
Working Path. The Backup Path is maintained as the recovered from a Failover Event, but is not yet forwarding packets
Working Path during Restoration. Restoration produces because the Backup Path remains the Working Path.
a Primary Path that is recovered from failure, but is
not yet forwarding traffic. Traffic is still being
forwarded by the Backup Path functioning as the Working
Path.
Measurement units: Discussion:
n/a Restoration must occur while the Backup Path is the Working Path.
The Backup Path is maintained as the Working Path during
Restoration. Restoration produces a Primary Path that is
recovered from failure, but is not yet forwarding traffic.
Traffic is still being forwarded by the Backup Path functioning as
the Working Path.
Issues: Measurement Units:
n/a
See Also: Issues:
Primary Path None.
Failover Event
Failure Recovery
Working Path
Backup Path
Protection Performance
3.3.6. Reversion See Also:
Primary Path
Failover Event
Failure Recovery
Working Path
Backup Path
Definition: 3.3.6. Reversion
The state of failover recovery in which the Primary Path has
become the Working Path so that it is forwarding packets.
Discussion: Definition:
Protection Switching Systems may or may not support Reversion. The state of failover recovery in which the Primary Path has
Reversion, if supported, must occur after Restoration. become the Working Path so that it is forwarding packets.
Packet forwarding on the Primary Path resulting from Reversion
may occur either fully or partially over the Primary Path. A
potential problem with Reversion is the discontinuity in end to
end delay when the Forwarding Delays [4] along the Primary Path
and Backup Path are different, possibly causing Out of Order
Packets [4], Duplicate Packets [4], and increased Jitter [4].
Measurement units: n/a Discussion:
Protection-Switching Systems may or may not support Reversion.
Reversion, if supported, must occur after Restoration. Packet
forwarding on the Primary Path resulting from Reversion may occur
either fully or partially over the Primary Path. A potential
problem with Reversion is the discontinuity in end-to-end delay
when the Forwarding Delays [4] along the Primary Path and Backup
Path are different, possibly causing Out-of-order Packets [4],
Duplicate Packets [4], and increased Jitter [4].
Issues: None Measurement Units:
n/a
See Also: Issues:
Protection Switching System None.
Working Path
Primary Path
3.4. Nodes See Also:
Protection-Switching System
Working Path
Primary Path
3.4.1. Protection-Switching Node 3.4. Nodes
Definition: 3.4.1. Protection-Switching Node
A node that is capable of participating in a Protection
Switching System.
Discussion: Definition:
The Protection Switching Node may be an ingress or egress for A node that is capable of participating in a Protection Switching
a Primary Path or Backup Path, such as used for MPLS Fast System.
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: Discussion:
n/a The Protection-Switching Node may be an ingress or egress for 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.
Issues: Measurement Units:
n/a
See Also: Issues:
Protection Switching System None.
Protection Performance
3.4.2. Non-Protection Switching Node See Also:
Protection-Switching System
Definition: 3.4.2. Non-Protection-Switching Node
A node that is not capable of participating in a Protection
Switching System, but may exist along the Primary Path or
Backup Path.
Discussion: Definition:
A node that is not capable of participating in a Protection
Switching System, but may exist along the Primary Path or Backup
Path.
Measurement units: Discussion:
n/a None.
Issues: Measurement Units:
n/a
See Also: Issues:
Protection Switching System None.
Primary Path
Backup Path
3.4.3. Headend Node See Also:
Definition: Protection-Switching System
The ingress node of the Primary Path. Primary Path
Backup Path
Discussion: 3.4.3. Headend Node
The Headend Node may also be a PLR when it is serving in
the dual role as the ingress to the Backup Path.
Measurement units: n/a Definition:
The ingress node of the Primary Path.
Issues: Discussion:
The Headend Node may also be a PLR when it is serving in the dual
role as the ingress to the Backup Path.
See Also: Measurement Units:
Primary Path n/a
Point of Local Repair (PLR)
Failover
3.4.4. Backup Node Issues:
Definition: None.
A node along the Backup Path.
Discussion: See Also:
The Backup Node can be any node along the Backup Path. Primary Path
There may be one or more Backup Nodes along the Backup Path. PLR
A Backup Node may be the ingress, mid-point, or egress of Failover
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 3.4.4. Backup Node
Measurement units: n/a Definition:
A node along the Backup Path.
Issues: 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, midpoint, 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.
See Also: Measurement Units:
Backup Path n/a
3.4.5. Merge Node Issues:
Definition: None.
A node along the Primary Path where Backup Path terminates.
Discussion: See Also:
The Merge Node can be any node along the Primary Path Backup Path
except the ingress node of the Primary Path. There can be
multiple Merge Nodes along a Primary Path. A Merge Node
can be the egress node for a single or multiple Backup
Paths. The Merge Node must be the egress to the Backup
Path. The Merge Node may also be the egress of the
Primary Path or Point of Local Repair (PLR).
Measurement units: 3.4.5. Merge Node
n/a
Issues: Definition:
A node along the Primary Path where Backup Path terminates.
See Also: Discussion:
Primary Path The Merge Node can be any node along the Primary Path except the
Backup Path ingress node of the Primary Path. There can be multiple Merge
PLR Nodes along a Primary Path. A Merge Node can be the egress node
Failover for a single Backup Path or multiple Backup Paths. The Merge Node
must be the egress to the Backup Path. The Merge Node may also be
the egress of the Primary Path or Point of Local Repair (PLR).
3.4.6. Primary Node Measurement Units:
n/a
Definition: Issues:
A node along the Primary Path that is capable of Failover to a None.
redundant Standby Node.
Discussion: See Also:
The Primary Node may be used for Protection Switching Systems Primary Path
that provide Redundant Node Protection, such as VRRP and HA Backup Path
PLR
Failover
Measurement units: n/a 3.4.6. Primary Node
Issues: Definition:
A node along the Primary Path that is capable of Failover to a
redundant Standby Node.
See Also: Discussion:
Protection Switching System The Primary Node may be used for Protection-Switching Systems that
Redundant Node Protection provide Redundant Node Protection, such as VRRP and HA.
Standby Node
Protection Performance
3.4.7. Standby Node Measurement Units:
n/a
Definition: Issues:
A redundant node to a Primary Node that forwards traffic along None.
the Primary Path upon Failure Detection of the Primary Node.
Discussion: See Also:
The Standby Node must be used for Protection Switching Protection-Switching System Redundant Node Protection Standby Node
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 3.4.7. 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 Definition:
Node is not offered traffic and does not forward traffic until A redundant node to a Primary Node; it forwards traffic along the
Failure Detection of the Primary Node. Upon Failure Detection Primary Path upon Failure Detection of the Primary Node.
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 Discussion:
The Standby Node must be used for Protection-Switching 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.
Issues: 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.
See Also: The Standby Node may be passive or active. The Passive Standby
Primary Node Node is not offered traffic and does not forward traffic until
State Control Interface 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.
3.5. Benchmarks Measurement Units:
n/a
3.5.1. Failover Packet Loss Issues:
Definition: None.
The amount of packet loss produced by a Failover Event until
Failover completes, where the measurement begins when the last
unimpaired packet is received by the Tester on the Protected
Primary Path and ends when the first unimpaired packet is
received by the Tester on the Backup Path.
Protection Performance See Also:
Primary Node
State Control Interface
Discussion: 3.5. Benchmarks
Packet loss can be observed as a reduction of forwarded
traffic from the maximum forwarding rate. Failover Packet
Loss includes packets that were lost, reordered, or delayed.
Failover Packet Loss may reach 100% of the offered load.
Measurement units: 3.5.1. Failover Packet Loss
Number of Packets
Issues: None Definition:
The amount of packet loss produced by a Failover Event until
Failover completes, where the measurement begins when the last
unimpaired packet is received by the Tester on the Protected
Primary Path and ends when the first unimpaired packet is received
by the Tester on the Backup Path.
See Also: Discussion:
Failover Event Packet loss can be observed as a reduction of forwarded traffic
Failover from the maximum forwarding rate. Failover Packet Loss includes
packets that were lost, reordered, or delayed. Failover Packet
Loss may reach 100% of the offered load.
3.5.2. Reversion Packet Loss Measurement Units:
Number of Packets
Definition: Issues:
The amount of packet loss produced by Reversion, where the None.
measurement begins when the last unimpaired packet is received
by the Tester on the Backup Path and ends when the first
unimpaired packet is received by the Tester on the Protected
Primary Path .
Discussion: See Also:
Packet loss can be observed as a reduction of forwarded Failover Event
traffic from the maximum forwarding rate. Reversion Packet Failover
Loss includes packets that were lost, reordered, or delayed.
Reversion Packet Loss may reach 100% of the offered load.
Measurement units: Number of Packets 3.5.2. Reversion Packet Loss
Issues: None Definition:
The amount of packet loss produced by Reversion, where the
measurement begins when the last unimpaired packet is received by
the Tester on the Backup Path and ends when the first unimpaired
packet is received by the Tester on the Protected Primary Path.
See Also: Discussion:
Reversion Packet loss can be observed as a reduction of forwarded traffic
from the maximum forwarding rate. Reversion Packet Loss includes
packets that were lost, reordered, or delayed. Reversion Packet
Loss may reach 100% of the offered load.
3.5.3. Failover Time Measurement Units:
Number of Packets
Definition: Issues:
The amount of time it takes for Failover to successfully None.
complete.
Discussion: See Also:
Failover Time can be calculated using the Time-Based Loss Reversion
Method (TBLM), Packet-Loss Based Method (PLBM), or
Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
Protection Performance 3.5.3. Failover Time
Measurement units: Definition:
milliseconds The amount of time it takes for Failover to successfully complete.
Issues: None Discussion:
Failover Time can be calculated using the Time-Based Loss Method
(TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method
(TBM). It is RECOMMENDED that the TBM is used.
See Also: Measurement Units:
Failover milliseconds
Failover Time
Time-Based Loss Method (TBLM)
Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM)
3.5.4. Reversion Time Issues:
None.
Definition: See Also:
The amount of time it takes for Reversion to complete so Failover
that the Primary Path is restored as the Working Path. Failover Time
Time-Based Loss Method (TBLM)
Packet-Loss-Based Method (PLBM)
Timestamp-Based Method (TBM)
Discussion: 3.5.4. Reversion Time
Reversion Time can be calculated using the Time-Based Loss
Method (TBLM), Packet-Loss Based Method (PLBM), or
Timestamp-Based Method (TBM). It is RECOMMENDED that the
TBM is used.
Measurement units: Definition:
milliseconds The amount of time it takes for Reversion to complete so that the
Primary Path is restored as the Working Path.
Issues: None Discussion:
Reversion Time can be calculated using the Time-Based Loss Method
(TBLM), Packet-Loss-Based Method (PLBM), or Timestamp-Based Method
(TBM). It is RECOMMENDED that the TBM is used.
See Also: Measurement Units:
Reversion milliseconds
Primary Path
Working Path
Reversion Packet Loss
Time-Based Loss Method (TBLM)
Packet-Loss Based Method (PLBM)
Timestamp-Based Method (TBM)
3.5.5. Additive Backup Delay Issues:
None.
Definition: See Also:
The amount of increased Forwarding Delay [4] resulting Reversion
from data traffic traversing the Backup Path instead of Primary Path
the Primary Path. Working Path
Reversion Packet Loss
Time-Based Loss Method (TBLM)
Packet-Loss-Based Method (PLBM)
Timestamp-Based Method (TBM)
Discussion: 3.5.5. Additive Backup Delay
Additive Backup Delay is calculated using Equation 1 as
shown below:
(Equation 1) Definition:
Additive Backup Delay = The amount of increased Forwarding Delay [4] resulting from data
Forwarding Delay(Backup Path) - traffic traversing the Backup Path instead of the Primary Path.
Forwarding Delay(Primary Path).
Protection Performance Discussion:
Additive Backup Delay is calculated using Equation 1 as shown
below:
Measurement units: (Equation 1)
milliseconds Additive Backup Delay =
Forwarding Delay(Backup Path) -
Forwarding Delay(Primary Path)
Issues: Measurement Units:
Additive Backup Latency may be a negative result. milliseconds
This is theoretically possible, but could be indicative
of a sub-optimum network configuration .
See Also: Issues:
Primary Path Additive Backup Latency may be a negative result. This is
Backup Path theoretically possible but could be indicative of a sub-optimum
Primary Path Latency network configuration.
Backup Path Latency
3.6 Failover Time Calculation Methods See Also:
The following Methods may be assessed on a per-flow basis using Primary Path
at least 16 flows spread over the routing table (more flows is Backup Path
better). Otherwise, the impact of a prefix-dependency in the Primary Path Latency
implementation of a particular protection technology could be Backup Path Latency
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.6.1 Time-Based Loss Method (TBLM) 3.6. Failover Time Calculation Methods
Definition: The following Methods may be assessed on a per-flow basis using at
least 16 flows spread over the routing table (using 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.6.1. Time-Based Loss Method (TBLM)
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 that 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
a time scale. This is indicated by the duration of non-zero time scale. This is indicated by the duration of non-zero packet
packet loss. The TBLM includes failure detection time and loss. The TBLM includes failure detection time and time for data
time for data traffic to begin traversing the Backup Path. traffic to begin traversing the Backup Path. Failover Time and
Failover Time and Reversion Time are calculated using the Reversion Time are calculated using the TBLM as shown in Equation
TBLM as shown in Equation 2: 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 Where
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 Time(Failover) = Time on the tester at the receipt of the first
last unimpaired packet at egress node on the primary path unimpaired packet at egress node after the backup path became the
before failure working path
Measurement units: Time(Failover Event) = Time on the tester at the receipt of the
milliseconds last unimpaired packet at egress node on the primary path before
failure
Issues: Measurement Units:
None milliseconds
Protection Performance
See Also:
Failover
Packet-Loss Based Method
3.6.2 Packet-Loss Based Method (PLBM) Issues:
None.
Definition: See Also:
Failover
Packet-Loss-Based Method
3.6.2. Packet-Loss-Based Method (PLBM)
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
calculated using PLBM from the amount Failover Packet Loss as using PLBM from the amount of Failover Packet Loss as shown below
shown below in Equation 3. Note: If traffic is sent to more than 1 in Equation 3. Note: If traffic is sent to more than 1
destination, PLBM gives the average loss over the measured destination, PLBM gives the average loss over the measured
destinations destinations.
(Equation 3) (Equation 3)
(Equation 3a) (Equation 3a)
PLBM Failover Time = PLBM Failover Time =
(Number of packets lost / (Number of packets lost / Offered Load rate) * 1000)
Offered Load rate) * 1000)
(Equation 3b) (Equation 3b)
PLBM Restoration Time = PLBM Restoration Time =
(Number of packets lost / (Number of packets lost / Offered Load rate) * 1000)
Offered Load rate) * 1000)
Units are packets/(packets/second) = seconds Units are packets/(packets/second) = seconds
Measurement units: Measurement Units:
milliseconds milliseconds
Issues: Issues:
None None.
See Also: See Also:
Failover Failover Time-Based Loss Method
Time-Based Loss Method
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
using a time scale to quantify the interval between time scale to quantify the interval between unimpaired packets
unimpaired packets arriving in the test stream. 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
failure or reversion on a time scale based on the or reversion on a time scale based on the observation of
observation of unimpaired packets. The TBM is calculated unimpaired packets. The TBM is calculated from Equation 2 with
from Equation 2 with the values obtained from the timestamp the values obtained from the timestamp in the packet payload,
in the packet payload, rather than from the Tester clock as rather than from the Tester clock (which are used with 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 Section 3.3 of [7]. A duplicate packet is defined in Section
3.3.5 of [4]. Unimpaired packets may be detected by checking a
[10, section 3.3]. A duplicate packet is defined in sequence number in the payload, where the sequence number equals
[4, section 3.3.3]. A lost packet is defined in
[7, Section 3.5]. Unimpaired packets may be detected by checking
a sequence number in the payload, where the sequence number equals
the next expected number for an unimpaired packet. A sequence gap 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
detection time and time for data traffic to begin traversing the time and time for data traffic to begin traversing the Backup
Backup Path. For calculating Reversion Time, the TBM includes Path. For calculating Reversion Time, the TBM includes Reversion
Reversion Time and time for data traffic to begin traversing the Time and time for data traffic to begin traversing the Primary
Primary Path. Path.
Measurement units:
milliseconds
Issues: None
See Also: Measurement Units:
Failover milliseconds
Failover Time
Reversion
Reversion Time
4. Acknowledgements Issues:
We would like thank the BMWG and particularly Al Morton and Curtis None.
Villamizar for their reviews, comments, and contributions to this
work.
5. IANA Considerations See Also:
This document requires no IANA considerations. Failover
Failover Time
Reversion
Reversion Time
6. Security Considerations 4. Security Considerations
Benchmarking activities as described in this memo are limited to Benchmarking activities as described in this memo are limited to
technology characterization using controlled stimuli in a laboratory technology characterization using controlled stimuli in a laboratory
environment, with dedicated address space and the constraints environment, with dedicated address space and the constraints
specified in the sections above. specified in the sections above.
The benchmarking network topology will be an independent test setup The benchmarking network topology will be an independent test setup
and MUST NOT be connected to devices that may forward the test and MUST NOT be connected to devices that may forward the test
traffic into a production network, or misroute traffic to the test traffic into a production network or misroute traffic to the test
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 5. References
7. References 5.1. Normative References
7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[2] Bradner, S., Editor, "Benchmarking Terminology for [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
Network Interconnection Devices", RFC 1242, July 1991. 9, RFC 2026, October 1996.
[3] Mandeville, R., "Benchmarking Terminology for LAN [2] Bradner, S., "Benchmarking Terminology for Network
Switching Devices", RFC 2285, February 1998. Interconnection Devices", RFC 1242, July 1991.
[4] Poretsky, S., et al., "Terminology for Benchmarking
Network-layer Traffic Control Mechanisms", RFC 4689,
November 2006.
[5] Bradner, S., "Key words for use in RFCs to Indicate [3] Mandeville, R., "Benchmarking Terminology for LAN Switching
Requirement Levels", RFC 2119, July 1997. Devices", RFC 2285, February 1998.
[6] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP [4] Poretsky, S., Perser, J., Erramilli, S., and S. Khurana,
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-21, "Terminology for Benchmarking Network-layer Traffic Control
work in progress, May 2010. Mechanisms", RFC 4689, October 2006.
[7] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
November 2006. Levels", BCP 14, RFC 2119, March 1997.
[8] Hinden, R., "Virtual Router Redundancy Protocol", RFC 5798, [6] Poretsky, S., Imhoff, B., and K. Michielsen, "Terminology for
March 2010. Benchmarking Link-State IGP Data Plane Route Convergence", RFC
6412, November 2011.
7.2. Informative References [7] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and
J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006.
[9] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP [8] Nadas, S., Ed., "Virtual Router Redundancy Protocol (VRRP)
Paths", RFC 4090, May 2005. Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[10] Nichols, K., et al, "Definition of the Differentiated 5.2. Informative References
Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998.
8. Authors' Addresses [9] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
[10] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
6. Acknowledgments
We would like thank the BMWG and particularly Al Morton and Curtis
Villamizar for their reviews, comments, and contributions to this
work.
Authors' Addresses
Scott Poretsky Scott Poretsky
Allot Communications Allot Communications
67 South Bedford Street, Suite 400 300 TradeCenter
Burlington, MA 01803 Woburn, MA 01801
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 Huawei Technologies
12359 Sunrise Valley Drive 2330 Central Expressway
Reston, VA 22102 Santa Clara, CA 95050
USA USA
Phone: +1 703 860 9273 Phone: +1 571 926 8593
Email: rpapneja@isocore.com EMail: rajiv.papneja@huawei.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
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
 End of changes. 322 change blocks. 
1009 lines changed or deleted 1000 lines changed or added

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