draft-ietf-bmwg-protection-term-04.txt   draft-ietf-bmwg-protection-term-05.txt 
Network Working Group S. Poretsky Network Working Group S. Poretsky
Internet Draft NextPoint Networks Internet Draft Allot Communications
Expires: August 2008 Intended Status: Informational Rajiv Papneja
Intended Status: Informational R. Papneja
Isocore Isocore
J. Karthik J. Karthik
Cisco Systems Cisco Systems
S. Vapiwala S. Vapiwala
Cisco Systems Cisco Systems
February 25, 2008 November 3, 2008
Benchmarking Terminology for Protection Performance
<draft-ietf-bmwg-protection-term-04.txt > Benchmarking Terminology
for Protection Performance
<draft-ietf-bmwg-protection-term-05.txt >
Intellectual Property Rights (IPR) statement: Intellectual Property Rights (IPR) statement:
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 1, line 50 skipping to change at page 1, line 49
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document provides common terminology and metrics for benchmarking This document provides common terminology and metrics for benchmarking
the performance of sub-IP layer protection mechanisms. The performance the performance of sub-IP layer protection mechanisms. The performance
benchmarks are measured at the IP-Layer, so avoid dependence on benchmarks are measured at the IP-Layer, avoiding dependence on
specific sub-IP protection mechanisms. The benchmarks and terminology specific sub-IP protection mechanisms. The benchmarks and terminology
can be applied in methodology documents for different sub-IP layer can be applied in methodology documents for different sub-IP layer
protection mechanisms such as Automatic Protection Switching (APS), protection mechanisms such as Automatic Protection Switching (APS),
Virtual Router Redundancy Protocol (VRRP), Stateful High Availability Virtual Router Redundancy Protocol (VRRP), Stateful High Availability
(HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR). (HA), and Multi-Protocol Label Switching Fast Reroute (MPLS-FRR).
Protection Performance Protection Performance
Table of Contents Table of Contents
1. Introduction..............................................3 1. Introduction..............................................3
2. Existing definitions......................................6 2. Existing definitions......................................6
skipping to change at page 2, line 50 skipping to change at page 2, line 50
3.4.3. Headend Node....................................19 3.4.3. Headend Node....................................19
3.4.4. Backup Node.....................................19 3.4.4. Backup Node.....................................19
3.4.5. Merge Node......................................20 3.4.5. Merge Node......................................20
3.4.6. Primary Node....................................20 3.4.6. Primary Node....................................20
3.4.7. Standby Node....................................21 3.4.7. Standby Node....................................21
3.5. Benchmarks...........................................21 3.5. Benchmarks...........................................21
3.5.1. Failover Packet Loss............................21 3.5.1. Failover Packet Loss............................21
3.5.2. Reversion Packet Loss...........................22 3.5.2. Reversion Packet Loss...........................22
3.5.3. Failover Time...................................22 3.5.3. Failover Time...................................22
3.5.4. Reversion Time..................................23 3.5.4. Reversion Time..................................23
3.5.5. Additive Backup Latency.........................23 3.5.5. Additive Backup Delay...........................23
3.6 Failover Time Calculation Methods.....................24 3.6 Failover Time Calculation Methods.....................24
3.6.1 Time-Based Loss Method...........................24 3.6.1 Time-Based Loss Method...........................24
3.6.2 Packet-Loss Based Method.........................25 3.6.2 Packet-Loss Based Method.........................25
3.6.3 Timestamp-Based Method...........................25 3.6.3 Timestamp-Based Method...........................25
4. Acknowledgments...........................................26 4. Acknowledgments...........................................26
5. IANA Considerations.......................................26 5. IANA Considerations.......................................26
6. Security Considerations...................................26 6. Security Considerations...................................26
7. References................................................26 7. References................................................26
8. Author's Address..........................................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. traffic against planned and unplanned failures in the internet. Fast
Fast convergence times are critical to maintain reliable network convergence times are critical to maintain reliable network
connectivity and performance. Technologies that function at sub-IP connectivity and performance. Convergence Events [7] are recognized
layers can be enabled to provide further protection of IP at the IP Layer so that Route Convergence [7] occurs. Technologies
traffic by providing the failure recovery at the sub-IP layers so that function at sub-IP layers can be enabled to provide further
that the outage is not observed at the IP-layer. Such Sub-IP protection of IP traffic by providing the failure recovery at the
Protection technologies include High Availability (HA) stateful sub-IP layers so that the outage is not observed at the IP-layer.
failover, Virtual Router Redundancy Protocol (VRRP), Automatic Link Such sub-IP protection technologies include, but are not limited to,
Protection (APS) for SONET/SDH, Resilient Packet Ring (RPR) for High Availability (HA) stateful failover, Virtual Router Redundancy
Ethernet, and Fast Reroute for Multi-Protocol Label Switching Protocol (VRRP) [11], Automatic Link Protection (APS) for SONET/SDH,
(MPLS-FRR) [8]. Resilient Packet Ring (RPR) for Ethernet, and Fast Reroute for
Multi-Protocol Label Switching (MPLS-FRR) [8].
Benchmarking terminology have been defined for IP-layer route 1.1 Scope
convergence [7]. New terminology and methodologies specific Benchmarking terminology was defined for IP-layer convergence in
to benchmarking sub-IP layer protection mechanisms are required. [7]. Different terminology and methodologies specific to
This will enable different implementations of the same benchmarking sub-IP layer protection mechanisms are required. The
protection mechanisms to be benchmarked and evaluated. In metrics for benchmarking the performance of sub-IP protection
addition, different protection mechanisms can be benchmarked and mechanisms are measured at the IP layer, so that the results are
evaluated. The metrics for benchmarking the performance of sub-IP always measured in reference to IP and independent of the specific
protection mechanisms are measured at the IP layer, so that the protection mechanism being used. The purpose of this document is
results are always measured in reference to IP and independent of to provide a single terminology for benchmarking sub-IP protection
the specific protection mechanism being used. The purpose of this mechanisms.
document is to provide a single terminology for benchmarking sub-IP
protection mechanisms. It is intended that there can exist unique A common terminology for Sub-IP layer protection mechanism
methodology documents for each sub-IP protection mechanism. The benchmarking enables different implementations of a protection
sequence of events is as follows: mechanism to be benchmarked and evaluated. In addition,
implementations of different protection mechanisms can be
benchmarked and evaluated. It is intended that there can exist
unique methodology documents for each sub-IP protection mechanism
based upon this common terminology document. The terminology
can be aplied to methodologies that benchmark sub-IP protection
mechanism performance with a single stream of traffic or
multiple streams of traffic. The traffic flow may be
uni-directional or bi-directional as to be indicated in the
methodology.
1.2 General Model
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. Figures 1 These terms are further defined in this document.
through 5 show fundamental models that MAY be used in
benchmarking Sub-IP Protection mechanisms. Sub-IP Protection
mechanisms MUST use a Protection Switching System that consists
of a minimum of two Protection-Switching Nodes, an Ingress Node
known as the Headend Node and an Egress Node known as the Merge
Node. The protection MAY be provided with 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.
A Protection Switching System may provide link protection, node
protection, path protection, local link protection, and high
availability, as shown in Figures 1 through 5 respectively.
A Failover Event occurs along the Primary Path or at the Primary
Protection Performance Protection Performance
Node. The Working Path is the Primary Path prior to the Failover Figures 1 through 5 show models that MAY be used when benchmarking
Event and the Backup Path after the Failover Event. A Tester is Sub-IP Protection mechanisms, which MUST use a Protection Switching
set outside the two paths or nodes as it sends and receives IP System that consists of a minimum of two Protection-Switching Nodes,
traffic along the Working Path. The tester MUST record the IP an Ingress Node known as the Headend Node and an Egress Node known
packet sequence numbers, departure time, and arrival time so that as the Merge Node. The Protection Switching System MUST include
the metrics of Failover Time, Additive Latency, Packet Reordering, either a Primary Path and Backup Path, as shown in Figures 1 through
Duplicate Packets, and Reversion Time can be measured. The Tester 4, or a Primary Node and Standby Node, as shown in Figure 5. A
may be a single device or a test system. If Reversion is Protection Switching System may provide link protection, node
supported then the Working Path is the Primary Path after protection, path protection, local link protection, and high
Restoration (Failure Recovery) of the Primary Path. availability, as shown in Figures 1 through 5 respectively. A
Failover Event occurs along the Primary Path or at the Primary Node.
The Working Path is the Primary Path prior to the Failover Event and
the Backup Path after the Failover Event. A Tester is set outside
the two paths or nodes as it sends and receives IP traffic along the
Working Path. The tester MUST record the IP packet sequence numbers,
departure time, and arrival time so that the metrics of Failover
Time, Additive Latency, Packet Reordering, Duplicate Packets, and
Reversion Time can be measured. The Tester may be a single device
or a test system. If Reversion is supported then the Working Path is
the Primary Path after Restoration (Failure Recovery) of the Primary
Path.
Link Protection, as shown in Figure 1, provides protection Link Protection, as shown in Figure 1, provides protection when a
when a Failover Event occurs on the link between two nodes along Failover Event occurs on the link between two nodes along the Primary
the Primary Path. Node Protection, as shown in Figure 2, Path. Node Protection, as shown in Figure 2, provides protection
provides protection when a Failover Event occurs at a Node along when a Failover Event occurs at a Node along the Primary Path.
the Primary Path. Path Protection, as shown in Figure 3, Path Protection, as shown in Figure 3, provides protection for link
provides protection for link or node failures for multiple hops or node failures for multiple hops along the Primary Path. Local
along the Primary Path. Local Link Protection, as shown in Link Protection, as shown in Figure 4, provides Sub-IP Protection of
Figure 4, provides Sub-IP Protection of a link between two nodes, a link between two nodes, without a Backup Node. An example of such
without a Backup Node. An example of such a Sub-IP Protection a Sub-IP Protection mechanism is SONET APS. High Availability
mechanism is SONET APS. High Availability Protection, as shown Protection, as shown in Figure 5, provides protection of a Primary
in Figure 5, provides protection of a Primary Node with a Node with a redundant Standby Node. State Control is provided
redundant Standby Node. State Control is provided between the between the Primary and Standby Nodes. Failure of the Primary Node
Primary and Standby Nodes. Failure of the Primary Node is is detected at the Sub-IP layer to force traffic to switch to the
detected at the Sub-IP layer to force traffic to switch to Standby Node, which has state maintained for zero or minimal packet
the Standby Node, which has state maintained for zero or minimal loss.
packet 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 Figure 1. System Under Test (SUT) for Sub-IP 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 34 skipping to change at page 6, line 34
2. Existing definitions 2. Existing definitions
This document uses existing terminology defined in other BMWG This document uses existing terminology defined in other BMWG
work. Examples include, but are not limited to: work. Examples include, but are not limited to:
Latency [Ref.[2], section 3.8] Latency [Ref.[2], section 3.8]
Frame Loss Rate [Ref.[2], section 3.6] Frame Loss Rate [Ref.[2], section 3.6]
Throughput [Ref.[2], section 3.17] Throughput [Ref.[2], section 3.17]
Device Under Test (DUT) [Ref.[3], section 3.1.1] Device Under Test (DUT) [Ref.[3], section 3.1.1]
System Under Test (SUT) [Ref.[3], section 3.1.2] System Under Test (SUT) [Ref.[3], section 3.1.2]
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.[7], Section 3.5]
Packet Reordering [Ref.[10], section 3.3] Packet Reordering [Ref.[10], section 3.3]
This document has the following frequently used acronyms: 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]. [2]. Terms defined in this document are capitalized when used
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].
RFC 2119 defines the use of these key words to help make the RFC 2119 defines the use of these key words to help make the
intent of standards track documents as clear as possible. While this intent of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards track document uses these keywords, this document is not a standards track
document. document.
Protection Performance Protection Performance
skipping to change at page 7, line 34 skipping to change at page 7, line 34
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.
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 [9] will traverse one or more paths.
The path is unidirectional. Example paths are the SONET/SDH The path is unidirectional. For example, the link between R1
path and the label switched path for MPLS. 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: Measurement units:
n/a n/a
Issues: Issues:
"A bidirectional path", which transmits traffic in both "A bidirectional path", which transmits traffic in both
directions along the same nodes, consists of two unidirectional directions along the same nodes, consists of two unidirectional
paths. Therefore, the two unidirectional paths belonging to paths. Therefore, the two unidirectional paths belonging to
"one bidirectional path" will be treated independently when "one bidirectional path" will be treated independently when
benchmarking for "a bidirectional path". benchmarking for "a bidirectional path".
skipping to change at page 8, line 14 skipping to change at page 8, 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 becomes the Working Path after Failover Event. A Backup Path SHALL become the Working Path
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
skipping to change at page 9, line 23 skipping to change at page 9, line 23
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 be the Working Path upon a Failover Event. The Backup Path SHALL become the Working Path upon a Failover
A Path MAY have one or more Backup Paths. A Backup Path MAY Event. A Path MAY have one or more Backup Paths. A Backup
protect one or more Primary Paths. There are various types of Path MAY protect one or more Primary Paths. There are various
Backup Paths: types of Backup Paths:
a. dedicated recovery Backup Path (1+1), which has 100% a. dedicated recovery Backup Path (1+1), which has 100%
redundancy for a specific ordinary path, 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. A new Path MUST be created prior to the Failover Event.
computed after the Failover Event is simply Convergence [7]
to a new Primary Path.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
skipping to change at page 10, line 47 skipping to change at page 10, 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 is considered disjoint if they do not A pair of paths that do not share a common link.
share a common link.
Discussions: Discussion:
Paths that protect a segment of a path may merge beyond the Two paths are disjoint if they do not share a common node other
segment being protected and are considered disjoint if they than the ingress and egress.
do not use a link from the set of links in the protected
segment. A path is node disjoint if it does not share a
common node 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 along the Primary Path that uses a Backup Path to A node capable of Failover along the Primary Path that is
protect another node or link. also the ingress node for the Backup Path to protect another
node or link.
Discussion: Discussion:
Based on the functionality of the PLR, its role is defined Any node along the Primary Path from the ingress node to
based on the type of method used. If the one-to-one backup the penultimate egress node MAY be a PLR. The PLR MAY use
method is used, the PLR is responsible for computing a a single Backup Path for protecting one or more Primary
separate Backup Path for each Primary Path. In the case Paths. There can be multiple PLRs along a Primary Path.
the facility backup method is used, the PLR creates a The PLR MUST be an ingress to a Backup Path. The PLR can
single Backup Path that can be used to protect multiple be any node along the Primary Path except the egress node
Primary Paths. Any node from the ingress node to the of the Primary Path. The PLR MAY simultaneously be a
penultimate egress node MAY be a PLR. If the PLR is at Headend Node when it is serving the role as ingress to
the ingress, the Backup Path is a Disjoint Path from the the Primary Path and the Backup Path. If the PLR is
ingress to egress. also the Headend Node, then the Backup Path is a Disjoint
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
skipping to change at page 13, line 19 skipping to change at page 13, line 19
Node Protection Node Protection
Link protection Link protection
3.2.4. Backup Span 3.2.4. Backup Span
Definition: Definition:
The number of hops used by a Backup Path. The number of hops used by a Backup Path.
Discussion: Discussion:
The Backup Span is an integer obtained by counting the The Backup Span is an integer obtained by counting the
number of nodes along the Backup path number of nodes along the Backup Path.
Measurement units: Measurement units:
number of nodes number of nodes
Issues: Issues:
None None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
skipping to change at page 13, line 49 skipping to change at page 13, line 49
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:
Backup path Backup Path
Headend Backup Node
Protection Performance Protection Performance
3.2.6. Redundant Node Protection 3.2.6. Redundant Node Protection
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
skipping to change at page 14, line 31 skipping to change at page 14, line 31
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
Backup 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 MUST be out-of-band.
skipping to change at page 15, line 14 skipping to change at page 15, line 14
Protection Performance Protection Performance
3.2.8. Protected Interface 3.2.8. Protected Interface
Definition: Definition:
An interface along the Primary Path that is protected by An interface along the Primary Path that is protected by
a Backup Path. a Backup Path.
Discussion: Discussion:
A Protected Interface is an interface protected by a A Protected Interface is an interface protected by a
Protection Switching Systems that provides Link Protection Switching System that provides Link
Protection, Node Protection, Path Protection, Local Protection, Node Protection, Path Protection, Local
Link Protection, and Redundant Node Protection. Link Protection, and Redundant Node Protection.
Measurement units: None Measurement units: None
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
skipping to change at page 15, line 36 skipping to change at page 15, 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 have a Primary Path The Protection Switching System MUST include either a
and a Backup Path. The Backup Path MAY be a Standby Primary Path and Backup Path, as shown in Figures 1 through
Backup Path or a dynamic Backup Path. The Protection 4, or a Primary Node and Standby Node, as shown in Figure
Switching System includes the mechanisms for both Failure 5. The Backup Path MAY be a Standby Backup Path or a
Detection and Failover. dynamic Backup Path. The Protection Switching System
includes the mechanisms for both Failure Detection and
Failover.
Measurement units: n/a Measurement units: n/a
Issues: None Issues: None
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Failover Failover
skipping to change at page 16, line 26 skipping to change at page 16, line 26
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 [7]
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: Issues: None
See Also: See Also:
Path Path
Failure Detection Failure Detection
Disjoint Path Disjoint Path
3.3.3. Failure Detection 3.3.3. Failure Detection
Definition: Definition:
The process to identify at a sub-IP layer a Failover Event The process to identify at a sub-IP layer a Failover Event
skipping to change at page 17, line 9 skipping to change at page 17, line 9
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Protection Performance Protection Performance
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 [7], 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.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
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, however it MAY exist along the Primary Switching System, but MAY exist along the Primary Path or
Path or Backup Path. Backup Path.
Discussion: Discussion:
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Protection Switching System Protection Switching System
Primary Path Primary Path
Backup Path Backup Path
3.4.3. Headend Node 3.4.3. Headend Node
Definition: Definition:
A node along the Primary Path that is capable of Failover. The ingress node of the Primary Path.
Discussion: Discussion:
The Headend Node can be any node along the Primary Path The Headend Node may also be a PLR when it is serving in
except the egress node of the Primary Path. There can be the dual role as the ingress to the Backup Path.
multiple Failover Nodes along a Primary Path. The Failover
Node MUST be the ingress to the Backup Path. The Failover
Node MAY also be the ingress of the Primary Path. The Headend
Failover Node is always a PLR.
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Path Primary Path
Point of Local Repair 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
skipping to change at page 20, line 16 skipping to change at page 20, line 16
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Backup Path Backup Path
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
skipping to change at page 24, line 32 skipping to change at page 24, line 32
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 to granularity of milliseconds based on failure on a time scale based on occurrence of packet loss on
occurrence of packet loss on a time scale. This is indicated by a time scale. This is indicated by the duration of non-zero
the duration of non-zero packet loss. The TBLM includes failure packet loss. The TBLM includes failure detection time and
detection time and time for data traffic to begin traversing the time for data traffic to begin traversing the Backup Path.
Backup Path. Failover Time and Reversion Time are calculated Failover Time and Reversion Time are calculated using the
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)
Measurement units: Measurement units:
milliseconds seconds
Issues: Issues:
None None
See Also: See Also:
Failover Failover
Packet-Loss Based Method Packet-Loss Based Method
Protection Performance Protection Performance
3.6.2 Packet-Loss Based Method (PLBM) 3.6.2 Packet-Loss Based Method (PLBM)
skipping to change at page 25, line 32 skipping to change at page 25, line 32
(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 seconds
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 time scale to quantify the interval between using a time scale to quantify the interval between
unimpaired packets arriving in the test stream. unimpaired packets arriving in the test stream.
Discussion: Discussion:
The purpose of this method is to quantify the duration of The purpose of this method is to quantify the duration of
failure or reversion on a time scale with granularity of failure or reversion on a time scale based on the
milliseconds based on the observation of unimpaired packets, observation of unimpaired packets, The TBM is calculated
using Equation 2 with the difference being that the time from Equation 2 with the values obtained from the timestamp
values are obtained from the timestamp in the packet payload in the packet payload, rather than from the Tester clock as
rather than from the Tester. 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
[7, Section 3.5]. Unimpaired packets may be detected by checking [7, Section 3.5]. Unimpaired packets may be detected by checking
a sequence number in the payload, where the sequence number equals a sequence number in the payload, where the sequence number equals
the next expected number for an unimpaired packet. A sequence gap the next expected number for an unimpaired packet. A sequence gap
or sequence reversal indicates impaired packets. or sequence reversal indicates impaired packets.
For calculating Failover Time, the TBM includes failure For calculating Failover Time, the TBM includes failure
detection time and time for data traffic to begin traversing the detection time and time for data traffic to begin traversing the
Backup Path. For calculating Reversion Time, the TBM includes Backup Path. For calculating Reversion Time, the TBM includes
Reversion Time and time for data traffic to begin traversing the Reversion Time and time for data traffic to begin traversing the
Primary Path. Primary Path.
Measurement units: Measurement units:
milliseconds seconds
Issues: None Issues: None
See Also: See Also:
Failover Failover
Failover Time Failover Time
Reversion Reversion
Reversion Time Reversion Time
4. Acknowledgements 4. Acknowledgements
skipping to change at page 27, line 14 skipping to change at page 27, line 14
Protection Performance Protection Performance
[5] Bradner, S., "Key words for use in RFCs to Indicate [5] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, July 1997. Requirement Levels", RFC 2119, July 1997.
[6] Paxson, V., et al., "Framework for IP Performance Metrics", [6] Paxson, V., et al., "Framework for IP Performance Metrics",
RFC 2330, May 1998. RFC 2330, May 1998.
[7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP [7] Poretsky, S., Imhoff, B., "Benchmarking Terminology for IGP
Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-15, Convergence", draft-ietf-bmwg-igp-dataplane-conv-term-16,
work in progress, February 2008. work in progress, November 2008.
[8] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP [8] Pan., P. et al, "Fast Reroute Extensions to RSVP-TE for LSP
Paths", RFC 4090, May 2005. Paths", RFC 4090, May 2005.
[9] Nichols, K., et al, "Definition of the Differentiated [9] Nichols, K., et al, "Definition of the Differentiated
Services Field (DS Field) in the IPv4 and IPv6 Headers", Services Field (DS Field) in the IPv4 and IPv6 Headers",
RFC 2474, December 1998. RFC 2474, December 1998.
[10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737, [10] Morton, A., et al, "Packet Reordering Metrics", RFC 4737,
November 2006. November 2006.
[11] Hinden, R., "Virtual Router Redundancy Protocol", RFC 3768,
April 2004.
7.2. Informative References 7.2. Informative References
None None
8. Author's Address 8. Authors' Addresses
Scott Poretsky Scott Poretsky
NextPoint Networks Allot Communications
3 Federal Street 67 South Bedford Street, Suite 400
Billerica, MA 01821 Burlington, MA 01803
USA USA
Phone: + 1 508 439 9008 Phone: + 1 508 309 2179
EMail: sporetsky@nextpointnetworks.com Email: sporetsky@allot.com
Rajiv Papneja Rajiv Papneja
Isocore Isocore
12359 Sunrise Valley Drive 12359 Sunrise Valley Drive
Reston, VA 22102 Reston, VA 22102
USA USA
Phone: 1 703 860 9273 Phone: 1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Jay Karthik Jay Karthik
 End of changes. 47 change blocks. 
154 lines changed or deleted 165 lines changed or added

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