1 / 9

Scope of Work Item

Sub-IP Layer Protection Mechanism Performance Benchmarking draft-ietf-bmwg-protection-term-03.txt draft-ietf-bmwg-protection-meth-02.txt BMWG, IETF-70 Vancouver December 2007 Author Team: Poretsky, Papneja, Karthik, Vapiwala, LeRoux, Rao. Scope of Work Item.

beau
Télécharger la présentation

Scope of Work Item

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Sub-IP Layer Protection Mechanism Performance Benchmarkingdraft-ietf-bmwg-protection-term-03.txtdraft-ietf-bmwg-protection-meth-02.txtBMWG, IETF-70VancouverDecember 2007Author Team: Poretsky, Papneja, Karthik, Vapiwala, LeRoux, Rao

  2. 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)

  3. 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”

  4. 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. 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. Restoration/Reversion Clarified in -03 -02 Submittal -03 Submittal

  5. Equations Updated in -03 (Equation 1) Additive Backup Delay = Forwarding Delay(Backup Path) - Forwarding Delay(Primary Path) (Equation 2) Time-Based Loss Method (TBLM) (Equation 2a) TBLM Failover Time = Time(Failover) - Time(Failover Event) (Equation 2b) TBLM Reversion Time = Time(Reversion) - Time(Restoratio 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. (Equation 3) 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

  6. Input from Al for -04 • Simplify the following terms. Failover Event, Failure Detection, Failover, Restoration, Reversion and Protection-Switching Node • Agree with recommendations AND "Failover Event" will include "malfunction or planned stoppage" in its definition. • Clarify Discussion for Failure Detection. • Agree with recommendations AND will replace "PLR" with "midpoint".

  7. Input from Adrian (CCAMP) for -04 Please consider aligning terminology with RFC 4427 produced by CCAMP. This derives terms from: - RFC 3386 - G.808.1 - G.841 Of course, there are many other sources of terminology for protection features. Thanks, Adrian • There is some alignment and some contradiction with this BMWG work item. • Author Team will update Terminology and Methodology document as necessary and provide explanation for any remaining deltas. • Examples: • The RFC 4427 definition of Impairment assumes packet loss. Contrary to BMWG work in which impairments could occur regardless of whether or not packer loss occurs. The goal of the BMWG work item is to benchmark protection mechanisms that prevent packet loss when “Failover Event” occurs. • A path is defined as a single link, whereas in RFC4427 "span" defines a link

  8. Acknowledgements • Thanks to BMWG-ers for support shown in the work item • The authors wish to thank the following for their invaluable input to the merged document • Curtis Villamizar • Jean Philippe Vasseur • Thanks to Agilent Technologies for their comments on this work item and for conforming to the methodology we proposed

  9. Next Steps • Incorporate any new comments from meeting and mailing list • Submit -04 Term and -03 Methodology by end of January

More Related