How to continue with Qcc -...

How to continue with Qcc

New Data Objects & New Protocols

Presenter: Marcel Kießling, Siemens AG

Franz-Josef Goetz, Siemens AG

Juergen Schmitt – Siemens AG

17. June 2015

Requirements for Industrial networks

Protocols for a consistent network configuration & diagnostic information

Applications are independent from the network – multiple share it

17. June 2015

Recap: Task of MSRP in AVB networks

17. June 2015

Changed tasks in a TSN network

Original design of Qca: 1) Announcement of stream properties

Registration of more Stream properties with improved MSRP

2) Find path backwards to Talker in the RSTP network

Qca can be used to define forwarding paths

3) Check availability of resources on the path from Talker to Listener(s)

Resource Reservation and diagnostic information on the path

4) Accumulate latency on the path from Talker to Listerner

Min. and Max. Latency (for CB)

Proposal for a new mixed Desgin (Qca + MRP** + MSP**): 1) Announcement of stream descriptions

MSRP** for registration of more Streams and more Streams properties

(to support the new TSN mechanisms)

2) Registration on

o RSTP: MRP**

o Pre-calculated Path (e.g. Qca): MRP**

3) Check availability of resources on the path from Talker to Listener(s)

MSP** for reservation, state information and e2e signaling along the path

4) Accumulate latency on the path from Talker to Listener(s)

MSP** provides Min. and Max. Latency (for CB)

17. June 2015

MRP++ and MSP

Reasons for splitting Registration and Reservation

At the moment within the TSN group there is a discussion • How to “support more streams. The current worst case limit is less than 500 streams;

there are use cases that require two orders of magnitude greater than this.”

• How to get “deterministic stream reservation convergence.”

• …

(excerpt from the .1Qcc PAR)

The following slides

• explain registration

• explain signaling (reservation)

and show the difference also in the architecture between both

The current MSRP implementation expanded MRP to do both jobs

17. June 2015

Registration:

Properties:

• Attributes get synchronized between links (ISIS-like on link)

Details on the following slides …

• Synchronized data is constant (no modification within a Bridge) -> called “static” information in the TSN Telco's

• No creation of new Attributes -> propagation of the registered information in the network along the path

• Has to scale to larger amount of data

Fragmentation of PDU is necessary!

• Synchronized attribute propagation is the main focus

Main focus:

• Reliable synchronization of network attributes within an active topology given

by a context. (In contrast to ISIS where Attributes are flooded all over the

network to everybody)

17. June 2015

Registration: MRP++ Architecture

LLC LLC

Transmission ReceptionTransmission Reception

MAC Relay Entity

Participant

MRP-Application

MAD

Participant

MRP-Application

MAD

Dec

lare

/

Reg

iste

r

Dec

lare

/

Reg

iste

r

Dec

lara

tio

n-R

eque

st

Reg

iste

r-In

dica

tio

n

Declaratio

n-R

equest Reg

iste

r-In

dica

tio

n

Reg

iste

r-R

eque

st

Dec

lare

/

Reg

iste

r

Dec

lare

/

Reg

iste

r

D R

D R

D R

D R

D R D R

MAP

CONTEXT

D R

Reg

iste

r-In

dica

tio

n

D R

Reg

iste

r-In

dica

tio

n

D RD R

Register-

Request

D RD R

Participant

LLC

Transmission Reception

MAD

MRP-Application

Dec

lara

tio

n-R

eque

st

Reg

iste

r-In

dica

tio

n

D R

D R D R

D R

Dec

lare

/

Reg

iste

r

Dec

lare

/

Reg

iste

r

Participant

LLC


MAD

MRP-Application

Dec

lara

tio

n-R

eque

st

Reg

iste

r-In

dica

tio

n

D R

D R D R

D R

Dec

lare

/

Reg

iste

r

Dec

lare

/

Reg

iste

r

synchronizing Network Attributes (e.g. VLAN, MAC Address, Stream description, ...)

17. June 2015

One Registration Application (out of others) is

MSRP (Multiple Stream Registration Protocol)

Used to propagate the static properties of a stream along the path.

Such properties are for example:

• VID

• Max. frame size

• Frame priority

• Rank

• Stream-ID

• Tree-ID (for path)

• Stream destination MAC

• …

17. June 2015

Reservation (Signaling)

Properties:

• Directed from source to sink

• Attributes can get modified at every Hop

• Changes along the Path between source and sink has to be signaled very fast

• Attribute disappears if source withdraws or times-out

• Beside cyclic Link-To-Link synchronization, event based PDUs are necessary

Main focus:

• End-to-End signaling

• Monitoring the path between source and sink

• Fast signaling of changes along the path between source and sink

• Signal to source and sink what they get guaranteed along the path

17. June 2015

Basic MSP Architecture

LLC LLC


MAC Relay Entity

Participant Participant Participant

LLC


MAP

CONTEXT

Bridge-Global-Signalling application

MADMAD

TAttr LAttr

MAD

Participant

LLC


MAD

TAttr LAttr

Reservation synchronisation Reservation synchronisation Reservation synchronisationReservation synchronisation

Signalling application

TAttr LAttr TAttrLAttr TAttrLAttr TAttr LAttr

TAttrTAttr

LAttrLAttr

TAttrTAttr

LAttr

LAttr




Attribute SourceAttribute Sink

17. June 2015

One Signaling Application (out of others) is

MSSP (Multiple Stream Signaling Protocol)

Used to:

• propagate the dynamic properties of a stream along the path (Upstream

AND Downstream).

E.g.:

• Accumulated min. and max. Latency (Downstream)

• Required Latency (Upstream)

• Min. receive Interval (Upstream)

• Effective receive Interval (Downstream)

• Stream send state (Ready/Failed) (Downstream)

• Stream receive state (Ready/Failed/ReadyFailed) (Upstream)

• Use the event based messages to by-pass the slow cyclic Link-To-Link

synchronization to signal disruptive events on the path

(e.g. Link-Down due to wire break)

17. June 2015

MSSP Architecture (Multiple Stream Signaling based on the MSP-Architecture)

LLC LLC


MAC Relay Entity

Participant Participant Participant

LLC


MAP

CONTEXTMADMAD

TResTRes TRes TResLRes LRes LRes LRes

Reserved-Flow

MAD

TResLRes

Participant

LLC


MAD

TRes LRes

Reservation synchronisation Reservation synchronisation Reservation synchronisationReservation synchronisation

Stream Reservation Application

Merging

Policing

Admission Control

Stream Global Reservation Application

Admission Control

PolicingRes

Res


Merging

Policing

Admission Control

Res

Res


Merging

Policing

Admission Control


Merging

Policing

Admission Control

17. June 2015

Conclusion for

decentralized and centralized Approaches

Different proposals with general Requirements:

• Common Interface (UNI) between Application and TSN Networks

• Applications with own (higher layer) protocol for application configuration

should see no difference between centralized and decentralized organized networks!

• Shapers (including time-based forwarding) in the same physical network

Network control:

• Bridges can compute the paths (BLCEs) and do the local configuration (decentralized)

• PCEs can compute path and scheduling and remotely configure bridges (PCEP – centralized)

• Connection to Layer 3 (IETF DetNet?)

Both require a standardized network service for coordination

Registration and Reservation as network service

Diagnostic based on these available network information!

Tasks for Qcc:

• Adding new MRP data objects for control (TLV’s) to support new TSN features like redundancy

• Specifying new Managed Objects which are required to configure traffic classes

• Suggested new work item:

• Splitting Registration and Signaling into MRP** for registration and MSP** for signaling (reservation)

MRP with MSRP => MRP** with MSRP** and MSP** with MSSP**

17. June 2015

Requirements

TSN for Industrial Automation

Required functionality for industrial TSN networks

• Industrial networks are typically structured hierarchically

• Network segments must have the ability to work independently

• Separating and joining of network segments must be possible without losing connectivity within the

segment

• After power up dynamically communication relation will be establish

• The network must have the ability to add and remove network components and end stations at any time

• The network is shared between multiple control applications and other services

• Control applications and services can go up and down at any time

• The network must guarantee most possible independence between control applications

Static control applications mean not only static network configuration.

Static centralized network configuration will not at all fulfill the automation

requirements on industrial network!

17. June 2015

The following slide shows a

possible Future of de-/centralized Industrial Networks

based on the existing IEEE 802.1 Building Blocks

Description of a hierarchical structured industrial network: • PLC 1 Usec Case in VLAN 4

• E2E higher layer protcol to establish communication between PLC 1 and its actuators and sensors

• PLC 1 – Edge Bridge UNI interface

• Edge Bridge contains a PCE (centralized path computing) and supports PCEP+

• ISIS PCR for topology discovery / also the virtual topology of VLAN 4

• MRP ++ for distributed registration of “explicit tree”, stream description, VID, … along the “explicit tree”

• MSP for distributed reservation of resources, e2e signaling, .. along the “explicit tree”

• PLC 2 Usec Case in VLAN 5 • E2E higher layer protcol to establish communication between PLC 2 and its actuators and sensors


• Edge Bridge and all Bridges with the VLAN 5 contain a BLCE for decentralized path computing


• MRP ++ for distributed registration to nail down the path (MRRP), stream description, VID, … along the path

• MSP for distributed reservation of resources, e2e signaling, .. along the path

• PLC 3 Usec Case in VLAN 7 • E2E higher layer protcol to establish communication between PLC 3 and its actuators and sensors


• Edge Bridge contains a PCE (centralized path computing) and supports PCEP+


• MRP ++ for distributed registration of “explicit tree”, stream description, centralized “schedule”, VID, … along the

“explicit tree”

• MSP for distributed reservation of resources, e2e signaling, .. along the “explicit tree”

17. June 2015

Possible Future of de-/centralized Industrial Networks

based on the existing IEEE 802.1 Building Blocks

Endstation

S2ISSimple 2-Trunk

Intermediate System with

PCC-Function

NetworkManager

Centraliced UserConfigruation

1

2

3

4

BLCE (= Bridge-Local-Computing-Engine, distributed network control) + UNI Interface

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4

1

2

3

4 ISIS-PCRISIS-PCRISIS-PCR

Sensor Actuator

MSPMRP++

MSPMRP++

MSPMRP++

PLC 2 PLC 1

1

2

3

4 ISIS-PCR

MSPMRP++

1

2

3

4ISIS-PCRISIS-PCRS2IS

Sensor

S2IS

Actuator

MSPMRP++

MSPMRP++

ISIS-PCRMSP

MRP++ ISIS-PCR

MSPM

RP++

ISIS-PCR

MSPMRP++

ISIS-PC

R

MSP

MR

P++

ISIS-PC

R

MSP

MR

P++

PCE + Scheduling

PCEP+ Path-Computing-Element-Protcol

Intermediate-System-to-Intermediate-System with Path Computing and Registration

Multiple-Signaling-ProtocolMSP

ISIS-PCR

Multiple-Registration-ProtocolMRP++

PCEP+

PCEP+

Default VLAN

VLAN 4 for PLC 1-one application-


ISIS-PCRM

SP

MRP++

ISIS

-PCRMSP

MRP

++

ISIS-PC

R

MSP

MR

P++

Universal Network Interface Includes e.g. MRP (MMRP, MSRP, …) and LLDP, ...

UNI UN

I

UN

I

UN

I

UN

I

UN

I

Time aware Shaper is supported

1

2

3

4

1

2

3

4

Sensor

UNI

1

2

3

4

ISIS-PCRISIS-PCR

Sensor Actuator

MSPMRP++

MSPMRP++

UN

I

UN

I

UN

I

1

2

3

4

1

2

3

4

Sensor

1

2

3

4

PLC 3

higher layer E2E protocol



PCEP+



user specific higher layer E2E protocol

user specific higher layer E2E protocol

Field-Level

Control-Level

Plant-Level

Industrial AutomationCommunication Pyramid

UNI

UN

I

How to continue with Qcc -...

Documents

Transcript of How to continue with Qcc -...