3GPP 23.501 v20.2.0 — the document's own text
5.8.5.6 Forwarding Action Rule
Taught in 13. Where the packets actually go (The 5G system architecture, in depth), 5. The connection, and what is promised on it (The 5G system architecture, overview).
The following table describes the Forwarding Action Rule (FAR) that defines how a packet shall be buffered, dropped or forwarded, including packet encapsulation/decapsulation and forwarding destination.
Table 5.8.5.6-1: Attributes within Forwarding Action Rule
| Attribute | Description | Comment |
|---|---|---|
| N4 Session ID | Identifies the N4 session associated to this FAR. | NOTE 9. |
| Rule ID | Unique identifier to identify this information. | |
| Action | Identifies the action to apply to the packet | Indicates whether the packet is to be forwarded, duplicated, dropped or buffered.When action indicates forwarding or duplicating, a number of additional attributes are included in the FAR.For buffering action, a Buffer Action Rule is also included and the action can also indicate that a notification of the first buffered and/or a notification of first discarded packet is requested (see clause 5.8.3.2).For drop action, a notification of the discarded packet may be requested (see clause 5.8.3.2). |
| Network instance(NOTE 2) | Identifies the Network instance associated with the outgoing packet (NOTE 1). | NOTE 8. |
| Destination interface(NOTE 3)(NOTE 7) | Contains the values "access side", "core side", "SMF", "N6-LAN", "5G VN internal". | Identifies the interface for outgoing packets towards the access side (i.e. down-link), the core side (i.e. up-link), the SMF, the N6-LAN (i.e. the DN), or to 5G VN internal (i.e. local switch). |
| Outer header creation(NOTE 3) | Instructs the UP function to add an outer header (e.g. IP+UDP+GTP, VLAN tag), IP + possibly UDP to the outgoing packet. | Contains the CN tunnel info, N6 tunnel info or AN tunnel info of peer entity (e.g. NG-RAN, another UPF, SMF, local access to a DN represented by a DNAI) (NOTE 8).Any extension header stored for this packet shall be added.The time stamps should be added in the GTP-U header if QoS Monitoring for packet delay is enabled for the traffic corresponding to the PDR(s). |
| Send end marker packet(s)(NOTE 2) | Instructs the UPF to construct end marker packet(s) and send them out as described in clause 5.8.1. | This parameter should be sent together with the "outer header creation" parameter of the new CN tunnel info. |
| Transport level marking(NOTE 3) | The Transport level marking provides either a) the explicit transport level packet marking value (e.g. the DiffServ Code Point value), b) an indication to derive the transport level packet marking value of the outgoing packet from the transport level packet marking value of the incoming packet (NOTE 14) or c), in the downlink direction, a list of transport level packet marking values, each associated with one or more PDU Set Importance values (see clause 5.8.2.7). | NOTE 8, NOTE 15. |
| Forwarding policy(NOTE 3) | Reference to a preconfigured traffic steering policy or http redirection (NOTE 4). | The Forwarding policy refers to a preconfigured forwarding behaviour in UPF, which may be related to:- N6-LAN steering to steer the subscriber's traffic to the appropriate N6 Service Functions deployed by the operator;- local N6 steering to enable traffic steering in the local access to the DN according to the routing information provided by an AF as described in clause 5.6.7;- a Redirect Destination and values for the forwarding behaviour (always, after measurement report (for termination action "redirect")). |
| Metadata(NOTE 10) | Metadata the UPF needs to add to traffic sent over a SFC. | The metadata information is associated with a TSP ID related to N6-LAN steering. |
| Request for Proxying in UPF | Indicates that the UPF shall perform ARP proxying and / or IPv6 Neighbour Solicitation Proxying as specified in clause 5.6.10.2. | Applies to the Ethernet PDU Session type. |
| On-path N6 connection information | Indicates to establish a connection to get media related information and contains the signalling method and the AS proxy address, see clause 5.37.9 (NOTE 13). | Applies when connect-UDP protocol is used. |
| Container for header enrichment(NOTE 2) | Contains information to be used by the UPF for header enrichment. | Only relevant for the uplink direction. |
| Buffering Action Rule(NOTE 5) | Reference to a Buffering Action Rule ID defining the buffering instructions to be applied by the UPF(NOTE 6) | |
| Header Handling Control Rule (see clause 5.6.17) (NOTE 11) | ||
| Header Detection Reference | A reference to a UPF configuration which defines how to detect the protocol or the message in a protocol for which to perform the header handling actions. | |
| Header Detection Support Information | Any dynamic information provided by the AF which is required for the detection of the headers and cannot be preconfigured for the Header handling Detection Reference. | |
| Header Handling Reporting Endpoints | List of notifications endpoints, i.e. per notification endpoint a Notification Target Address and a Notification Correlation ID. | |
| Header Handling Control Reference | A reference to a Header Handling Action related information pre-configured in the UPF. | |
| Header Handling Action(NOTE 12) | Indicates the header handling action to be performed on a specific header field | Possible values: Detect, Remove, Replace, Insert. |
| Header Information(NOTE 12) | A reference to a UPF configuration which defines how to identify a specific header field for which to perform the header handling action. | |
| Header Value(NOTE 12) | A string describing the value of the specific header field. | Mandatory for Replace action, optional for Remove, Insert and Detect action. |
| Header Handling Condition(NOTE 12) | Indicates the condition for performing the header handling action. | Possible values: first match, every match. |
| Header Handling Reporting (NOTE 12) | Indicates whether reporting is requested for the performed Header Handling Action and the notification endpoint(s). | Possible values: yes/no; if yes, one or more of the notification endpoints.Optionally, to reduce signalling, it may include Reporting suggestion information and One time Report indication. |
| NOTE 1: Needed e.g. if: - UPF supports multiple DNN with overlapping IP addresses; - UPF is connected to other UPF or NG-RAN node in different IP domains; - UPF "local switch" and N19 forwarding is used for different 5G LAN groups.NOTE 2: These attributes are required for FAR action set to forwarding.NOTE 3: These attributes are required for FAR action set to forwarding or duplicating.NOTE 4: The TSP ID is preconfigured in the SMF and used to determine the Forwarding Policy included in the FAR according to the description in clause 5.6.7 and clause 6.1.3.14 of TS 23.503 [45] for local N6 steering and in clause 5.6.16 and clause 6.1.3.14 of TS 23.503 [45] for N6-LAN steering. The Forwarding Policy action is enforced before the Outer header creation actions.NOTE 5: This attribute is present for FAR action set to buffering.NOTE 6: The buffering action rule is created by the SMF and associated with the FAR in order to apply a specific buffering behaviour for UL/DL packets requested to be buffered, as described in clause 5.8.3 and clause 5.2.4 of TS 29.244 [65].NOTE 7: The use of "5G VN internal" instructs the UPF to send the packet back for another round of ingress processing using the active PDRs pertaining to another N4 session of the same 5G VN group.NOTE 8: When in architectures defined in clause 5.34, a FAR is sent over N16a from SMF to I-SMF, the FAR sent by the SMF may indicate that the I-SMF is to locally determine the value of this attribute in order to build the N4 FAR rule sent to the actual UPF controlled by the I-SMF. This is further defined in clause 5.34.6.NOTE 9: In the architecture defined in clause 5.34, the rules exchanged between I-SMF and SMF are not associated with a N4 Session ID but are associated with a N16a association.NOTE 10: The use of Metadata is described in clause 5.6.16. How the UPF transforms the Metadata into actual information sent with the traffic (e.g. in the encapsulation header) is based on local policies related with the Forwarding Policy and not specified.NOTE 11: More detailed description of each of the Header Handling Control Rule parameters can be found in clause 5.6.17.2 which describes the corresponding AF provided parameters in the Header Handling Control information.NOTE 12: These parameters are provided together to request a Header Handling Action. Multiple sets of these parameters (and thus multiple header handling actions) can be provided. One or more of these parameters can be provided to overwrite Header Handling Action related information pre-configured in the UPF as per the Header Handling Control Reference.NOTE 13: To be able to provide the media related information to the UPF, a close cooperation between the AS and the Proxy is assumed. Such cooperation is out of the scope of 3GPP.NOTE 14: To be able to perform this action, the transport level packet marking value of the incoming packet needs to be stored for this packet during the outer header removal performed according to the PDR.NOTE 15: There can only be one list of PDU Set Importance based transport level packet marking values provided in a FAR and this list shall not be forwarded to the I-SMF over N16a in the architecture defined in clause 5.34. |