802'1Qay Protection Switching

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.