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

2. IEEE Interim Jan 2011, Kauai, Hawaii
Recap of Major Ideas
new-alon-INSP-NNI-protection 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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

3. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

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

5. IEEE Interim Jan 2011, Kauai, Hawaii
NNI Deployment
Two types NNI deployment
Same building
Different buildings
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

6. Deployed in Same Building1 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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

7. Deployed in Different Building1 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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

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

9. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

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

11. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

12. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

13. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

14. Failure within Operator Network
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

15. IEEE Interim Jan 2011, Kauai, Hawaii
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?
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

16. Technology Independent
Types of Technology
Connection-oriented
Connection-less
We need to specify how the definition and working of PBB-TE is unaltered
11/12/2018
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
11/12/2018
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

19. IEEE Interim Jan 2011, Kauai, Hawaii
Avoid MAC-in-MAC-in-MAC encapsulation at RNI
Because for PBB-TE and PBB it doesn’t make sense; it would lead to loss in throughput due to third MAC header.
Expensive equipment as it will be IB-BEB
Cant re-use existing Bridges with software upgrades
However, can use B-BEBs at RNI
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

20. IEEE Interim Jan 2011, Kauai, Hawaii
Bundling
Bundling and unbundling of I-SIDs from multiple B-VIDs over the RNI.
If B-BEB is allowed at the RNI then bundling is possible
Expensive equipment as it is B-BEB
Cant re-use existing Bridges with software upgrades
Should not change QoS of PBB-TE. For PBB, it is ok
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

21. IEEE Interim Jan 2011, Kauai, Hawaii
Avoid Traffic Loss
Traffic should never be lost when alternate path is available
What this means for PBB-TE? : choose as many better TESI segments to provide service continuity. That is, if w1 and p1 are the work and protect TESIs on operator 1, and w2 and p2 are on operator 2, if w1 fails then end-to-end path could be p1-ENNI-w2 as this might be better than p1-ENNI-p2.
However, don’t allow arbitrary switching within ENNI.
Should handle forwarding ambiguity for above. For PBB-TE, node B will have two paths at node B. One towards C and another towards D (See next slide for figure)
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

22. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

23. IEEE Interim Jan 2011, Kauai, Hawaii
Avoid Traffic Loss
Traffic should never be lost when alternate path is available
What this means for PBB-TE? : choose as many better TESI segments to provide service continuity. That is, if w1 and p1 are the work and protect TESIs on operator 1, and w2 and p2 are on operator 2, if w1 fails then end-to-end path could be p1-ENNI-w2 as this might be better than p1-ENNI-p2.
However, don’t allow arbitrary switching within ENNI.
Should handle forwarding ambiguity for above. For PBB-TE, node B will have two paths at node B. One towards C and another towards D
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

24. Block Traffic Towards Interconnect when Complete Interconnect Failure
Don’t send traffic if RNI is always failed.
Instead use this feature to free up bandwidth on operator 1 and operator 2 network for other internal services.
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

25. Deterministic QoS for PBB-TE
Deterministic QoS for PBB-TE means we cannot use Routing/Switching at RNI. We must use Congruent Protection mechanisms at the RNI for PBB-TE.
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

26. Source Address Translation
Source Address translation at RNI nodes
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

27. IEEE Interim Jan 2011, Kauai, Hawaii
50 ms
Carrier-grade services demand 50 ms resiliency
Introducing many encapsulation and components on the path between RNI nodes, whether adjacent or peer, may need to be avoided
Bundling might have to be avoided at the RNI as detecting I-SIDs-to-VID mapping in a bundled service and triggering fault notifications towards the source will be processor intensive and 50 ms might not be guaranteed for all services
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

28. IEEE Interim Jan 2011, Kauai, Hawaii
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
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii

29. IEEE Interim Jan 2011, Kauai, Hawaii
Thanks
11/12/2018
IEEE Interim Jan 2011, Kauai, Hawaii