Internet DRAFT - draft-porfiri-dhc-dhcpv4-l2ra-fronthaul

draft-porfiri-dhc-dhcpv4-l2ra-fronthaul







DHC                                                           C. Porfiri
Internet-Draft                                                  J. Arkko
Intended status: Standards Track                            M. Kühlewind
Expires: 25 April 2024                                          Ericsson
                                                         23 October 2023


          Layer 2 Relay Agents in Cellular Fronthaul Networks
               draft-porfiri-dhc-dhcpv4-l2ra-fronthaul-00

Abstract

   The fronthaul portion of a cellular network is the part of the
   network that connects centralized radio controllers and the
   distributed radio units at the edge of the cellular network.  A
   switched fronthaul network is one where the connectivity is provided
   through one or more stages of switches.

   When performing address assignment and configuration tasks in such
   networks, knowledge of how the different devices are connected is
   beneficial.  Networks that employ IPv6 can use DHCPv6 to support
   Relay Agents.  However, those networks that continue to be based on
   IPv4 have no easy way to support this, as the DHCPv4 support for
   relays is limited.

   This document explores how to provide Relay Agent functionality in
   IPv4-based switched fronthaul networks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 25 April 2024.







Porfiri, et al.           Expires 25 April 2024                 [Page 1]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


Copyright Notice

   Copyright (c) 2023 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Use Case  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Layer 2 Fronthaul Architecture  . . . . . . . . . . . . .   4
     2.2.  Layer 2 topology discovery in IPv6  . . . . . . . . . . .   5
     2.3.  Layer 2 topology discovery in IPv4  . . . . . . . . . . .   6
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Potential Approaches  . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The fronthaul portion of a cellular network is the part of the
   network that connects centralized radio controllers and the
   distributed radio units at the edge of the cellular network.  In
   recent years fronthaul networks have become increasingly popular due
   to the distribution of the radio functionality between the radio
   units and the more centralized, cloud-based higher layer functions.

   A switched fronthaul network is one where the connectivity is
   provided through one or more stages of switches.  Such arrangements
   are becoming common as well.






Porfiri, et al.           Expires 25 April 2024                 [Page 2]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


   When performing address assignment and configuration tasks in such
   networks, knowledge of how the different devices are connected is
   beneficial as it allows automatic network configuration of the radio
   units.

   Networks that employ IPv6 can use DHCPv6 to support Relay Agents
   [RFC3315].  This is commonly supported in fronthaul networks.  In
   DHCPv6, a Relay Agent encapsulates the DHCP client message in a new
   DHCP message which it sends to the DHCP server along with any options
   it chooses to add to provide information to the DHCP server.  This
   mode of operation supports also networks that include a hierarchy of
   switches.

   However, those networks that continue to be based on IPv4 have no
   easy way to support this, as the DHCPv4 support for relays is much
   more limited.  For instance, there is no support in DHCPv4 for
   hierarchical modes of deployment, as the specifications prohibit
   chaining of Relay Agent Information Options (RAIOs) [RFC3046].

   This document explores how to provide Relay Agent functionality in
   IPv4-based switched fronthaul networks.

1.1.  Terminology

   The following terms and acronyms are used in this document:

   *  Baseband Unit (BB)

      A processing unit that handles baseband information.  A Baseband
      Unit is often placed centrally, while the Radio Units (see below)
      are distributed and need to be co-located with or near the
      antennas.

   *  DHCP Relay Agent

      This is a concept in all of the protocols, BOOTP [RFC0951]
      [RFC1542], DHCPv4 [RFC2131] [RFC2132], and DHCPv6 [RFC3315],
      although the details differ between the protocols.

   *  Lightweight DHCPv6 Relay Agent (LDRA)

      This is an extension of the original DHCPv6 Relay Agent mechanism,
      to support also Layer 2 devices performing a Relay Agent function
      [RFC6221].

   *  Radio Unit (RU)





Porfiri, et al.           Expires 25 April 2024                 [Page 3]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


      A distributed radio element in a mobile network.  Radio Units
      sometimes also called Radio Heads.

   *  Relay Agent Information Option (RAIO)

      This is a DHCP option defined in [RFC3046].  Also commonly
      referred to as "Option 82".  RAIO options were later extended to
      be able to carry suboptions [RFC6925].

2.  Use Case

   In some network deployments like Fronthaul in mobile networks, the
   aggregation of Radio Unit devices (also known as Switched Fronthaul)
   hides the relationship between the Radio Unit themselves and the
   physical ports where they are connected.

   In order to properly support the Switched Fronthaul device
   configuration, the DHCP server must know the network topology.  This
   is accomplished by implementing in each Layer 2 switch a Layer 2
   Relay Agent functionality.

2.1.  Layer 2 Fronthaul Architecture

   Figure 1 depicts the context where L2RA agent is exploited for
   providing the topology information to the DHCP server.

     +--------+
     |  RU1   |     P1 +-+------+     |                   |
     |        +--------| | L2RA |     |  +----+------+    |
     +--------+        | +------+     |  |    | L3RA |    |
                       |  L2    |     +--|    +------+    |
     +--------+     P2 | switch |     |  |           |    |
     |  RU2   +--------|  #1    +-----|  |   Router  +----|
     |        |        +--------+     |  +-----------+    |  +---------+
     +--------+                       |                   |  |         |
                                      |                   +--| DHCP    |
     +--------+                       |                   |  | Server  |
     |  RU3   |     P1 +-+------+     |                   |  |   #1    |
     |        +--------| | L2RA |     |  +-----------+    |  +---------+
     +--------+        | +------+     |  |           |    |
                       |  L2    |     +--| Baseband  |    |
     +--------+     P2 | switch |     |  |   Unit    |    |
     |  RU4   +--------|  #2    +-----|  |           +----|
     |        |        +--------+     |  +-----------+    |
     +--------+                       |                   |

                 Figure 1: Layer 2 switched fronthaul




Porfiri, et al.           Expires 25 April 2024                 [Page 4]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


   In Figure 1 there are a number of Radio Units (RU) that are connected
   to the Baseband Unit (BB) by means of a Layer 2 switched network.
   Traffic between RUs and BBs is both IP based and Layer 2 based.

   In order to properly address the RU, BB needs to associate the RU's
   MAC to the L2 switch and to the switch port where the RU is connected
   to.

   In a Layer 2 fronthaul there may be a hierarchy of L2 switches where
   a pool of RU and BB are connected.

   Since each RU is unique, but the uniqueness is only known by BB and
   it's tied to the topology, BB needs to know what is the connection
   that is used to access each RU.  In practice, the BB needs to know
   what the mapping between IP and MAC address towards the switch and
   port is.

2.2.  Layer 2 topology discovery in IPv6

   When the fronthaul network uses IPv6, DHCPv6 [RFC3315] is used for
   topology discovery.

   The solution exploits DHCPv6 Relay Agent support in the server,
   whilst Lightweight DHCPv6 Relay Agent (LDRA) [RFC6221] is implemented
   in the L2 switches.  The adoption of LDRA allows to inform DHCPv6
   server about the L2 topology.

   The following sequence can be used:

   *  At boot time, the RU sends a DHCPv6 request.

   *  The L2 switch forwards it with the topology information, as
      specified in [RFC6221]

   *  Any other device in the path towards the DHCPv6 server may also be
      a Relay Agent and provide additional topology information.

   *  DHCPv6 server will reply to the RU and provide a valid IP address.

   *  When the RU receives its IP address, the RU will communicate with
      the BB.

   *  As soon as BB knows about the RU, it will query the DHCPv6 server
      about the topology.

   *  Once the topology is known, the BB can properly manage the RU.





Porfiri, et al.           Expires 25 April 2024                 [Page 5]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


2.3.  Layer 2 topology discovery in IPv4

   DHCPv4 does not fully support the needed functionality for a Layer 2
   Relay Agent.  As such, the procedure used for IPv6 cannot be used.
   In such case only manual configuration is possible.

   Specifically, in DHCPv4 lacks the following capabilities:

   *  There is no support for hierarchy of Relay Agents.

   *  It is not clear if there is an attribute that could carry
      interface or port related information, like DHCPv6's Interface-ID
      [RFC3315] [RFC6221].

   *  There is no specification for how to employ Relay Agents in a
      Layer 2 device.

3.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  Requirements

   A solution with similar capabilities to those of the DHCPv6 Relay
   Agent or Lightweight DHCPv6 Relay Agent mechanisms is needed.

   That is, upon initializing themselves, the clients should be able to
   use the network infrastructure to request configuration information
   such as IP addresses.  And the network infrastructure should be able
   to understand the topology of how the clients are connected to the
   network.

   (In the use case discussed in Section 2.1, the clients are RUs and
   the network infrastructure is the switches and the BBs, but the
   concept is applicable in other circumstances.)

   More specifically, these appear to be the minimum requirements:

   *  A configuration request made by a client must be passed onto to
      servers that provide configuration information.







Porfiri, et al.           Expires 25 April 2024                 [Page 6]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


   *  As part of passing a request from a client to the server, the
      server needs to be made aware of how the client is connected
      through the network, e.g., such that network devices connecting
      the client to the servers may add information they wish to relay.

   *  There needs to be support for adding information from multiple
      network devices, such as from any of the switches traversed on the
      path towards the server.

   *  The configuration servers need to be able to use the information
      shared by the network devices when processing the client's
      request.

   *  There should be no appreciable impact on network capacity or
      processing.

   It is desirable but not required that a solution be based on DHCPv4.

5.  Potential Approaches

   Any arrangement that fulfils the requirements above is potentially a
   solution that can be applied in the use case described in
   Section 2.1.

   Historically, the IETF DHC working group has discussed an extension
   that would support a DHCPv6-like Relay Agent mechanisms in DHCPv4.  A
   proposal for this was made in
   [I-D.ietf-dhc-dhcpv4-relay-encapsulation], and some of the associated
   issues were discussed in [I-D.ietf-dhc-l2ra].  This is one potential
   approach.

   It may of course be that the historical draft is not the only
   possible solution.  The draft
   [I-D.ietf-dhc-dhcpv4-relay-encapsulation] may also be a broader and
   more generic solution than is strictly speaking necessary to support
   the requirements in Section 4.  For instance, there's likely no need
   to support both BOOTP and DHCP.

   It also seems possible that other arrangements based on new types of
   Relay Agent Information Options (RAIOs) [RFC3046] could be designed,
   or the current rules could be relaxed.  The current specification
   requires that when a Relay Agent receives a packet containing an
   RAIO, it must not add an RAIO.  This prevents chaining of RAIOs, and
   hence prohibits the hierarchical use case.  An alternative design,
   perhaps based on a new option and rules around detecting loops could
   perhaps circumvent the need to develop new DHCP messages as was done
   in [I-D.ietf-dhc-dhcpv4-relay-encapsulation].




Porfiri, et al.           Expires 25 April 2024                 [Page 7]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


   For feature parity with DHCPv6, it is desirable but not required that
   a solution be based on DHCPv4.

6.  Security Considerations

   Mechanisms to avoid accepting information from untrusted relays are
   likely necessary.  [RFC3046] provided some minimal anti-spoofing
   support, while [I-D.ietf-dhc-dhcpv4-relay-encapsulation] extended
   this to require configuration mechanisms to disable forwarding of any
   relayed information at the network border, i.e., disallowing clients
   or fraudulent entities from sending DHCP messages claimed to be
   relayed.

   Other, cryptography-based mechanisms may provide further improved
   security.  One example of a cryptography-based mechanism are the DHCP
   authentication mechanisms and suboptions defined in [RFC3118] and
   [RFC4030], although it is not clear that they are widely used.

7.  IANA Considerations

   This document makes no request for IANA.

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, DOI 10.17487/RFC2131, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2131>.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2132>.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, DOI 10.17487/RFC3046, January 2001,
              <https://www.rfc-editor.org/rfc/rfc3046>.

   [RFC6221]  Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A.
              Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221,
              DOI 10.17487/RFC6221, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6221>.




Porfiri, et al.           Expires 25 April 2024                 [Page 8]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [I-D.ietf-dhc-dhcpv4-relay-encapsulation]
              Lemon, T., Deng, H., and L. Huang, "Relay Agent
              Encapsulation for DHCPv4", Work in Progress, Internet-
              Draft, draft-ietf-dhc-dhcpv4-relay-encapsulation-01, 11
              July 2011, <https://datatracker.ietf.org/doc/html/draft-
              ietf-dhc-dhcpv4-relay-encapsulation-01>.

   [I-D.ietf-dhc-l2ra]
              Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
              Information", Work in Progress, Internet-Draft, draft-
              ietf-dhc-l2ra-06, 25 January 2012,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dhc-
              l2ra-06>.

   [RFC0951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              DOI 10.17487/RFC0951, September 1985,
              <https://www.rfc-editor.org/rfc/rfc951>.

   [RFC1542]  Wimer, W., "Clarifications and Extensions for the
              Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542,
              October 1993, <https://www.rfc-editor.org/rfc/rfc1542>.

   [RFC3118]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for
              DHCP Messages", RFC 3118, DOI 10.17487/RFC3118, June 2001,
              <https://www.rfc-editor.org/rfc/rfc3118>.

   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
              C., and M. Carney, "Dynamic Host Configuration Protocol
              for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
              2003, <https://www.rfc-editor.org/rfc/rfc3315>.

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Option", RFC 4030, DOI 10.17487/RFC4030, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4030>.

   [RFC6925]  Joshi, B., Desetti, R., and M. Stapp, "The DHCPv4 Relay
              Agent Identifier Sub-Option", RFC 6925,
              DOI 10.17487/RFC6925, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6925>.





Porfiri, et al.           Expires 25 April 2024                 [Page 9]

Internet-Draft      Layer 2 Relay Agents in Fronthaul       October 2023


Acknowledgments

   The authors would like to acknowledge that much of the material in
   this document has been inspired by
   [I-D.ietf-dhc-dhcpv4-relay-encapsulation] by Ted Lemon, Hui Deng, and
   Lu Huang, and [I-D.ietf-dhc-l2ra] by Bharat Joshi and Pavan Kurapati.
   These documents were the original ideas, which the current authors
   have only adopted and fine-tuned.

   The authors would also like to acknowledge interesting discussions in
   this problem space with Sarah Gannon, Ines Ramadza, Siddharth Sharma,
   and Bernie Volz.

Authors' Addresses

   Claudio Porfiri
   Ericsson
   Email: claudio.porfiri@ericsson.com


   Jari Arkko
   Ericsson
   Email: jari.arkko@ericsson.com


   Mirja Kühlewind
   Ericsson
   Email: mirja.kuhlewind@ericsson.com























Porfiri, et al.           Expires 25 April 2024                [Page 10]