Link loss forwarding should be related to one or more air-interface

[niloda]

With link loss forwarding enabled, the mac interface must be shut down when the radio link is down. This is easy to implement when the device has only one radio link. In the figure below, when the radio link goes down, the three interfaces should be shut down, stopping the three services (red, blue and green)

With multiple radio links, you should specify which one shuts down the specific mac interface, otherwise any alarmed link could shut down all mac interfaces on the device, even those not receiving traffic from the alarmed link. In the figure below, in a device with 3 radio interfaces, the two services (red and green) outgoing from LAN-3 flow over two different microwave links, while the service (blue) outgoing from LAN-1 flows over a third microwave link.

The question is which LAN interface should be shut down when which radio link is down. Of course, a problem on MW-LINK-3 should shut down LAN-1 only, but a problem on MW-LINK-1 and MW-LINK-2 (one or both?) should shut down LAN-3. LAN-2 should not be affected by any radio link even if link loss forwarding is enabled.

In addition, considering the complete link, not just one end-point, should the los alarm of the remote interface from which the service enters be forwarded? For example, in the figure below, should LAN-1 be shut down in response to a los alarm on the remote interface LAN-3? This allows to forward the los in a chain of radio links.

The problem is that the current model:

• does not allow nor to associate one or more radio links (air-interface) to the mac interface
• does not allow selecting whether one or all radios sending traffic to the mac interface should be down to shut down the mac-interface.
• doesn't foresee the forwarding of the loss on a remote interface (if the functionality is considered useful)

[niloda]

A proposal to complete the functionality could be:

• add a list (named LinkLosForwardingAirInterfaceList) of LTPs whose layer-protocol-name is air-interface:LAYER_PROTOCOL_NAME_TYPE_AIR_LAYER. This list contains the air-interfaces which send/receive traffic to/from the mac-interface.
• add an attribute (named LinkLosForwardingMode) whose value selects whether the LOS should be propagated if at least one LTP or all the LTPs in the previous list are in fault.

If we wanted to allow LOS forwarding in a chain of radio links (last figure of the previous comment), the device would have to know the status of the remote ports. Currently the TR-532 model does not provide this, so important changes would be required. Therefore, we could postpone the solution of this part of the issue to a possible step 2, of course if it were worth it.

[openBackhaul]

Alternative proposal - "On top of EthernetContainer":

The following proposal requires that the operational state of a client layer interface is regarding the operational state of its serving layer interface(s).
If there is a 1:1 relationship, it is required that the operational state of a client LTP is down, whenever the operational state of its server LTP is down.
If there is a 1:n relationship (e.g. physical link aggregation), it is required that the operational state of the client LTP is down, whenever the operational states of all its server LTPs is down.

• It is proposed to introduce LinkLossForwardingInterface, LinkLossForwardingFd and LinkLossForwardingFc modellings.
• The LinkLossForwardingInterface LTP shall be client to the EthernetContainer LTP and server to the MacInterface LTP. Both shall be 1:1 relationships.
• The value of the operational state attribute (interfaceIsUp) of the LinkLossForwardingInterface LTP shall be determined by the value of the same attribute at its underlying EthernetContainer LTP.
• The LinkLossForwardingInterface shall contain a LinkLossForwardingIsOn : Boolean configuration attribute.
• All LinkLossForwardingInterface LTPs shall be listed in the LinkLossForwardingFd.
• The LinkLossForwardingFc shall be modeled with FcPorts for expressing direction.
• The implementations of the LinkLossForwardingFc shall allow defining one input, but multiple output.
• If the LTP at the input of a LinkLossForwardingFc would be configured LinkLossForwardingIsOn==true and operational state would be interfaceIsUp==false, all output LTPs with LinkLossForwardingIsOn==true would automatically change into interfaceIsUp==false, too.
• The new operational state of the LinkLossForwardingInterface LTPs shall be propagated to their respective client MacInterface LTPs.

This modelling shall be supported on management interfaces of devices that are supporting LinkLossForwarding configuration. If some device would not support LinkLossForwarding the MacInterface would keep being client of the EthernetContainer LTP.

[demx8as6]

Many thanks again!!! Topic is on the agenda for tomorrow. Cheers,MartinGesendet von Outlook für Android

[openBackhaul]

Decision during the 5G-xhaul call to the 13th of December 2023:

The following proposal would have to be implemented, if the device supports flexibly defining relationships between interfaces that are suffering from link loss and interfaces shall shall be switched off because of this event.

It requires that the mediator implementation can handle multiple LPs at an LTP.
The operational state information would be propagated in lateral direction between interfaces of different kinds (AirInterface and WireInterface).

• It is proposed to introduce LinkLossForwardingInterface, LinkLossForwardingFd and LinkLossForwardingFc modellings.

LinkLossForwardingInterface

• The LinkLossForwardingInterface LPs shall be associated to all LTPs that are already associating an AirInterface or a WireInterface LP.
• The LinkLossForwardingInterface shall contain a LinkLossForwardingIsOn : Boolean configuration attribute. This attribute shall hold the following comment: "true: the interface is sending its LTP's operational status information into a LinkLossForwardingFc, if defined to be an input of that LinkLossForwardingFc; and the interface is putting its LTP's operational status to down, if receiving an operational status down from a LinkLossForwardingFc, in which it is defined to be an output,"

LinkLossForwardingFd

• All LTPs with a LinkLossForwardingInterface LP associated shall be listed in the LinkLossForwardingFd.
• The LinkLossForwardingFd shall provide RPCs for creating and deleting LinkLossForwardingFcs.
  • createLinkLossForwardingFc( in _affectedLinkLossForwardingFd:FD[1], in _inputInterfaceList:LTP[*], in condition:ConditionType[1], in _outputInterfaceList:LTP[*], out _createdLinkLossForwardingFc:FC[1] ) with ConditionType = {OR, AND}
  • deleteLinkLossForwardingFc( in _affectedLinkLossForwardingFd:FD[1], in _obsoleteLinkLossForwardingFc:FC[1] )

LinkLossForwardingFc

• The LinkLossForwardingFc shall be modeled with FcPorts for expressing direction.
• If the LTP at the input of a LinkLossForwardingFc would be configured LinkLossForwardingIsOn==true and operational state would be interfaceIsUp==false, all output LTPs with LinkLossForwardingIsOn==true would automatically change into interfaceIsUp==false, too.

[demx8as6]

The proposal for next Dec6th should be postponed to Dec13 to gather more feedback.

In addition a discussion is beneficial about the creation and deletion of LinkLossForwardingFc . RPC?

[openBackhaul]

Proposal above has been complemented accordingly.