1 / 7

802.1Qay Protection Switching

802.1Qay Protection Switching. PBB-TE Protection Switching Requirements May 2008 Steve Oliva, Sprint . PBB-TE Protection Switching Requirements .

reynold
Download Presentation

802.1Qay Protection Switching

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. 802.1Qay Protection Switching PBB-TE Protection Switching Requirements May 2008 Steve Oliva, Sprint

  2. PBB-TE Protection Switching Requirements • As noted, among other potential 802.1Qay requirements (as being requirements also identified in ITU-T G.8031), in the NTT contribution in the March 08 meeting: • A mismatch between the bridge/selector positions of the near end and far end should be detected • The bridge/selector mismatch for the local network element should be detected and reported • …(other potential requirements)… • Thus leading to a requested 802.1Qay requirement (which need not necessarily be tied specifically to G.8031) Post-protection-switching PBB-TE protection bridge configurations must be audited to ensure compatible operation took place at both ends following a switch.

  3. PBB-TE Protection Switching Requirements • The NTT contribution in the March meeting also noted another requirement identified in ITU-T G.8031: • A bridge/selector mismatch should be cleared by the network operator • While this indeed can be a valid requirement, a more precise requirement for 802.1Qay might be: Following detection of a bridge/selector mismatch, an attempt to correct the mismatch must be made by the 802.1 protection switching process. Failing such correction, the mismatch must be reported by the protection switching process to an OSS/NMS, enabling the mismatch to be corrected by a network operator.

  4. PBB-TE Protection Switching Requirements Illustrating the need for the requirements defined on pp 2-3 • Some potential mismatches following an event requiring a protection switch: • Near end fails to switch due to malfunction but sends RDI (or equivalent) causing the far end to switch. • Near end detects a defect and switches, but the far end fails to switch due to malfunction after receiving RDI (or equivalent). • Improper provisioning causing mismatch in regard to revertive and non-revertive modes at near end and far end, eventually causing switch configuration mismatch.

  5. PBB-TE Protection Switching Requirements • Detection of mismatches by the protection switching process can be accomplished through transfer of info on switch positions at end points, using the TE connection(s). • Protection switching process internal detection of mismatches can avoid the need to seek action through an OSS/NMS (unless actually needed) • Faster overall protection process possible • OSS/NMS availability at the time when needed? • OSS/NMS solution likely to be complex, or more costly than protection switching process solution • Overall, standardized signaling of protection switching processes on the TE link(s) is a single domain solution that can also minimize issues associated with multiple domains. • [In recognizing that the scope of 802.1Qay is limited to single domain solutions, the development of single domain solutions that can be compatible with multiple domain solutions, or at least not complicate multiple domain solutions, should be a goal in developing 802.1Qay, as well as other 802.1 standards]

  6. PBB-TE Protection Switching Requirements • Additional Considerations • End to end protection switching process communication over TE paths must be straightforward and robust. Equipment providers implementing the protection switching standards must be committed to interoperability: • Avoid the early SONET ring interoperability example where protocol mismatches ( the “proprietary short stack”, for example, or other SONET DCC mismatches) caused protection switching interoperability issues1. 1White Paper, DCC Solutions for SONET/SDH Systems, OpenCon Systems Inc. October 2003

  7. PBB-TE Protection Switching Requirements Summary • Reliable - Post-protection-switching PBB-TE protection bridge configurations must be audited to ensure compatible operation took place at both ends following a switch • Self Correcting - Following detection of a bridge/selector mismatch, an attempt to correct the mismatch must be made by the 802.1 protection switching process. Failing such correction, the mismatch must be reported by the protection switching process to an OSS/NMS, enabling the bridge/selector mismatch to be cleared by a network operator. • Minimal Complexity - End to end protection switching process communication over TE paths must be straightforward and robust. • Future Proof - Although recognizing that the scope of 802.1Qay is limited to single domain solutions, the development of single domain solutions that can be compatible with multiple domain solutions, or at least not complicate multiple domain solutions, should be a goal in developing 802.1Qay, as well as other 802.1 standards.

More Related