Download
rni requirements imposed by pbb te n.
Skip this Video
Loading SlideShow in 5 Seconds..
RNI Requirements Imposed by PBB-TE PowerPoint Presentation
Download Presentation
RNI Requirements Imposed by PBB-TE

RNI Requirements Imposed by PBB-TE

148 Vues Download Presentation
Télécharger la présentation

RNI Requirements Imposed by PBB-TE

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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