5.13 Ethernet traffic (for 5GC)

29.2443GPPInterface between the Control Plane and the User Plane nodesRelease 17TS

5.13.1 General

An SMF and UPF may support Ethernet PDU sessions, as specified in clause 5.6.10.2 of 3GPP TS 23.501 [28].

A combined PGW-C/SMF and PGW-U/UPF may support Ethernet PDU sessions as specified in clause 4.3.17.8a of 3GPP TS 23.401 [14] and clause 5.6.10.2 of 3GPP TS 23.501 [28]. In this case, the PGW-C/SMF and PGW-U/UPF shall follow, respectively, the requirements specified for the SMF and UPF by this clause.

For a PFCP session set up for an Ethernet PDU session, the SMF shall:

– include the PDN Type IE set to "Ethernet" in the PFCP Session Establishment Request;

– provision PDR(s), for uplink and/or downlink traffic, with Ethernet Packet Filter(s), based on at least any combination of:

– Source/destination MAC address;

– Ethertype as defined in IEEE 802.3 [31];

– Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) VID fields as defined in IEEE 802.1Q [30];

– Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-TAG) PCP/DEI fields as defined in IEEE 802.1Q [30];

– IP Packet Filter Set, in case Ethertype indicates IPv4/IPv6 payload;

– Ethernet PDU Session Information, only possible for a DL PDR, that identifies all (DL) Ethernet packets matching the PDU session as follows, based on the N6 Ethernet configuration in the UPF for the associated Network Instance (see clause 5.6.10.2 of 3GPP TS 23.501 [28]):

– DL traffic based on the MAC address(es) and/or C-TAG and/or S-TAG used by the UE for the UL traffic, for configurations where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to the same N6 interface;

– DL traffic from the N6 interface associated to the PDU session, for configurations where there is a one-to-one relationship between a PDU Session and a N6 interface (in which case the UPF does not need to be aware of MAC addresses and/or C-TAG and/or S-TAG used by the UE in order to route down-link traffic).

NOTE 1: For instance, the SMF can provision a DL PDR with just an "Ethernet PDU Session Information", in a Traffic Endpoint ID or in a PDI, or Ethernet Packet Filters in a PDI, or both an "Ethernet PDU Session Information" in a Traffic Endpoint ID and Ethernet Packet Filters in a PDI.

The SMF may also request a UPF, acting as a PDU session anchor, to:

– redirect Address Resolution Protocol (ARP) (see IETF RFC 826 [32]) or IPv6 Neighbour Solicitation traffic (see IETF RFC 4861 [33]) to the SMF as specified in clause 5.13.2, or to respond to ARP or IPv6 Neighbour Solicitation based on the local cache information as specified in clause 5.13.3;

– report the MAC (Ethernet) addresses and possibly associated VLAN tag(s) used as source address of frames sent UL by the UE, as specified in clause 5.13.5;

– update its list of MAC addresses and possibly associated VLAN tag(s) associated to the PDU session, during an Ethernet PDU session anchor relocation, as specified in clause 5.13.6.

For a PFCP session set up for an Ethernet PDU session, the UPF shall:

– detect Ethernet traffic, based on Ethernet Packet Filter(s) provisioned in PDR(s) by the SMF, and process the Ethernet traffic as instructed in the FAR, QER(s) and URR(s) associated to the PDR(s);

– forward Address Resolution Protocol (see IETF RFC 826 [32]) or IPv6 Neighbour Solicitation messages (see IETF RFC 4861 [33]) to the SMF, as specified in clause 5.13.2, if so required by the SMF;

– respond to Address Resolution Protocol (see IETF RFC 826 [32]) or IPv6 Neighbour Solicitation (see IETF RFC 4861 [33]) based on the local cache information, as specified in clause 5.13.3, if so required by the SMF.

NOTE 2: Ethernet Preamble and Start of Frame delimiter are not sent over 5GS.

NOTE 3: How the UPF/SMF builds the ARP or the IPv6 Neighbour cache is not specified in this release and is implementation specific.

5.13.2 Address Resolution Protocol or IPv6 Neighbour Solicitation Response by SMF

If the SMF requests the UPF to forward all Address Resolution Protocol (ARP) (see IETF RFC 826 [32]) or IPv6 Neighbour Solicitation (see IETF RFC 4861 [33]) traffic to the SMF to respond to the ARP or IPv6 Neighbour Solicitation based on the local cache information for Ethernet PDU sessions, the SMF shall provision a PDR in the UPF with:

– an Ethernet Packet Filter containing EtherType 2054 (hexadecimal 0x0806) and associate the PDR with a FAR, for forwarding ARP traffic to the SMF; and/or

– a PDI containing an application ID such that the identified application ID matches against EtherType 34525 (hexadecimal 0x86DD), IPv6 Next Header type as 58 and ICMP Field Type as 135 and associate the PDR with a FAR, for forwarding IPv6 Neighbour Solicitation traffic to the SMF.

In this case, the user plane packets shall be forwarded between the CP and UP functions by encapsulating the user plane packets using GTP-U encapsulation (see clause 5.3.1).

The SMF shall respond to ARP and/or IPv6 Neighbour Solicitation as specified in 3GPP TS 23.501 [28], clause 5.6.10.2 in this case.

5.13.3 Address Resolution Protocol or IPv6 Neighbour Solicitation Response by UPF

If the SMF requests the UPF to respond to Address Resolution Protocol (ARP) (see IETF RFC 826 [32]) or IPv6 Neighbour Solicitation (see IETF RFC 4861 [33]) based on the local cache information for an Ethernet PDU session, the SMF shall provision a PDR in the UPF with:

– an Ethernet Packet Filter containing EtherType 2054 (hexadecimal 0x0806) and associate the PDR with a FAR that has the ARP bit in Proxying IE of the Forwarding Parameters IE set to "1"; or

– a PDI containing an application ID such that the identified application ID matches against EtherType 34525 (hexadecimal 0x86DD), IPv6 Next Header type as 58 and ICMP Field Type as 135 and associate the PDR with a FAR that has the INS bit in Proxying IE of the Forwarding Parameters IE set to "1".

The UPF shall respond to ARP and/or IPv6 Neighbour Solicitation as specified in 3GPP TS 23.501 [28], clause 5.6.10.2 in this case.

5.13.3A Provisioning of MAC addresses and SDF filters in Ethernet Packet Filters

The provisioning of an SDF Filter in an Ethernet Packet Filter shall follow the requirements specified for provisioning an SDF Filter in clause 5.2.1A.2A.

Likewise, the source and destination MAC addresses information, when provisioned, shall be set as for downlink Ethernet flows. The UP function shall apply source and destination MAC addresses information based on the Source Interface of the PDR, according to the same principles as specified in clause 5.2.1A.2A, e.g. swapping the source and destination MAC addresses information if the Source Interface is ACCESS, and applying them as provisioned if the Source Interface is CORE.

5.13.4 Bidirectional Ethernet Filters

The CP function may provision bidirectional Ethernet Filters in the UP function (see table 7.5.2.2-3), i.e. Ethernet filters that may be associated to both uplink and downlink PDRs of a same PFCP session, as follows:

– when provisioning a bidirectional Ethernet Filter the first time for a PFCP session, the CP function shall set the BIDE (Bidirectional Ethernet Filter) flag in the Ethernet Filter Properties IE and provision the Ethernet filter definition together with a Ethernet Filter ID uniquely identifying the Ethernet Filter among all the Ethernet Filters provisioned for a given PFCP session; the source and destination MAC addresses information, in a bidirectional Ethernet filter, shall be set as for downlink Ethernet flows;

– the CP function may then provision a PDR for the same PFCP session but the opposite direction, by provisioning the Ethernet Filter ID in the Ethernet filter ID field of the PDI, without provisioning again the Ethernet Filter Properties and Ethernet filter definition.;

– when being provisioned with a bidirectional Ethernet Filter in a PDR, the UP function shall apply the Ethernet filter according to the direction of the PDR as specified in clause 5.13.3A, i.e. the UP function shall apply the Ethernet filter parameters provisioned for the Ethernet filter ID, but with swapping the source and destination MAC addresses, and the source and destination IP addresses if any, if the PDR is set for uplink Ethernet flows;

– the UP function shall apply any modification of a bidirectional Ethernet Filter to all PDRs of the PFCP session making use of this Ethernet Filter;

– upon deletion of a PDR making use of a bidirectional Ethernet Filter, the UP function shall still apply the Ethernet Filter for any other PDR making use of the Ethernet Filter.

The requirements specified for provisioning of MAC addresses and SDF Filters in clause 5.13.A shall also apply when provisioning bidirectional Ethernet Filters.

5.13.5 Reporting of UE MAC addresses to the SMF

In a PFCP Session Establishment Request or a PFCP Session Modification Request, the SMF may request the UPF to start or stop (in a PFCP Sesssion Modification Request only) reporting the UE MAC addresses, i.e. the different MAC (Ethernet) addresses used as source address of frames sent UL by the UE in a PDU Session, by:

– creating a URR requesting the UPF to report Ethernet traffic information (i.e. with the Reporting Trigger set to ‘MAC Addresses Reporting’); and

– associating the URR to the PDR provisioned for the UL traffic of the PDU session.

The SMF may additionally request the UPF to detect and report when no user plane packets are received for an UE MAC address, by provisioning the Ethernet Inactivity Timer IE in the URR.

When being requested to start reporting the UE MAC addresses, the UPF shall:

– report immediately any UE MAC addresses (and possibly their associated VLAN tags) known to be associated to the PDU session (e.g. if the request to start monitoring of traffic is received after the PFCP session establishment and if the UPF monitors the UE MAC addresses for the routing of DL traffic);

– report new UE MAC addresses (and possibly their associated VLAN tags) that are detected subsequently;

– report UE MAC addresses (and possibly their associated VLAN tags) that are removed subsequently from the PDU session, based on the detection of absence of traffic during the Ethernet Inactivity Timer, if this timer is provisioned in the URR.

NOTE: Numerous UE MAC addresses can be used by a same PDU session. The UP function can defer a bit the reporting of newly detected or removed UE MAC addresses to allow the reporting of multiple UE MAC addresses in a same usage report. Details are implementation specific.

5.13.6 Ethernet PDU session anchor relocation

The UPF (PSA) of an Ethernet PDU session may be relocated as specified in clause 4.3.5.8 of 3GPP TS 23.502 [29].

A UPF that supports the Ethernet PDU session relocation procedure shall set the ETHAR bit in the UP Function Features (see clause 8.2.25).

If the UPF indicated support of Ethernet PDU session anchor relocation, the SMF may request the UPF to update its list of MAC addresses and possibly associated VLAN tag(s) associated to the PDU session, during an Ethernet PDU session relocation procedure, by sending a PFCP Session Modification Request with Ethernet context information including the MAC addresses (and possibly associated VLAN tag(s)) received from the old Ethernet PDU session anchor.

Upon receipt of such information, the UPF shall consider these MAC addresses (and possibly associated VLAN tag(s)) as associated to the PDU session and the UPF may assist in the update of Ethernet forwarding tables of Ethernet switches in the DN as specified in clause 4.3.5.8 of 3GPP TS 23.502 [29].