1 / 12

PIRC Architecture July 2007 Plenary Session San Francisco Mike Takefman Cisco Systems

PIRC Architecture July 2007 Plenary Session San Francisco Mike Takefman Cisco Systems. My PIRC High Level Goals. Built on top of 802.17b MAC Assumption is an L2 switched network PIRC has to provide loop-free dual connectivity Multiple Load-Balancing methods

ceana
Download Presentation

PIRC Architecture July 2007 Plenary Session San Francisco Mike Takefman Cisco Systems

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. PIRC Architecture July 2007 Plenary Session San Francisco Mike Takefman Cisco Systems IEEE 802.17 RPRWG

  2. My PIRC High Level Goals • Built on top of 802.17b MAC • Assumption is an L2 switched network • PIRC has to provide loop-free dual connectivity • Multiple Load-Balancing methods • Compatible with non-PIRC stations • ideally no MAC or operational changes needed for other nodes • usable with existing standard product chips IEEE 802.17 RPRWG

  3. Where To Put Filtering • PIRC is essentially adding new filtering rules to the system • assumption is that ingress and egress filter rules exist • Our scope requires that these filtering rules exist in the MAC level, but the actual position is implementation dependant • side effect on whether 802.17b learning occurs • no easy way to arbitrarily allow or not allow learning • question is one of compliance • Tributary support requires egress filtering rules in addition to ingress rules IEEE 802.17 RPRWG

  4. Hash Filtering • Previous presentations have pointed out that certain constraints must be followed in order to insure connectivity • net result is that the basic hash function is based on outer VLAN • hence this form of hash filtering is essentially VLAN filtering and any other hashing function is by definition proprietary IEEE 802.17 RPRWG

  5. 2 Span Failure Scenarios • It has been suggested that PIRC support both 1 and 2 span failures • it must be assumed that the network is otherwise loop free • 2 cuts on a leaf ring is trivial as a loop cannot be created • 2 cuts on an intermediate ring is more interesting and has a few cases D C B A IEEE 802.17 RPRWG

  6. 2 Span Failure Scenarios • Isolated Node • no connectivity to that node • no loops created • Nothing can be done, and there are no PIRC issues D C B A IEEE 802.17 RPRWG

  7. 2 Span Failure Scenarios • Isolated Neighbour Ring • no connectivity to that sub-tree • no loop created • Nothing can be done, and there are no PIRC issues D C B A IEEE 802.17 RPRWG

  8. 2 Span Failure Scenarios • Isolated Partial Ring • full connectivity possible • no loop created • PIRC could restore connectivity • A&B operated normally • D&C both do full forwarding D C B A IEEE 802.17 RPRWG

  9. 2 Span Failure Scenarios • Split Ring • full connectivity possible BUT • loop created with current suggested PIRC filtering • PIRC could restore connectivity • A&B, C&D forward everything from neighbour ring to “broken ring” • one of A|B, C|D forward to neighbour ring • never forward back from mate • done with egress filtering if tribs are needed else ingress D C B A IEEE 802.17 RPRWG

  10. 2 Span Failure Scenarios • How to recognize split ring? Nodes on affected ring observe • mate has disappeared on one ring but not the other D C B A IEEE 802.17 RPRWG

  11. 2 Span Failure Scenarios • Does the split ring scenario scale to 3 PIRC pairs? • A&B,C&D are partially isolated from B&E • A&B is split from C&D • the problem is that the split rules are different from the partially isolated rules • implies you need to apply rules based on ringSA -> YUCK D C B E F A IEEE 802.17 RPRWG

  12. Conclusions • Dual Failure scenario can only be handled for limited cases • likely not worth doing IEEE 802.17 RPRWG

More Related