RNI Requirements Imposed by PBB-TE

1. RNI Requirements Imposed by PBB-TE M Vinod Kumar IEEE Interim Jan 2011, Kauai, Hawaii

2. Recap of Major Ideas new-alon-INSP-NNI-protection-11-10-v01.pdf new-haddock-resilient-network-interconnect-LAG-0910-v3b.pdf new-nfinn-LACP-vs-buffer-networks-1110-v1.pdf new-vinod-ENNI-Protection-0310-v03.pptx new-farkas-network-interconnect-resiliency-requirements-0710-v02.pdf new-farkas-network-interconnect-resiliency-requirements-0710-v02.pdf IEEE Interim Jan 2011, Kauai, Hawaii

3. Introduction • Here we consider the requirements that RNI has to satisfy when PBB-TE services flow over them • Note: PBB-TE multi-domain standard does not exist • If we want RNI to protect connection-oriented service then this presentation brings forth the challenges to be addressed • Else, we can keep PBB-TE explicitly out of scope • Nevertheless, this presentation will enable writing clear PAR statements and 5Cs IEEE Interim Jan 2011, Kauai, Hawaii

4. Topology RNI node RNI Peers = 8 O RNI Adjacent |8| M:N |M:N| When few RNI Adjacent nodes are connected then we prefix Partial, e.g. |8 IEEE Interim Jan 2011, Kauai, Hawaii

5. NNI Deployment • Two types NNI deployment • Same building • Different buildings IEEE Interim Jan 2011, Kauai, Hawaii

6. Deployed in Same Building 1 2 Building of Operator 1 1 Ex 2 Building of Operator 1 Building of Operator 2 Building of Exchange Operator Exchange is high available device simple patch panel or switch IEEE Interim Jan 2011, Kauai, Hawaii

7. Deployed in Different Building 1 2 Fiber of Operator 1 Building of Operator 1 Building of Operator 2 1 2 Fiber of Operator 2 Building of Operator 1 Client Building of Operator 2 Server IEEE Interim Jan 2011, Kauai, Hawaii

8. Which deployment problem are we trying to solve? IEEE Interim Jan 2011, Kauai, Hawaii

9. Ten Requirements • Should work for both Connection-Oriented as well as connection-less technology. Every prez is pretty much focused on connection-less • Protection from node and link failure of RNI, and infrastructure segment failure in the operator network be supported • Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at RNI • Bundling and unbundling of I-SIDs from multiple B-VIDs over the RNI. If B-BEB is allowed then bundling is allowed. • No change to Customer Frames • Traffic should never be lost when alternate path is available • Don’t send traffic if RNI is always failed. Instead use this feature to free up BW on operator 1 and operator 2 network for other internal services. • Deterministic QoS for PBB-TE means we cannot use Routing/Switching at RNI. We must use Protection mechanisms at the RNI for PBB-TE. • Source Address translation at RNI nodes. This would require modification to B-BEBs for RNI • Sub-50 msec IEEE Interim Jan 2011, Kauai, Hawaii

10. Protection Scopes • Three types of protection • Node • Link • Infrastructure Segment or Service path within operator IEEE Interim Jan 2011, Kauai, Hawaii

11. RNI Link Failure Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line Work C1 C2 Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH Protect Fault Notification • Working-ENNI fails  traffic switches to protection-ENNI • Protection-ENNI could be defined over the topologies mentioned IEEE Interim Jan 2011, Kauai, Hawaii

12. RNI Node Failure Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line Work C1 C2 Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH Protect Fault Notification RNI Node fault may lead to ENNI protection IEEE Interim Jan 2011, Kauai, Hawaii

13. In case of ‘=’ topology failure of link/node triggers action in both the operators. • This behaviour should be allowed • Similar behaviour is valid for any RNI node failure as it triggers action in adjoining operator network IEEE Interim Jan 2011, Kauai, Hawaii

14. Failure within Operator Network Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line Work C1 C2 Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH Protect Fault Notification Fault within the operator may lead to triggering actions in other operator IEEE Interim Jan 2011, Kauai, Hawaii

15. What are we doing? Protection of the interconnects? OR Protection of end-to-end services flowing over the interconnect by doing something nice at the interconnect nodes? IEEE Interim Jan 2011, Kauai, Hawaii

16. Technology Independent IEEE Interim Jan 2011, Kauai, Hawaii

17. Avoid Further Encapsulation of Data Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line C1 C2 Work Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH Protect Tunnelled Carrier Frames No additional encapsulation at RNI nodes Customer Frames Translation of Frames IEEE Interim Jan 2011, Kauai, Hawaii

18. No Change to Customer Frames Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line C1 C2 Work Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH Protect Tunnelled Carrier Frames No change to the customer frames Customer Frames Translation of Frames IEEE Interim Jan 2011, Kauai, Hawaii

19. IEEE Interim Jan 2011, Kauai, Hawaii

20. Bundling IEEE Interim Jan 2011, Kauai, Hawaii

21. Avoid Traffic Loss IEEE Interim Jan 2011, Kauai, Hawaii

22. Forwarding Ambiguity Op1 L2 Service Customer Op1 L2 Service Customer ENNI Op1 L2 Network Op2 L2 Leased Line A Work C C1 C2 Carrier Ethernet/ EoSDH Carrier Ethernet/ EoSDH B D Protect Forwarding Ambiguity Fault Notification TESI stitching at the RNI nodes IEEE Interim Jan 2011, Kauai, Hawaii

23. Avoid Traffic Loss IEEE Interim Jan 2011, Kauai, Hawaii

24. Block Traffic Towards Interconnect when Complete Interconnect Failure IEEE Interim Jan 2011, Kauai, Hawaii

25. Deterministic QoS for PBB-TE IEEE Interim Jan 2011, Kauai, Hawaii

26. Source Address Translation 1000 B-MAC 1000 B-MAC 3000 Source B-MAC 3000 B-MAC 4000 B-MAC 1000 B-MAC 1000 B-MAC 1000 B-MAC Ex 1000 B-MAC 1000 B-MAC Network B ends up learning many B-MAC and this can be avoided • Source Address translation at RNI nodes IEEE Interim Jan 2011, Kauai, Hawaii

27. 50 ms IEEE Interim Jan 2011, Kauai, Hawaii

28. Ten Requirements • Should work for both Connection-Oriented as well as connection-less technology. Every prez is pretty much focused on connection-less • Protection from node and link failure of RNI, and infrastructure segment failure in the operator network be supported • Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at RNI • Bundling and unbundling of I-SIDs from multiple B-VIDs over the RNI. If B-BEB is allowed then bundling is allowed. • No change to Customer Frames • Traffic should never be lost when alternate path is available • Don’t send traffic if RNI is always failed. Instead use this feature to free up BW on operator 1 and operator 2 network for other internal services. • Deterministic QoS for PBB-TE means we cannot use Routing/Switching at RNI. We must use Protection mechanisms at the RNI for PBB-TE. • Source Address translation at RNI nodes. This would require modification to B-BEBs for RNI • Sub-50 msec IEEE Interim Jan 2011, Kauai, Hawaii

29. Thanks IEEE Interim Jan 2011, Kauai, Hawaii