1 / 7

Pseudo-Wire Protection

Pseudo-Wire Protection. Ping Pan ppan@hammerheadsystems.com IETF 65. Why?. PW (Important traffic). Tunnel-1 (BW1). Node 2. Node1. PW (Best effort). Tunnel-2 (BW2), backup Tunnel-1. Switch-over. Conventional mechanism (e.g. MPLS FRR) would work, if

mhuggins
Download Presentation

Pseudo-Wire Protection

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. Pseudo-Wire Protection Ping Pan ppan@hammerheadsystems.com IETF 65

  2. Why? PW (Important traffic) Tunnel-1 (BW1) Node 2 Node1 PW (Best effort) Tunnel-2 (BW2), backup Tunnel-1 Switch-over • Conventional mechanism (e.g. MPLS FRR) would work, if • Tunnel-1 and Tunnel-2 have the same bandwidth (i.e.,BW1 = BW2) • All PW’s are equally important • Otherwise, if BW2 < BW1, • Important traffic may get dropped/delayed during network failure • PW protection: • Each PW needs to have its own “importance” and QoS level • During switch-over, preempt others if necessary

  3. Design Considerations (1) • Need to work in single and multi-segment environment • Work with Generic ID FEC only • Working and protection PW’s must be uniquely identified • But make the use of AII/AGI may not be a good idea working protection Need to know what to process

  4. Design Considerations (2) • On Backup Path Determination • Carrying “ERO” should be optional • Use hop-by-hop forwarding for the working PW • Get “RRO” information from “PW Switching Point TLV (SP-TLV)” • Build the protection PW base on SP-TLV • May use SP-TLV for loop-detection • On CAC at each hop • Should be optional depending on traffic type • Other relevant protection information: • 1:1 or 1:N: need to validate the need of 1:N • Fate-sharing: useful in multi-hop applications • Hot-standby vs. cold-standby

  5. Protocol Extension • Protection-TLV • Setup and Holding Preference Levels • Protection Type: hot or cold standby • Schemes: 1:1 or 1:N • Flags: • Fate-sharing allowed • Per-hop BW CAC required • Reference ID: unique identify working and protecting PW’s • PW Status: • Bad message, no bandwidth etc. • Everything else: • Keep as it is • AII/AGI must be the same on all working and protecting PW’s

  6. How does it work? Protecting PW Working PW Node 3 Node 2 Node1 • Run MHOP PW for working and protection PW setup • Use SP-TLV for loop detection • Use Protection-TLV and SP-TLV to forward working and protection PW’s • Forward failure status if not working • Run the Generic FEC procedure to setup the working PW • Run the Generic FEC procedure to setup the protection PW • When working, pointing user traffic to the protecting PW • During failure (learned from BFD etc.), switch over • Preempt traffic when needed… • Send out Label Mapping and setup the working PW • When working, setup the protecting PW (base on SP-TLV…) • When working, pointing user traffic to the protecting PW • During failure (learned from BFD etc.), switch over • Preempt traffic when needed…

  7. Next Step • This proposal works in both single-segment and multi-segment cases • Like to • Continue to gather feedback • Iron out the details with others • Make this into a WG Working Document THANK YOU ALL

More Related