draft-ietf-bmwg-protection-term-07.txt   draft-ietf-bmwg-protection-term-08.txt 
Network Working Group S. Poretsky Network Working Group S. Poretsky
Internet Draft Allot Communications Internet Draft Allot Communications
Expires: April 2010 Expires: June 2010 Rajiv Papneja
Intended Status: Informational Rajiv Papneja Intended Status: Informational Isocore J. Karthik
Isocore
J. Karthik
S. Vapiwala S. Vapiwala
Cisco Systems Cisco Systems
October 2009 December 2009
Benchmarking Terminology Benchmarking Terminology
for Protection Performance for Protection Performance
<draft-ietf-bmwg-protection-term-07.txt > <draft-ietf-bmwg-protection-term-08.txt >
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 6, line 25 skipping to change at page 6, line 25
--------- -------- ---------- Path --------- -------- ---------- Path
| State |Control ^ | State |Control ^
| Interface |(Optional) | | Interface |(Optional) |
| --------- | | --------- |
+---------| Standby |---------+ +---------| Standby |---------+
| Node | | Node |
--------- ---------
Figure 5. System Under Test (SUT) for Sub-IP Redundant Node Protection 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.
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] Offered Load [Ref.[3], section 3.5.2]
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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. MUST be created prior to the Failover Event. The backup path
generally originates at the point of failure, and terminates at
a node along a primary path.
Measurement units: Measurement units:
n/a n/a
Issues: Issues:
See Also: See Also:
Path Path
Working Path Working Path
Primary Path Primary Path
skipping to change at page 21, line 45 skipping to change at page 21, line 45
Measurement units: n/a Measurement units: n/a
Issues: Issues:
See Also: See Also:
Primary Node Primary Node
State Control Interface State Control Interface
3.5. Benchmarks 3.5. Benchmarks
The following Benchmarks MAY be assessed on a per-flow basis
using at least 16 flows spread over the routing table (more
flows is better). Otherwise, the impact of a prefix-dependency
in the implementation of a particular protection technology
could be missed. However, the test designer must be aware of
the number of packets per second sent to each prefix, as this
establishes sampling of the path and the time resolution for
measurement of Failover time on a per-flow basis.
3.5.1. Failover Packet Loss 3.5.1. Failover Packet Loss
Definition: Definition:
The amount of packet loss produced by a Failover Event until The amount of packet loss produced by a Failover Event until
Failover completes, where the measurement begins when the last Failover completes, where the measurement begins when the last
unimpaired packet is received by the Tester on the Protected unimpaired packet is received by the Tester on the Protected
Primary Path and ends when the first unimpaired packet is Primary Path and ends when the first unimpaired packet is
received by the Tester on the Backup Path. received by the Tester on the Backup Path.
Protection Performance Protection Performance
skipping to change at page 24, line 22 skipping to change at page 24, line 22
This is theoretically possible, but could be indicative This is theoretically possible, but could be indicative
of a sub-optimum network configuration . of a sub-optimum network configuration .
See Also: See Also:
Primary Path Primary Path
Backup Path Backup Path
Primary Path Latency Primary Path Latency
Backup Path Latency Backup Path Latency
3.6 Failover Time Calculation Methods 3.6 Failover Time Calculation Methods
The following Methods MAY be assessed on a per-flow basis using
at least 16 flows spread over the routing table (more flows is
better). Otherwise, the impact of a prefix-dependency in the
implementation of a particular protection technology could be
missed. However, the test designer must be aware of the number
of packets per second sent to each prefix, as this establishes
sampling of the path and the time resolution for measurement
of Failover time on a per-flow basis.
3.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
skipping to change at page 24, line 47 skipping to change at page 24, line 55
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:
seconds milliseconds
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)
Definition: Definition:
The method used to calculate Failover Time (or Reversion Time) The method used to calculate Failover Time (or Reversion Time)
from the amount of Failover Packet Loss. from the amount of Failover Packet Loss.
Discussion: Discussion:
PLBM includes failure detection time and time for data traffic to PLBM includes failure detection time and time for data traffic to
begin traversing the Backup Path. Failover Time can be begin traversing the Backup Path. Failover Time can be
calculated using PLBM from the amount Failover Packet Loss as calculated using PLBM from the amount Failover Packet Loss as
shown below in Equation 3. Note: If traffic is sent to more than 1 shown below in Equation 3. Note: If traffic is sent to more than 1
destination, PLBM gives the average loss over the measured destinations destination, PLBM gives the average loss over the measured
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:
seconds 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)
skipping to change at page 26, line 20 skipping to change at page 26, line 20
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:
seconds milliseconds
Issues: None Issues: None
See Also: See Also:
Failover Failover
Failover Time Failover Time
Reversion Reversion
Reversion Time Reversion Time
4. Acknowledgements 4. Acknowledgements
We would like thank the BMWG and particularly Al Morton and Curtis We would like thank the BMWG and particularly Al Morton and Curtis
Villamizar for their reviews, comments, and contributions to this Villamizar for their reviews, comments, and contributions to this
work. work.
5. IANA Considerations 5. IANA Considerations
This document requires no IANA considerations. This document requires no IANA considerations.
6. Security Considerations 6. Security Considerations
Documents of this type do not directly affect the security of Benchmarking activities as described in this memo are limited to
Internet or corporate networks as long as benchmarking is not technology characterization using controlled stimuli in a laboratory
performed on devices or systems connected to production networks. environment, with dedicated address space and the constraints
Security threats and how to counter these in SIP and the media specified in the sections above.
layer is discussed in RFC3261, RFC3550, and RFC3711 and various
other drafts. This document attempts to formalize a set of The benchmarking network topology will be an independent test setup
common methodology for benchmarking performance of failover and MUST NOT be connected to devices that may forward the test
mechanisms in a lab environment. traffic into a production network, or misroute traffic to the test
management network.
Further, benchmarking is performed on a "black-box" basis, relying
solely on measurements observable external to the DUT/SUT.
Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production
networks.
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", [1] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996. RFC 2026, October 1996.
[2] Bradner, S., Editor, "Benchmarking Terminology for [2] Bradner, S., Editor, "Benchmarking Terminology for
Network Interconnection Devices", RFC 1242, July 1991. Network Interconnection Devices", RFC 1242, July 1991.
[3] Mandeville, R., "Benchmarking Terminology for LAN [3] Mandeville, R., "Benchmarking Terminology for LAN
skipping to change at page 27, line 51 skipping to change at page 27, line 51
Burlington, MA 01803 Burlington, MA 01803
USA USA
Phone: + 1 508 309 2179 Phone: + 1 508 309 2179
Email: sporetsky@allot.com Email: sporetsky@allot.com
Rajiv Papneja Rajiv Papneja
Isocore Isocore
12359 Sunrise Valley Drive 12359 Sunrise Valley Drive
Reston, VA 22102 Reston, VA 22102
USA USA
Phone: 1 703 860 9273 Phone: +1 703 860 9273
Email: rpapneja@isocore.com Email: rpapneja@isocore.com
Protection Performance Protection Performance
Jay Karthik Jay Karthik
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
Phone: +1 978 936 0533 Phone: +1 978 936 0533
Email: jkarthik@cisco.com Email: jkarthik@cisco.com
 End of changes. 15 change blocks. 
25 lines changed or deleted 58 lines changed or added

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