120 likes | 232 Views
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
E N D
PIRC Architecture July 2007 Plenary Session San Francisco Mike Takefman Cisco Systems IEEE 802.17 RPRWG
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
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
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
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
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
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
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
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
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
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
Conclusions • Dual Failure scenario can only be handled for limited cases • likely not worth doing IEEE 802.17 RPRWG