Sub-IP Layer Protection Mechanism Performance Benchmarking draft-ietf-bmwg-protection-term-04.txt draft-ietf-bmwg-protection-meth-03.txt

Download Report

Transcript Sub-IP Layer Protection Mechanism Performance Benchmarking draft-ietf-bmwg-protection-term-04.txt draft-ietf-bmwg-protection-meth-03.txt

Sub-IP Layer Protection Mechanism Performance Benchmarking

draft-ietf-bmwg-protection-term-04.txt

draft-ietf-bmwg-protection-meth-03.txt

BMWG, IETF-71 Philadelphia March 2008 Author Team: Poretsky, Papneja, Karthik, Vapiwala, LeRoux, Rao

Scope of Work Item

 Common terminology and metrics for benchmarking the performance of sub-IP layer protection mechanisms  Benchmarks are measured at the IP-Layer  Methodology is technology-independent so can be used to compare performance of different protection mechanisms.

 Terminology will applied to separate Methodology documents for different sub-IP layer protection mechanisms  Multi-Protocol Label Switching Fast Reroute (MPLS-FRR)     Generalized MPLS (GMPLS) Automatic Protection Switching (APS) Virtual Router Redundancy Protocol (VRRP) Stateful High Availability (HA) 2

Scope in Terminology Introduction

Technologies that function at sub-IP layers can be enabled to provide further 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. Such Sub-IP Protection technologies include High Availability (HA) stateful failover, Virtual Router Redundancy Protocol (VRRP), Automatic Link Protection (APS) for SONET/SDH, 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 convergence [7]. New terminology and methodologies specific to benchmarking sub-IP layer protection mechanisms are required. This will enable different implementations of the same protection mechanisms to be benchmarked and evaluated. In addition, different protection mechanisms can be benchmarked and evaluated. 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. It is intended that there can exist unique methodology documents for each sub-IP protection mechanism. 3

Terminology Changes from Rev 03 to 04

Added new terms:

     3.2.5. Local Link Protection..........................13

 3.2.6. Redundant Node Protection................14

 3.2.7 State Control Interface.........................14

 3.4.3. Headend Node....................................19

3.4.4. Backup Node......................................19

(3.4.5. Merge Node.......................................20 ) 3.4.6. Primary Node......................................20

3.4.7. Standby Node.....................................21 4

Added Figures for Protection Mechanisms (1 of 2)

IP Traffic Tester IP Traffic Failover Event Ingress/ Headend Primary Path Egress/ Merge Link Protection Backup Backup Path Node Protection (Also provides Link Protection) Backup Path IP Traffic Tester IP Traffic Failover Event Ingress/ Headend Primary Path MidPoint Backup Egress/ Merge IP Traffic Tester IP Traffic Failover Event Path Protection (Also provides Node Protection and Link Protection) Ingress/ Headend Primary Path MidPoint Egress/ Merge Backup Backup Path

5

Added Figures for Protection Mechanisms (2 of 2)

IP Traffic Tester IP Traffic Failover Event Ingress/ Headend Primary Path Egress/ Merge Link Protection Backup Path Backup Local-Link Protection IP Traffic Tester IP Traffic Failover Event Ingress/ Headend Primary Path Backup Path Egress/ Merge IP Traffic Tester IP Traffic Failover Event Redundant Node Protection Ingress/ Headend Primary Path Primary Egress/ Merge State Control Interface Standby

6

Sequence of Events

1. Failover Event - Primary Path fails 2. Failure Detection- Failover Event is detected 3. Failover - Backup Path becomes the Working Path due to Failover Event 4. Restoration - Primary Path recovers from a Failover Event 5. Reversion (optional) - Primary Path becomes the Working Path

7

Benchmarks

3.5.1. Failover Packet Loss..............................21

3.5.2. Reversion Packet Loss...........................22 3.5.3. Failover Time..........................................22 3.5.4. Reversion Time.......................................23 3.5.5. Additive Backup Dely.........................23

(Equation 1)

Additive Backup Delay

= Forwarding Delay(Backup Path) - Forwarding Delay(Primary Path) 

Unimpaired Packet

    Out-of-order Packet [Ref.[4], section 3.3.2] Duplicate Packet [Ref.[4], section 3.3.3] Forwarding Delay [Ref.[4], section 3.2.4] Packet Loss [Ref.[7], Section 3.5] 8

Calculation Methods

Time-Based Loss Method (TBLM)

(Equation 2a) TBLM Failover Time = Time(Failover) - Time(Failover Event) (Equation 2b) TBLM Reversion Time = Time(Reversion) - Time(Restoration)

Timestamp-Based Method (TBM)

Uses Equation 2 with the difference being that the time values are obtained from the timestamp in the packet payload rather than from the Tester.

Packet-Loss Based Method (PLBM)

(Equation 3a) PLBM Failover Time = Number of packets lost / (Offered Load rate * 1000) Units are packets/(packets/second) = seconds (Equation 3b) PLBM Restoration Time = Number of packets lost / (Offered Load rate * 1000) Units are packets/(packets/second) = seconds 9

Methodology Changes from Rev 02 to 03

    New version submitted February 18, 2008 Minor nits to the document Waiting for terminology to firm up before making further changes to the methodology document Excellent comments from Tom Alexander – Brief overview and AI  We plan to address and respond to the comments to the mailing list  We will clarify the stream characteristics as pointed out in your comments  We will try to bring uniformity in terms usage through out the document  We will try to reduce the number of figures by using your suggestions on compressed topology (Need to discuss with other authors though!)  Will try to address the scenario in the diagrams where head-end is the PLR  Will streamline the definitions once terminology document is finalized 10

Next Steps

 Incorporate any new comments from meeting and mailing list  Methodology document to updated upon obtaining concurrence on terminology document  Version 4 of Methodology Document to include Tom’s comments  Seek direction from the working group on firming up the progress of terminology document 11

BACKGROUND SLIDES

12

Terminology Changes from Rev 02 to 03

 Removed term “Tunnel” because it was not used anywhere and was similar in definition to “Path”.  Path definition updated to be sequence of nodes and links, not just sequence of nodes.

 Added two new Benchmarks:  3.5.1. Failover Packet Loss  3.5.2. Reversion Packet Loss  Added sequence of events to section 1. Introduction “The sequence of events is as follows: 1. Failover Event - Primary Path fails 2. Failure Detection- Failover Event is detected 3. Failover - Backup Path becomes the Working Path due to Failover Event 4. Restoration - Primary Path recovers from a Failover Event 5. Reversion (optional) Primary Path becomes the Working Path” 13

Restoration/Reversion Clarified in -03

-02 Submittal

3.3.4. Restoration Definition: The act of Failover Recovery in which the Primary Path is restored following a Failover Event.

3.3.5. Reversion Definition: The act of restoring the Primary Path as the Working Path.

-03 Submittal

3.3.4. Restoration Definition: The act of failover recovery in which the Primary Path recovers from a Failover Event, but is not yet forwarding packets because the Backup Path remains the Working Path. 3.3.5. Reversion Definition: The act of failover recovery in which the Primary Path becomes the Working Path so that it forwarding packets.

14