rni requirements imposed by pbb-te

29
RNI Requirements Imposed by PBB-TE M Vinod Kumar 06/18/2022 IEEE Interim Jan 2011, Kauai, Hawaii 1

Upload: cedric-wilson

Post on 31-Dec-2015

32 views

Category:

Documents


1 download

DESCRIPTION

RNI Requirements Imposed by PBB-TE. M Vinod Kumar. 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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 1

RNI Requirements Imposed by PBB-TE

M Vinod Kumar

Page 3: RNI Requirements Imposed  by PBB-TE

04/19/2023 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

Page 4: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 4

Topology

= O

|8|

8

|M:N|M:N

RNI node

RNI Peers

RNI Adjacent

When few RNI Adjacent nodes are connected then we prefix Partial, e.g. |8

Page 5: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 5

NNI Deployment

• Two types NNI deployment– Same building

– Different buildings

Page 6: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 6

Deployed in Same Building

1

2

Building of Operator 1 Ex 2

Building of Exchange Operator

1

Building of Operator 1

Building of Operator 2

Exchange is high available device1. simple patch panel or 2. switch

Page 7: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 7

Deployed in Different Building

2Fiber of Operator 1

1

Building of Operator 1

Building of Operator 2

2Fiber of Operator 2

1

Building of Operator 1Client

Building of Operator 2Server

Page 8: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 8

• Which deployment problem are we trying to solve?

Page 9: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 9

Ten Requirements1. Should work for both Connection-Oriented as well as connection-less technology.

Every prez is pretty much focused on connection-less2. Protection from node and link failure of RNI, and infrastructure segment failure

in the operator network be supported3. Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at RNI4. 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 Frames6. Traffic should never be lost when alternate path is available7. 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 B-

BEBs for RNI10. Sub-50 msec

Page 10: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 10

Protection Scopes

• Three types of protection– Node– Link – Infrastructure Segment or Service path within

operator

Page 11: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 11

RNI Link Failure

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

1. Working-ENNI fails traffic switches to protection-ENNI• Protection-ENNI could be defined

over the topologies mentioned

ENNI

Work

Protect

FaultNotification

Page 12: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 12

RNI Node Failure

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

RNI Node fault may lead to ENNI protection

ENNI

Work

Protect

FaultNotification

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

Page 13: RNI Requirements Imposed  by PBB-TE

04/19/2023 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

Page 14: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 14

Failure within Operator Network

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

Fault within the operator may lead to triggering actions in other operator

ENNI

Work

Protect

FaultNotification

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

Page 15: RNI Requirements Imposed  by PBB-TE

04/19/2023 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?

Page 16: RNI Requirements Imposed  by PBB-TE

04/19/2023 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

Page 17: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 17

Avoid Further Encapsulation of Data

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

No additional encapsulation at RNI nodes

ENNI

Work

Protect

TunnelledCarrierFrames

CustomerFrames

Translation of Frames

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

Page 18: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 18

No Change to Customer Frames

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

No change to the customer frames

ENNI

Work

Protect

TunnelledCarrierFrames

CustomerFrames

Translation of Frames

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

Page 19: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 19

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

Page 20: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 20

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

Page 21: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 21

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)

Page 22: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 22

B

Forwarding Ambiguity

Op1L2 Network

Op2L2 Leased

LineC1 C2Carrier

Ethernet/EoSDH

Carrier Ethernet/

EoSDH

TESI stitching at the RNI nodes

ENNI

Work

Protect

FaultNotification

Forwarding Ambiguity

A C

D

Op1L2 ServiceCustomer

Op1L2 ServiceCustomer

Page 23: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 23

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

Page 24: RNI Requirements Imposed  by PBB-TE

04/19/2023 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.

Page 25: RNI Requirements Imposed  by PBB-TE

04/19/2023 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.

Page 26: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 26

Source Address Translation

• Source Address translation at RNI nodes

Ex

1000 B-

MAC

1000 B-

MAC

1000 B-

MAC

3000 Source B-MAC 4000

B-MAC

1000 B-

MAC

1000 B-

MAC

1000 B-

MAC

3000 B-

MAC

1000 B-

MAC

Network B ends up learning many B-MAC and this can be avoided

Page 27: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 27

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

Page 28: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 28

Ten Requirements1. Should work for both Connection-Oriented as well as connection-less technology.

Every prez is pretty much focused on connection-less2. Protection from node and link failure of RNI, and infrastructure segment failure

in the operator network be supported3. Avoid MAC-in-MAC-in-MAC encapsulation at RNI. However, can use B-BEBs at RNI4. 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 Frames6. Traffic should never be lost when alternate path is available7. 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 B-

BEBs for RNI10. Sub-50 msec

Page 29: RNI Requirements Imposed  by PBB-TE

04/19/2023 IEEE Interim Jan 2011, Kauai, Hawaii 29

THANKS