IF Interface

[openBackhaul]

As a part of the harmonization of an Ethernet based connection between IDU and ODU, the current practice of connecting IDU and ODU by IF cable shall be documented in the ONF TR-532 document (respectively its future version in the LinuxFoundation).

Proposal to the LF ONMI x-haul call on 16th of October 2024:
(objected during call at 15th of October 2024)

• A new chapter 6.6 Connecting ODUs shall be added to the existing chapter 6 Special elements of the ONF TR-532 document.
• A new chapter 6.6.1 IF Interface shall be added to the new chapter 6.6 Connecting ODUs .
• The following text shall be added to chapter 6.6.1 IF Interface :
  "The parameters of the intermediate frequency connection between IDU and ODU cannot be configured. No status, performance or alarm information is provided for its interfaces.
  For reasons of simplicity, LogicalTerminationPoints, ForwardingDomains, ForwardingConstructs, Links etc. are not used for describing this connection. Instead, the pairing of IF connector and ODU is presented in a way that is very similar to the pairing of the SFP and its cage.
  All IF connectors at both the IDU and the ODUs need to be documented as instances of Connector (as far as they are made available at the device’s own management interface).
  “Virtual” Holders are to be instantiated at the instance of Equipment, which is representing the modem board. Every existing physical IF connector is to be represented by a “virtual” Holder.
  The values of the Holder::localId and the Connector::localId attributes must be identical for those instances of Holder that are representing IF connectors.
  The connected ODU is to be referenced in the containedHolder::occupyingFru attribute of the instance of Holder, which is representing the physical IF connector that is actually connecting the ODU.
  Independently from the unusual modelling of the IF connection, the stack of LogicalTerminationPoints representing the radio connection (AirInterface and further OSI layers on top of it) are listed directly beneath the ControlConstruct.
  
  Figure 4: Simple interface stack (no 1+1 or 2+0) in case of IF connection"

[michbin]

The local-id uniquely identifies contained holders and connectors within a certain context (e.g. the node). It is typically used for mapping the Core Model objects to the managed objects in the device (resp. at its native management interface). So a mediator is not normally free in assigning arbitrary values to the local-id.

The sequence-id defines an ordering of elements of a certain type within the context of the parent equipment object. It is up to an implementation whether contained holders and connectors use independent ranges or share a single range. So it might be impossible to fulfill a requirement of identical sequence-id values for virtual holder and IF connector. (Some devices fulfill it natively though.)

[openBackhaul]

If we can use neither local-id nor sequence-id for concluding from the instance of "virtual" Holder (having the occupying-fru attribute referencing the ODU) on instance of Connector (representing the IF connector), would it then be possible to fill both the outsideLabel attributes at the instances of "virtual" Holder and Connector with the string identifying the physical connector on the front plate.

[openBackhaul]

Updated Proposal to the LF ONMI x-haul call on 23rd of October 2024:
(objected during call at 22th of October 2024)

• Please regard the dependency on EquipmentAugment issue#55 for creating an new Connector::vendorLabel attribute.
• A new chapter 6.6 Connecting ODUs shall be added to the existing chapter 6 Special elements of the ONF TR-532 document.
• A new chapter 6.6.1 IF Interface shall be added to the new chapter 6.6 Connecting ODUs .
• The following text shall be added to chapter 6.6.1 IF Interface :
  "The parameters of the intermediate frequency connection between IDU and ODU cannot be configured. No status, performance or alarm information is provided for its interfaces.
  For reasons of simplicity, LogicalTerminationPoints, ForwardingDomains, ForwardingConstructs, Links etc. are not used for describing this connection. Instead, the pairing of IF connector and ODU is presented in a way that is very similar to the pairing of the SFP and its cage.
  All IF connectors at both the IDU and the ODUs need to be documented as instances of Connector (as far as they are made available at the device’s own management interface).
  “Virtual” Holders are to be instantiated at the instance of Equipment, which is representing the modem board. Every existing physical IF connector is to be represented by a “virtual” Holder.
  The values of the Holder::vendorLabel and the Connector::vendorLabel attributes must be identical for those instances of Holder that are representing IF connectors.
  The connected ODU is to be referenced in the containedHolder::occupyingFru attribute of the instance of Holder, which is representing the physical IF connector that is actually connecting the ODU.
  Independently from the unusual modelling of the IF connection, the stack of LogicalTerminationPoints representing the radio connection (AirInterface and further OSI layers on top of it) are listed directly beneath the ControlConstruct.
  
  Figure 4: Simple interface stack (no 1+1 or 2+0) in case of IF connection"

[openBackhaul]

Decision during the LF ONMI x-haul call on 13th of November 2024:

• Please regard the dependencies on EquipmentAugment issue#56 and EquipmentAugment issue#57.
• A new chapter 6.6 Connecting ODUs shall be added to the existing chapter 6 Special elements of the ONF TR-532 document.
• A new chapter 6.6.1 IF Interface shall be added to the new chapter 6.6 Connecting ODUs .
• The following text shall be added to chapter 6.6.1 IF Interface :
  "The parameters of the intermediate frequency connection between IDU and ODU cannot be configured. No status, performance or alarm information is provided for its interfaces.
  For reasons of simplicity, LogicalTerminationPoints, ForwardingDomains, ForwardingConstructs, Links etc. are not used for describing this connection. Instead, the pairing of IF connector and ODU is presented in a way that is very similar to the pairing of the SFP and its cage.
  All IF connectors at both the IDU and the ODUs need to be documented as instances of Connector (as far as they are made available at the device’s own management interface).
  “Virtual” Holders are to be instantiated at the instance of Equipment, which is representing the modem board. Every existing physical IF connector is to be represented by an instance of “virtual” Holder. The instance of Connector that is representing the IF connector has to be referenced in the _oduConnector attribute and the instance of Equipment representing the connected ODU has to be referenced in the _occupyingFru attribute of such an instance of “virtual” Holder.
  The _connectedOdu attribute at the instance of Connector representing the IF connector has to reference the instance of “virtual” Holder that might reference an instance of Equipment representing a connected ODU in its _occupyingFru attribute.
  
  Figure 4: Simple example for connecting ODUs via IF cabling
  Independently from the unusual modelling of the IF connection, the stack of LogicalTerminationPoints representing the radio connection (AirInterface and further OSI layers on top of it) are listed directly beneath the ControlConstruct.
  
  Figure 5: Simple interface stack (no 1+1 or 2+0 configuration) in case of IF connection
  "