RNI Requirements Imposed by
PBB-TE
M Vinod Kumar
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
1
Recap of Major Ideas
1. new-alon-INSP-NNI-protection-11-10-v01.pdf
2. new-haddock-resilient-network-interconnectLAG-0910-v3b.pdf
3. new-nfinn-LACP-vs-buffer-networks-1110-v1.pdf
4. new-vinod-ENNI-Protection-0310-v03.pptx
5. new-farkas-network-interconnect-resiliencyrequirements-0710-v02.pdf
6. new-farkas-network-interconnect-resiliencyrequirements-0710-v02.pdf
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
2
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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
3
RNI node
=
Topology
RNI Peers
O
8
M:N
|M:N|
RNI Adjacent
|8|
When few RNI Adjacent nodes are connected then we prefix Partial, e.g. |8
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
4
NNI Deployment
• Two types NNI deployment
– Same building
– Different buildings
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
5
Deployed in Same Building
1
2
Building of
Operator 1
1
Building of
Operator 1
Ex
Building of
Exchange
Operator
2
Building of
Operator 2
Exchange is high available device
1. simple patch panel or
2. switch
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
6
Deployed in Different Building
1
Building of
Operator 1
Fiber of
Operator 1
2
Building of
Operator 2
1
Building of
Operator 1
Client
7/26/2016
Fiber of
Operator 2
IEEE Interim Jan 2011, Kauai, Hawaii
2
Building of
Operator 2
Server
7
• Which deployment problem are we trying to
solve?
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
8
Ten Requirements
1. Should work for both Connection-Oriented as well as connection-less technology.
Every prez is pretty much focused on connection-less
2. Protection from node and link failure of RNI, and infrastructure segment failure
in the operator network be supported
3. Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at
RNI
4. Bundling and unbundling of I-SIDs from multiple B-VIDs over the RNI. If B-BEB is
allowed then bundling is allowed.
5. No change to Customer Frames
6. Traffic should never be lost when alternate path is available
7. 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.
8. Deterministic QoS for PBB-TE means we cannot use Routing/Switching at RNI.
We must use Protection mechanisms at the RNI for PBB-TE.
9. Source Address translation at RNI nodes. This would require modification to BBEBs for RNI
10. Sub-50 msec
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
9
Protection Scopes
• Three types of protection
– Node
– Link
– Infrastructure Segment or Service path within
operator
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
10
RNI Link Failure
Op1
L2 Service
Customer
C1
ENNI
Work
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
Op2
L2 Leased
Line
L2 Network
Protect
1. Working-ENNI fails  traffic switches to
protection-ENNI
• Protection-ENNI could be defined
over the topologies mentioned
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
Carrier
Ethernet/
EoSDH
C2
Fault
Notification
11
RNI Node Failure
Op1
L2 Service
Customer
C1
ENNI
Work
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
Op2
L2 Leased
Line
L2 Network
Protect
Carrier
Ethernet/
EoSDH
C2
Fault
Notification
RNI Node fault may lead to ENNI
protection
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
12
• 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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
13
Failure within Operator Network
Op1
L2 Service
Customer
C1
ENNI
Work
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
Op2
L2 Leased
Line
L2 Network
Protect
Carrier
Ethernet/
EoSDH
C2
Fault
Notification
Fault within the operator may lead to
triggering actions in other operator
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
14
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?
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
15
Technology Independent
Types of Technology
• Connection-oriented
• Connection-less
We need to specify how the definition
and working of PBB-TE is unaltered
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
16
Avoid Further Encapsulation of Data
Op1
L2 Service
Customer
C1
ENNI
Op2
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
L2 Network
Work
L2 Leased
Line
Protect
Carrier
Ethernet/
EoSDH
C2
Tunnelled
Carrier
Frames
No additional encapsulation at RNI nodes
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
Customer
Frames
Translation
17
of Frames
No Change to Customer Frames
Op1
L2 Service
Customer
C1
ENNI
Op2
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
L2 Network
Work
L2 Leased
Line
Protect
Carrier
Ethernet/
EoSDH
C2
Tunnelled
Carrier
Frames
No change to the customer frames
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
Customer
Frames
Translation
18
of Frames
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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
19
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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
20
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)
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
21
Forwarding Ambiguity
Op1
L2 Service
Customer
C1
ENNI
A Work
Op1
Carrier
Ethernet/
EoSDH
Op1
L2 Service
Customer
C
Op2
L2 Leased
Line
L2 Network
B
Protect
D
Carrier
Ethernet/
EoSDH
C2
Forwarding
Ambiguity
Fault
Notification
TESI stitching at the RNI nodes
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
22
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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
23
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.
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
24
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 PBBTE.
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
25
Source Address Translation
• Source Address translation at RNI nodes
1000
BMAC
1000
BMAC
Ex
1000
BMAC
7/26/2016
1000
BMAC
3000
Source
B-MAC
3000
BMAC
1000
BMAC
Network B ends up
learning many B-MAC and
this can be avoided
IEEE Interim Jan 2011, Kauai, Hawaii
4000
BMAC
1000
BMAC
1000
BMAC
26
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
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
27
Ten Requirements
1. Should work for both Connection-Oriented as well as connection-less technology.
Every prez is pretty much focused on connection-less
2. Protection from node and link failure of RNI, and infrastructure segment failure
in the operator network be supported
3. Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at
RNI
4. Bundling and unbundling of I-SIDs from multiple B-VIDs over the RNI. If B-BEB is
allowed then bundling is allowed.
5. No change to Customer Frames
6. Traffic should never be lost when alternate path is available
7. 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.
8. Deterministic QoS for PBB-TE means we cannot use Routing/Switching at RNI.
We must use Protection mechanisms at the RNI for PBB-TE.
9. Source Address translation at RNI nodes. This would require modification to BBEBs for RNI
10. Sub-50 msec
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
28
THANKS
7/26/2016
IEEE Interim Jan 2011, Kauai, Hawaii
29