Uploaded image for project: 'OpenShift Request For Enhancement'
  1. OpenShift Request For Enhancement
  2. RFE-4591

MACsec (IEEE 802.1AE) support for secondary SR-IOV interfaces

XMLWordPrintable

    • Icon: Feature Request Feature Request
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • False
    • None
    • False
    • Not Selected
    • 0
    • 0% 0%

      1. Proposed title of this feature request
      MACsec (IEEE 802.1AE) support for secondary SR-IOV interfaces.

      2. What is the nature and description of the request?
      Telco RAN partners require MACsec (IEEE 802.1AE) encryption in order to protect 5G Front Haul traffic between the DU & RU in order to achieve feature parity with their Classic RAN product lines and also in anticipation of O-RAN specifying MACsec encryption of Front Haul traffic between the DU & RU.

      Front Haul traffic is transported from the DU to the RU through an SR-IOV VF configured using the Red Hat SR-IOV Network Operator on a PF on NIC in the DU node. Therefore support for and configuration of MACsec for SR-IOV VF interfaces is required in OpenShift.

      Software only MACsec (i.e. MACsec without any hardware offload/acceleartion) is acceptable.

      MACsec encryption with Pre-Shared Key (PSK) authentication using Connectivity Association Key/Connectivity Association Name (CAK/CKN) key pairs is required.

      Deployment of the partner's workload application occurs after OCP Day 1 installation and Day 2 post installation OCP configuration phases have completed and there is no requirement for MACsec to be available prior to Day 2 post installation OCP configuration having been completed.

      The partner has two deployment scenarios that require MACsec support from OpenShift:

      • End to End MACsec between the DU and RU where the MACsec encrypted traffic traverses an intermediary switch which is not participating in MACsec and is only responsible for forwarding MACsec-protected frames between the DU and RU switch ports without performing any MACsec encryption/decryption.
      • MACsec between the DU and the upstream switch port that the DU's NIC PF carrying Front Haul traffic is connected to. This scenario is only used when the RU does not support MACsec.

      In each of the deployment scenarios above a CAK/CKN PSK pair will be configured on each end point (DU, RU or switch). Multiple RUs may be connected to a single DU and therefore support for configuring multiple CAK/CKN pairs per DU node (one per SR-IOV VF) is required.

      For Telco RAN deployments, assuming that the resources required for MACsec encryption will need to come from the platform core CaaS budget the Telco Engineering RAN Reference Design Specification will need to include guidance to Telco partners on how to assess the impact and determine how many additional cores to allocate to the reserved (platform/housekeeping) core set.

      Further details of the partner's use case is documented here [Red Hat Employees only].

      3. Why does the customer need this? (List the business requirements here)
      MACsec (IEEE 802.1AE) encryption is required to protect 5G Front Haul traffic between the DU & RU in order to achieve feature parity with their Classic RAN product lines and also in anticipation of O-RAN specifying MACsec encryption of Front Haul traffic between the DU & RU.

      4. List any affected packages or components.
      SR-IOV Operator
      (possibly) NMState/NMState Operator
      Telco Engineering RAN Reference Design Specification

       

            mzasepa@redhat.com Michal Zasepa
            bnivenje@redhat.com Ben Niven-Jenkins
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: