[802.1CB TSN FRER] *FeatureReq*: Expand stream identification parameters for StreamDecoder

[olfline]

Hello dears 🙂

Problem
The StreamDecoder Module currently can decode an incoming stream by means of:

• VlanID
• pcpID
• Interface
• SrcMac
• DestMac

According to 802.1CB, further stream indicators are defined (see also screenshot of IEEE802.1CB-2017, Table 6-1):

• SrcIP
• DestIP
• dscpValue
• IpNext (Either UDP,TCP or SCTP)
• SrcPort
• DestPort

Feature Request
Implementation of additional stream identifiers (SrcIP, DestIP, dscpValue, IpNext, SrcPort, DestPort).
I am not sure whether this should be implemented in the StreamDecoder module as it is acting only at layer two at the moment.

Usecase
Imagine sending two different streams from one host to another with just different source/destination ports. The streams can only differentiated by the src/dest port.

What do you think about this?
Kind regards 🙂

[levy]

I think it makes sense to have something along these lines. I'm not sure about the implementation though. Perhaps it would be better to allow arbitrary packet filter expressions as in ContentBasedFilter for example. Then it would be possible to match for any protocol field or meta data of a packet as shown in PacketFilter_1.test

I'm not sure if this is really needs to be a StreamDecoder function though. Perhaps it's the function of the StreamIdentifier module, which is responsible for identifying the packets of the outgoing stream, and this module already supports arbitrary packet filter expressions. That is you can match for IP addresses, port numbers, etc. Even if we were doing the same with the StreamDecoder module, I don't see how that will work in the StreamEncoder part. If some module replace the stream identifier on the packet, how will this be reflected in IP addresses and port numbers?

So my question is this: are you sure that this functionality belongs to the StreamDecoder and not the StreamIdentifier module?

[olfline]

Hello levy!

First of all thanks for the superfast reply! I really appreciate your commitment! 😊

Why do I need this?

I do research on the PSFP topic.
So the PSFP module needs the streamTag and the streamTag is added by the StreamDecoder one step before the filtering.
I implemented your idea and replaced the StreamDecoder with the StreamIdentifier.

Expected behaviour

When using the StreamDecoder, the StreamInd Tag should be attached to the packet after passing the module.
When using the StreamIdentifier, the StreamReq Tag should be attached to the packet after passing the module.
The filter should just work fine, as it looks up the StreamInd and the StreamReq Tag.

Actual behaviour

When using the StreamDecoder, the StreamReq Tag is attached to the packets, before passing the module.

When using the StreamIdentifier, I can not see any Tag - neither StreamInd nor StreamReq - on the packet after passing the Module. Nevertheless, the StreamFilter is just working fine and pushes the packets to the right branch.

So good news is that I can do my research with the StreamIdentifier Module instead of the StreamDecoder.

Remaining questions

Nevertheless I am wondering:

1. Why is the StreamReq attached to packets when using the StreamDecoder even before passing the Module?
2. Why is there no StreamReq or StreamInd Tag displayed when using the StreamIdentifier, but the filter is just working fine?
3. Could it make sense to merge the StreamDecoder and the StreamIdentifier Module? They basically do the same, attach a Tag according to packet information.

For reproduction

omnet Version: 6.0.1
inet commit: 46a35a2
omnet.ini
omnet.ned

Thank you in advance 😊

[levy]

I think there's a slight misunderstanding about what is the function of the StreamIdentifier and StreamDecoder modules.

The StreamIdentifier module determines the stream of outgoing packets inside a TSN host. For example, an application generates UDP packets and the StreamIdentifier is configured to look at the IP destination address and the UDP destination port to determine which stream does the packet belong to. The StreamIdentifier attaches a StreamReq with the determined stream name to the packet in the bridging layer. Later on the StreamEncoder determines the 802.1 VLAN ID and PCP value for the given stream and the packet is transmitted to the wire.

In contrast, the StreamDecoder module determines the stream for incoming packets inside a TSN switch. For example, an incoming packet contains a specific 802.1 VLAN ID and PCP value, and the StreamDecoder attaches the stream identifier to the packet in the form of a StreamInd. When the packet is turned from incoming into outgoing packet in the TSN bridging layer, the StreamInd is turned into a StreamReq. Similarly to the above the StreamEncoder determines the 802.1 VLAN ID and PCP value for the outgoing packet.

For outgoing packets StreamReq specifies the requested stream identifier, for incoming packets StreamInd specifies the indicated stream identifier. The ingress stream filter for incoming packets is supposed to work based on the StreamInd, while the egress stream filter for outgoing packets is supposed to work based on the StreamReq.

[levy]

Forgot to answer your questions:

• 1: there should be a StreamInd attached after a StreamDecoder if the stream could be determined for the incoming packet
• 2: there should be a StreamReq attached after a StreamIdentifier if the stream could be determined for the outgoing packet
• 3: they are similar but they have different purpose and look at different parts of the packet and attach different kind of tags

[olfline]

Thanks for clearification!

Then I simply should not use the StreamIdentifier instead of the StreamDecoder as the packets will be mistagged.

But as I already stated out above the following problem arises:
Imagine a client, which sends two different streams with the same PCP an VID value through a switch to the same destination.
With the current implementation the decoder of the switch can not determine which stream one packet belongs to by looking at the PCP, VID, source, interface and destination values. As a result the PSFP can not apply different filter rules.

IMO, the arbitrary filter expression should be implemented into the StreamDecoder.
Vice Versa, the StreamEncoder could therefore attach/change arbitrary Packet options. I think this is not trivial with arbitrary filter expressions.
But for my use case the Stream Encoder won't need any modification.