<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC2516 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2516.xml">
]> "rfc2629-xhtml.ent">

<rfc submissionType="IETF" xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-allan-5g-fmc-encapsulation-08" number="8822" submissionType="IETF" category="info" ipr="trust200902">
	<!-- Generated by id2xml 1.5.0 on 2021-02-26T02:20:32Z -->
	<?rfc strict="yes"?>
	<?rfc compact="yes"?>
	<?rfc subcompact="no"?>
	<?rfc symrefs="yes"?>
	<?rfc sortrefs="no"?>
	<?rfc text-list-symbols="-o*+"?>
	<?rfc toc="yes"?> consensus="true" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3">

<front>

    <title abbrev="5G Wireless Wireline Convergence WWC User Pl">5G Plane Encapsulation">5G Wireless Wireline Convergence User Plane Encapsulation (5WE)</title>

    <seriesInfo name="RFC" value="8822"/>
    <author initials="D." surname="Allan" fullname="Dave Allan" role="editor">
      <organization>Ericsson</organization>
	<address><postal><street>2455
      <address>
        <postal>
          <street>2455 Augustine Drive</street>
          <city>San Jose</city>
          <region>CA</region>
          <code>95054</code>
	<country>USA</country>
          <country>United States of America</country>
        </postal>
        <email>david.i.allan@ericsson.com</email>
      </address>
    </author>
    <author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3rd">
      <organization>Futurewei Technologies</organization>
	<address><postal><street>2386
      <address>
        <postal>
          <street>2386 Panoramic Circle</street>
          <city>Apopka</city>
          <region>FL</region>
          <code>32703</code>
	<country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1-508-333-2270</phone>
        <email>d3e3e3@gmail.com</email>
      </address>
    </author>
    <author initials="D." surname="Woolley" fullname="David Woolley">
      <organization>Telstra Corporation</organization>
	<address><postal><street>242
      <address>
        <postal>
          <street>242 Exhibition St</street>
          <city>Melbourne</city> <region></region>
          <region/>
          <code>3000</code>
          <country>Australia</country>
        </postal>
        <email>david.woolley@team.telstra.com</email>
      </address>
    </author>
    <date year="2021" month="March"/>
	<abstract><t> month="April" year="2021"/>

<keyword>PPPoE</keyword>
<keyword>W-AGF</keyword>
<keyword>QFI</keyword>
<keyword>RQI</keyword>
<keyword>WWC</keyword>

    <abstract>
      <t>
   As part of providing wireline access to the 5G Core (5GC), deployed
   wireline networks carry user data between 5G residential gateways and the
   5G Access Gateway Function (AGF). The encapsulation method specified in
   this document supports the multiplexing of traffic for multiple PDU
   sessions within a VLAN delineated VLAN-delineated access circuit, permits legacy equipment
   in the data path to inspect certain packet fields, carries 5G QoS
   information associated with the packet data, and provides efficient
   encoding. It achieves this by specific points of similarity with the RFC 2516 PPPoE
   Point-to-Point Protocol over Ethernet (PPPoE) data packet encapsulation.</t>
   encapsulation (RFC 2516).</t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>

      <t>
   Converged 5G ("fifth generation") wireline networks carry user data between
   5G residential gateways (5G-RG) (5G-RGs) and the 5G Access Gateway Function
   (identified as a Wireline-AGF (W-AGF) by 3GPP in [TS23316]) <xref target="TS23316"
   format="default"/>) across deployed access networks based on Broadband
   Forum <xref target="TR101"/> target="TR101" format="default"/> and <xref target="TR178"/>. target="TR178"
   format="default"/>. This form of wireline access is considered to be
   trusted non-3GPP access by the 5G system.</t>
      <t>
   The transport encapsulation used needs to meet a variety of
   requirements requirements,
   including the following:</t>

	<t><list style="symbols"><t>The
      <ul spacing="normal">
        <li>The ability to multiplex multiple logical connections (Protocol
        Data Unit (PDU) Sessions sessions as defined by 3GPP) within a VLAN identified point to
     point VLAN-identified
        point-to-point logical circuit between a 5G-RG and a W-AGF.</t>

	<t>To W-AGF.</li>

        <li>To allow unmodified legacy equipment in the data path to identify
        the encapsulation and inspect specific fields in the payload.  Some
        access nodes in the data path between the 5G-RG and the W-AGF (Such (such as
        digital subscriber loop access multiplexers (DSLAMs) and optical line
        terminations (OLTs)) currently inspect packets identified by specific
        Ethertypes to identify protocols such as the point to point protocol Point-to-Point Protocol
        over
     ethernet Ethernet (PPPoE), IP, ARP, and IGMP. This may be for the purpose
        of enhanced QoS, the policing of identifiers identifiers, and other applications. Some
        deployments are dependent upon this inspection. Such devices are able
        to do this for PPPoE or IP over ethernet IP-over-Ethernet (IPoE) packet encodings but
        would be unable to do so if a completely new encapsulation, or an
        existing encapsulation using a new Ethertype, were used.</t>

	<t>To used.</li>
        <li>To carry per packet per-packet 5G QoS information.</t>

	<t>Fixed information.</li>
        <li>An encapsulation that minimizes processing since fixed access
        residential gateways are sensitive to the complexity of packet processing, therefore an encapsulation that minimizes
     processing
        processing. While not a strict requirement, this is an important consideration.</t>

	</list>
	</t>
        consideration.</li>

      </ul>

      <t>
   A data encapsulation that uses a common Ethertype and has certain fields
   appearing at the same offset as the PPPoE <xref target="RFC2516"/> data encapsulation <xref target="RFC2516"
   format="default"/> can address these requirements. This
   data encapsulation is referred to as the 5G WWC user plane Encapsulation encapsulation or
   5WE. Currently deployed access nodes do not police the VER, TYPE
   and TYPE, or CODE
   fields of an RFC 2516 header,  PPPoE header and only perform limited policing of stateful
   functions with respect to the procedures documented in RFC 2516. Therefore,
   these fields have a different definition for 5WE and are used to:</t>

	<t><list style="symbols"><t>Identify
      <ul spacing="normal">

        <li>Identify that the mode of operation for packets encapsulated in
        such a fashion uses 5G WWC session establishment based on non-access
        stratum (NAS, a logical control interface between user equipment (UE)
        and 5GC a 5th Generation Core Network (5GC) as specified by 3GPP) based 5G WWC session establishment and life cycle
        life-cycle maintenance procedures as documented in [TS23502][TS23316] <xref
        target="TS23502" format="default"/> and <xref target="TS23316"
        format="default"/> instead of legacy PPP/PPPoE session establishment

        procedures (i.e. <xref target="RFC2516"/> (i.e., PADI discipline, LCP, NCP NCP,
        etc.). In this scenario scenario, "discovery" is performed by means outside the
        scope of this document.</t>

	<t>Permit document.</li>
        <li>Permit the session ID field to be used to identify the 5G PDU
     session the encapsulated packet is part of.</t>

	<t>Communicate of.</li>
        <li>Communicate per-packet 5G QoS Flow Identifier (QFI) and
     Reflective QoS Indication (RQI) information from the 5GC to the
     5G-RG.</t>

	</list>
	</t>
     5G-RG.</li>
      </ul>

      <t>
   This 5G specific 5G-specific redesign of fields not inspected by deployed
   equipment results in an encapsulation uniquely applicable to the
   requirements for the communication of PDU session traffic between
   the subscriber premises and the 5G system over wireline networks.
   The 6 byte 6-byte RFC 2516 data packet header followed by a 2 byte 2-byte PPP
   protocol ID is also the most frugal of the encapsulations that are
   currently supported by legacy access equipment that could be adapted
   to meet these requirements.</t>
      <t>
   This encapsulation is expected to be used in environments where RFC
   2516 is deployed. Therefore, implementations MUST <bcp14>MUST</bcp14> examine the
   version number:</t>

	<t><list style="symbols"><t>if
      <ul spacing="normal">
        <li>If the version number is 1, 1 and PPPoE <xref target="RFC2516"/> target="RFC2516" format="default"/> is supported,
     process the frame further, else further; else, silently discard it.</t>

	<t>if it.</li>
        <li>If the version number is 2 and 5WE is supported, process the frame
     further, else
        further; else, silently discard it.</t>

	</list>
	</t> it.</li>
      </ul>
      <t>
   In both cases cases, frames for the supported version number should have
   session IDs corresponding to established sessions for the respective
   protocol models. A 5WE frame with an unrecognized session ID MUST <bcp14>MUST</bcp14> be
   silently discarded.</t>
      <t>
   This encapsulation may have MTU issues when used for Ethernet
   multiplexing in networks where the underlying Ethernet payload is
   limited to 1500 bytes.</t>
      <t>
   This encapsulation is not suitable for other network environments,
   e.g., general use over the public Internet.</t>
      <section title="Requirements Language" anchor="sect-1.1"><t> anchor="sect-1.1" numbered="true" toc="default">
        <name>Requirements Language</name>

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
   "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.</t> here.
        </t>
      </section>
      <section title="Acronyms" anchor="sect-1.2"><t> anchor="sect-1.2" numbered="true" toc="default">
        <name>Acronyms</name>
        <t>
   This document uses the following acronyms:</t>

	<figure><artwork><![CDATA[
3GPP  3rd
<dl indent="10">
<dt>3GPP</dt> <dd>3rd Generation Partnership Project
5WE Project</dd>
<dt>5WE</dt>  <dd> 5G WWC Encapsulation
5GC Wireless Wireline Convergence User Plane Encapsulation</dd>
<dt>5GC</dt>  <dd> 5th Generation Core (network)
DSLAM Digital (network)</dd>
<dt>DSLAM</dt> <dd>Digital Subscriber Loop Access Multiplexer
W-AGF Wireline Multiplexer</dd>
<dt>W-AGF</dt> <dd>Wireline Access Gateway Function
IPoE  IP Function</dd>
<dt>IPoE</dt> <dd>IP over Ethernet
NAS   Non-Access Stratum
OLT   Optical Ethernet</dd>
<dt>NAS</dt>   <dd>Non-Access Stratum</dd>
<dt>OLT</dt>  <dd>Optical Line Termination
PDU   Protocol Termination</dd>
<dt>PDU</dt>   <dd>Protocol Data Unit
PPPoE PPP Unit</dd>
<dt>PPPoE</dt> <dd>PPP over Ethernet
QFI   QoS Ethernet</dd>
<dt>QFI</dt>  <dd>QoS Flow Identifier
QoS   Quality of Service
RG Identifier</dd>
<dt>QoS</dt>   <dd>Quality of Service</dd>
<dt>RG</dt>   <dd> Residential Gateway
RQI Gateway</dd>
<dt>RQI</dt>  <dd> Reflective QoS Indicator
WWC   Wireless Indicator</dd>
<dt>WWC</dt>   <dd>Wireless Wireline Convergence
]]></artwork>
	</figure> Convergence</dd>
</dl>
      </section>
    </section>
    <section title="Data anchor="sect-2" numbered="true" toc="default">
      <name>Data Encapsulation Format" anchor="sect-2"><t> Format</name>
      <t>
   The Ethernet payload [IEEE802] <xref target="IEEE802" format="default"/> for PPPoE <xref target="RFC2516"/> target="RFC2516" format="default"/> is indicated by
   an Ethertype of 0x8864. The information following that Ethertype
   uses a value of 2 in the VER field for the repurposing of the PPPoE
   data encapsulation as the 5G WWC user plane encapsulation (5WE). The
   5G WWC User Plane user plane encapsulation is structured as follows:</t>

	<figure><artwork><![CDATA[

      <artwork name="" type="" align="left" alt=""><![CDATA[
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  VER  |  TYPE |     QFI   |R|0|           SESSION_ID          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            LENGTH             |          PROTOCOL ID          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         DATA PAYLOAD         ~
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork>
	</figure>
      <t>The description of each field is as follows:
   <list>
      <t>VER is the
      </t>

<dl indent="9">

<dt>VER:
</dt>
<dd>The version. It MUST <bcp14>MUST</bcp14> be set to 0x02.</t>

      <t>TYPE is the 0x02.
</dd>

<dt>TYPE:
</dt>
<dd>The message type. It MUST <bcp14>MUST</bcp14> be set to 0x01.</t>

      <t>QFI encodes 0x01.
</dd>

<dt>QFI:
</dt>
<dd>Encodes the 3GPP 5G QoS Flow Identifier [TS38415] <xref target="TS38415"
format="default"/> to be used for mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802].</t>

      <t>R (short <xref
target="IEEE802" format="default"/>.
</dd>

<dt>R:
</dt>
<dd>(Short for Reflective QoS Indication [TS38415]) encodes <xref target="TS38415"
format="default"/>) Encodes the one bit one-bit RQI. It is set by the network side network-side 5WE
termination for downstream traffic and ignored by the network for upstream traffic.</t>

      <t>0 indicates
traffic.
</dd>

<dt>0:
</dt>
<dd>Indicates the bit(s) MUST that <bcp14>MUST</bcp14> be sent as zero and ignored on
      receipt.</t>

      <t>SESSION_ID is a
receipt.
</dd>

<dt>SESSION_ID:
</dt>
<dd>A 16-bit unsigned integer in network byte order. It is used to distinguish
different PDU sessions that are in the VLAN
      delineated VLAN-delineated multiplex. A value of
0xffff is reserved for future use and
      MUST NOT <bcp14>MUST NOT</bcp14> be used.</t>

      <t>LENGTH is the used.
</dd>

<dt>LENGTH:
</dt>

<dd>The length in bytes of the data payload payload, including the initial Protocol
ID. It is 16 bits in network byte order.</t>

      <t>PROTOCOL ID is the 16 bit order.
</dd>

<dt>PROTOCOL ID:
</dt>

<dd><t>The 16-bit identifier of the data payload type encoded using values
from the IANA PPP "PPP DLL protocol numbers registry. (<eref
      target="https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-2"/>)

	<list> Protocol Numbers" registry <eref
target="https://www.iana.org/assignments/ppp-numbers" brackets="angle"/>.</t>
<t>The following values are valid in this field for 5G WWC use:

          <list>
               <t>0x0021: IPv4</t>

               <t>0x0031: Ethernet (referred to in PPP as "bridging")</t>

               <t>0x0057: IPv6</t>

	</list>
        </t>

	<t>
      Packets use:</t>

  <ul>
    <li>0x0021: IPv4
    </li>
    <li>0x0031: Bridging PDU (Ethernet)
    </li>
    <li>0x0057: IPv6
    </li>
  </ul>
<t>Packets received that do not contain one of the above protocol IDs are silently discarded.</t>

	</list>
	</t>

	</list> discarded.
</t>

	<t><list style="hanging" hangIndent="3"><t>
      DATA PAYLOAD is encoded

</dd>

<dt>DATA PAYLOAD:
</dt>
<dd>Encoded as per the protocol ID.</t>

	</list>
	</t>

	</section>

	<section title="Acknowledgements" anchor="sect-3"><t>
   This memo is a result of comprehensive discussions by the Broadband
   Forum's Wireline Wireless Convergence Work Area.
   The authors would also like to thank Joel Halpern and Dirk Von Hugo
   for their detailed review of this draft.</t> ID.
</dd>

</dl>

    </section>

    <section title="Security Considerations" anchor="sect-4"><t> anchor="sect-4" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
	5G NAS procedures used for session life cycle life-cycle maintenance employ ciphering
   and integrity protection [TS23502]. <xref target="TS23502" format="default"/>. They
   can be considered
   to be a more secure session establishment discipline than
   existing RFC 2516 procedures, at least against on path on-path attackers.  The
   design of the 5WE encapsulation will not circumvent existing anti-spoofing
   and other security procedures in deployed equipment.  The existing access
   equipment will be able to identify fields that they normally process and policed
   police as per existing RFC 2516 traffic.</t>
      <t>
   Therefore, the security of a fixed access network using 5WE will be
   equivalent or superior to current practice.</t>
      <t>
   5WE encapsulated
   5WE-encapsulated traffic is used on what the 5GC considers to be trusted
   non-3GPP interfaces, therefore interfaces; therefore, it is not ciphered. 5WE is not suitable for
   use over an untrusted non-3GPP interface.</t>
      <t>
   The security requirements of the 5G system are documented in
   [TS33501]</t>
   <xref target="TS33501" format="default"/>.</t>
    </section>
    <section title="IANA Considerations" anchor="sect-5"><t> anchor="sect-5" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
   IANA is requested to create a has created the following registry on the Point-to-Point "Point-to-Point (PPP)
   Protocol Field Assignments IANA Web page as follows:</t>

	<figure><artwork><![CDATA[
   Registry Assignments" page:</t>

<dl>

<dt>Registry Name: PPP
</dt>
<dd>PPP Over Ethernet Versions
   Registration
</dd>

<dt>Registration Procedure: Specification
</dt>
<dd>Specification Required
   References: [RFC2516] [this document]

       VER     Description                        Reference
      -----   -----------------------------      -----------
         0     reserved
</dd>

<dt>References:
</dt>
<dd><xref target="RFC2516"/> [this document]
         1     PPPoE                             [RFC2516]
         2     5G
</dd>

</dl>

<table anchor="iana_table">
  <name>PPP Over Ethernet Versions</name>
  <thead>
    <tr>
      <th>VER</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>0</td>
      <td>Reserved</td>
      <td>[this document]</td>
    </tr>
    <tr>
      <td>1</td>
      <td>PPPoE</td>
      <td><xref target="RFC2516"/></td>
    </tr>
    <tr>
      <td>2</td>
      <td>5G WWC User Plane Encapsulation   [this document]
      3-15     unassigned                        [this document]
]]></artwork>
	</figure> Encapsulation</td>
      <td>[this document]</td>
    </tr>
    <tr>
      <td>3-15</td>
      <td>unassigned</td>
      <td></td>
    </tr>
  </tbody>
</table>

      <t>
   IANA is requested to add [this document] has added this document as an additional reference for
   Ethertype 0x8864 in the Ethertypes table "Ether Types" registry on the IANA "IEEE 802 Numbers" web
   page.(<eref target="https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml#ieee-802-numbers-1"/>)</t>
   page <eref
   target="https://www.iana.org/assignments/ieee-802-numbers"
   brackets="angle"/>.</t>
    </section>
  </middle>
  <back>
	<references title="Normative References">
	&RFC2119;
	&RFC8174;
	&RFC2516;

	<!--
   draft-allan-5g-fmc-encapsulation-08-manual.txt(315): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
[TS38415] 3rd Generation Partnership Project, Technical
          Specification Group Radio Access Network, NG-RAN,
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2516.xml"/>

<reference anchor="TS38415">
     <front>
       <title>NG-RAN; PDU
          Session User Plane Protocol (Release 15), 3GPP TS38.415
   -->

	<!--
   draft-allan-5g-fmc-encapsulation-08-manual.txt(319): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
[TS23502] 3rd Generation Partnership Project, Technical
          Specification Group Services and System Aspects,
          Procedures session user plane protocol</title>
       <author>
         <organization>3GPP</organization>
       </author>
       <date month="March" year="2018" />
     </front>
<seriesInfo name="TS" value="38.415" />
<refcontent>Release 15</refcontent>
</reference>

   <reference anchor="TS23502">
     <front>
       <title>Procedures for the 5G System (Release 16), 3GPP TS23.502
   -->

	<!--
   draft-allan-5g-fmc-encapsulation-08-manual.txt(323): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
[TS23316] 3rd Generation Partnership Project, Technical
          Specification Group Services and System Aspects,
          Wireless (5GS)</title>
       <author>
         <organization>3GPP</organization>
       </author>
       <date month="December" year="2016" />
     </front>
<seriesInfo name="TS" value="23.502" />
<refcontent>Release 15</refcontent>
   </reference>

   <reference anchor="TS23316">
     <front>
       <title>Wireless and wireline convergence access support for the 5G System (5GS) (Release 16), 3GPP TS23.316,
          November 2018
--> (5GS)</title>
       <author>
         <organization>3GPP</organization>
       </author>
       <date month="December" year="2018" />
     </front>
<seriesInfo name="TS" value="23.316" />
<refcontent>Release 16</refcontent>
   </reference>

</references>
	<references title="Informative References">
      <references>
        <name>Informative References</name>

        <reference anchor="TR101"><front> anchor="TR101">
          <front>
            <title>Migration to Ethernet Based Broadband Aggregation</title>
            <author>
	    <organization>Broadband Forum</organization>
	    </author>
            <date month="July" year="2011"/>
          </front>
	<seriesInfo name="Broadband" value="Forum Technical Report: TR-101
<refcontent>TR-101, issue 2"/> 2</refcontent>
        </reference>

        <reference anchor="TR178"><front> anchor="TR178">
          <front>
            <title>Multi-service Broadband Network Architecture and Nodal Requirements</title>
            <author>
	      <organization>Broadband Forum</organization>
	    </author>
            <date month="September" year="2014"/>
          </front>
	<seriesInfo name="Broadband" value="Forum Technical Report: TR-178"/>
<refcontent>TR-178, issue 1</refcontent>

        </reference>

	<!--
   draft-allan-5g-fmc-encapsulation-08-manual.txt(339): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
[IEEE802] 802, IEEE, "IEEE

   <reference anchor="IEEE802">
     <front>
       <title>IEEE Standard for Local and Metropolitan Networks: Overview and Architecture", IEEE Std 802-2014.
   -->

	<!--
   draft-allan-5g-fmc-encapsulation-08-manual.txt(342): Warning: Failed parsing a
   reference.  Are all elements separated by commas (not periods, not just
   spaces)?:
[TS33501] 3rd Generation Partnership Project, Technical
          Specification Group Services and System Aspects,
          Security Architecture
       Architecture</title>
       <author>
         <organization>IEEE</organization>
       </author>
       <date month="June" year="2014" />
     </front>
<seriesInfo name="Std" value="802-2014"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
   </reference>

   <reference anchor="TS33501">
     <front>
       <title>Security architecture and Procedures procedures for 5G System
          (Release 16), 3GPP TS33.501, December 2019
--> System</title>
       <author>
         <organization>3GPP</organization>
       </author>
       <date month="December" year="2019" />
     </front>
<seriesInfo name="TS" value="33.501"/>
<refcontent>Release 16</refcontent>
   </reference>

</references>
    </references>

    <section anchor="sect-3" numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>
   This memo is a result of comprehensive discussions by the Broadband Forum's
   Wireline Wireless Convergence Work Area.  The authors would also like to
   thank <contact fullname="Joel Halpern"/> and <contact fullname="Dirk Von
   Hugo"/> for their detailed review of this document.</t>
    </section>
  </back>

</rfc>