Choosing kind of forwarding

[openBackhaul]

Some devices are supporting:

1. exclusive forwarding based on bare MAC switching
2. exclusive forwarding based on MAC switching inside VLANs
3. forwarding based on bare MAC switching and on MAC switching inside VLANs in parallel.

In some cases kind of forwarding is even a matter of port by port configuration.

(1) Means that VlanInterfaces would not exist and EthernetContainers would be connected to an EthernetContainerFD and zero or one EthernetContainerFCs.

(2) Means that VlanInterfaces would exist, be connected to a VlanFd and be connect to zero, one or multiple VlanFcs. At the same time the serving EthernetContainer would exist, but not be connected to an EthernetContainerFD (and consequently not be connected to any EthernetContainerFC).

(3) Means that VlanInterfaces would exist, be connected to a VlanFd and be connect to zero, one or multiple VlanFcs. At the same time the serving EthernetContainers would exist, and the EthernetContainers would be connected to an EthernetContainerFD and zero or one EthernetContainerFCs.

As the behavior is configurable at port level at some devices, a method for triggering the device to create/delete the respective objects (e.g. VlanInterface, EthernetContainerFcPorts etc.) on the management interface must be defined.

Adding the following artifacts to the EthernetContainer modelling might be an option:

• Enumeration datatype ForwardingKindType with values {FRAME_BASED_FORWARDING_ONLY, VLAN_BASED_FORWARDING_ONLY, FRAME_AND_VLAN_BASED_FORWARDING, NOT_YET_DEFINED, NONE}.

• EthernetContainerCapability::availKindsOfForwarding:ForwardingKindType [*].

• EthernetContainerConfiguration::kindOfForwarding:ForwardingKindType [1]. (In case a device would just support one of the aforementioned modes, the attribute would represent that and just not allow changing it.)

• EthernetContainerStatus::currentKindOfForwarding:ForwardingKindType [1].

[openBackhaul]

Discussion on 6th of September 2023:
Changing the kind of forwarding would require creation and deletion of objects (e.g. FcPorts).
Would have to be decided, whether to apply an RPC instead of a bare configuration attribute.

[niloda]

Some devices support the bullet 2. "exclusive forwarding based on MAC switching inside VLANs" however requiring to configure packet forwarding per port.

For these devices, packets are forwarded only if the ports belonging to the VLAN are enabled to send traffic between them.

For this purpose, each input port has the ability to enable a set of output ports to send traffic to, creating a so called port based VLAN. In the TR-532 model port based VLAN would be represented by the EthernetContainerFCs.

In order for ehernrtContainer model to cover these devices as well, it is proposed to add the VLAN_BASED_FORWARDING enumeration to the ForwardingKindType.

When EthernetContainerConfiguration::kindOfForwarding:ForwardingKindType is set to VLAN_BASED_FORWARDING, the configuration to be implemented is necessarily the one described in point (3) to allow both the creation of the VLANs and to enable a set of ports to send traffic between them.

In summary, VlanFcs are used to create VLANs while EthernetContainerFC are used to enable ports to send traffic between them.

[openBackhaul]

Discussion on 26th of September 2023:
The following two kinds of forwarding have been stated to be implemented on existing microwave devices:

• forwarding based on MAC switching inside VLANs
• point2point frame forwarding
• (Danilo was not present, so a third kind of forwarding might need to be covered, too)

Forwarding based on MAC switching inside VLANs is the default configuration on the devices.

Changing to point2point frame forwarding could be initiated by calling an RPC configureLayer1Connection(LtpUuid1, LtpUuid2).
This RPC would

• create
  • an EthernetContainerFC,
  • two EthernetContainerFcPorts that are referencing the two EthernetContainer LTPs that are defined in the input.
• delete
  • the two VlanFdPorts that are referencing the two VlanInterface LTPs that are clients to the two EthernetContainer LTPs that are defined in the input.
  • all VlanFcPorts that are referencing the same VlanInterface LTPs.

Dismantling the point2point frame forwarding could be initiated by calling an RPC dismantleLayer1Connection(FcUuid).
This RPC would inverse above changes except creating the VlanFcPorts.

As these RPCs would be executed on FDs further details will be developed in the EthernetContainer modeling.

[demx8as6]

For EthernetContainerFC creation please see existing issue: #2