| Internet-Draft | 5GS DetNet Node | July 2023 |
| Jiang, et al. | Expires 9 January 2024 | [Page] |
The 3GPP Rel-18 has completed the working item (WID) of the DetNet, i.e., the Deterministic Network. This WID defines and standardizes how a 5G system (5GS) may behave as a logical DetNet transit node, as well as how a 5GS DetNet node may integrate into the IP-domain deterministic network. A 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers. While the 3GPP Rel-18 work has referenced the IETF Detnet YANG model draft for the purpose of provisioning the DetNet traffic parameters to a 5GS logical DetNet node, the per-(logical)-node parameter provisioning needs to be further improved. This draft defines some new DetNet YANG parameters, e.g., the type of a DetNet node, the composite node ID, and the flow direction within a 5GS logical node, via reusing the existing IETF YANG model. Toward the end, we also discuss some complicated 5GS related DetNet scenarios that would be considered for future extensions.¶
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 9 January 2024.¶
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.¶
Recently the 3GPP Rel-18 has completed the working item (WID) of the DetNet, i.e., the Deterministic Network. This WID defines and standardizes how a 5G system (5GS) may behave as a logical DetNet node, as well as how a 5GS DetNet node may integrate into the IP-domain deterministic network. As of now, the Rel-18 has only realized the functionalities of the DetNet forwarding sub-layer [TS.23.501].¶
As shown in the Figure 1, the 5G system or 5GS is a logical DetNet transit node that are comprised of various 5G network functions or NFs, e.g. AMF, SMF, UPF, PCF, etc. It behaves holistically as a transparent box to external networks (as demarcated by the dotted box in the Figure 1), and can be integrated with the IP deterministic network as defined in IETF RFC 8655 [RFC8655]. The 5G NF TSCTSF performs mappings in the control plane between the 5GS internal NFs and the DetNet controller in the IP domain. As a black box-like transit node, the 5GS specific procedures in both the 5G core (i.e., 5GC) and the radio access network (i.e., RAN) remain hidden from the IP DetNet controller.¶
..........................................
: +-----+ +--------+ : +----------+
: | UDM | | TSCTSF |--------|CPF:DetNet|
: +-----+ +--------+ : |Controller|
: / \ | : +----------+
: N8 N10 |N84 :
: +-----+ +------+ +-----+ :
: | AMF |-N11-| SMF |-N7-| PCF | :
: +-----+ +------+ +-----+ :
: / | | :
: N1 N2 N4 :
: / | | :
+--------+ : / | +-------+ :
| DetNet | +----+ +-------+ N3 |(NW-TT)| N6 (UP) : +--------+
| System |--| UE |--| (R)AN |----| |------------:----| DetNet |
+--------+ +----+ +-------+ | UPF | : | Network|
: +-------+ : +--------+
: | | :
: +-N9-+ :
...........................................
The 5GS logical DetNet node has two types of external-facing interfaces, i.e., the device-side ports or DS-TT, and the network-side ports or NW-TT. On the device side, a UE via its DS-TT ports connects with external DetNet entities, which might be DetNet end systems or full-fledged IP DetNet nodes (e.g., IP DetNet routers). This scenario would be a typical deployment for small businesses to achieve deterministic network connectivity via 5G wireless services. On the network side, the NW-TT functionalities could co-exist with the 5G NF UPF, though it is not mandatory. A NW-TT port is connected via the 5G data-plane to external DetNet domain (most likely, an IP deterministic network).¶
Note that there is a need of coordination between the 5GS mobile operator and the IP-domain service provider to support various functionalities, e.g., AAA, signaling exchange, etc. This is currently based on the assumption of the existence of a pre-determined business agreement between the two parties to support the interactions between the 5GS TSCTSF and the IP DetNet controller [TS.23.501]. The interface between the TSCTSF and the DetNet controller uses protocols defined in IETF. The DetNet configuration is carried in the YANG model [IETF-Draft.DetNet.Yang]¶
As shown in the Figure 2, a 5GS router (or so-tagged ‘bridge’ in the figure) is composed of the ports on the UPF network side (i.e., NW-TT), the user plane tunnels between the UE and UPF (i.e., PDU sessions), and the ports on the device side (i.e., DS-TT). For a 5GS DetNet router, the NW-TT ports, the DS-TT ports and the correspondingly associated PDU Sessions together support the 5GS connectivity to the deterministic network.¶
PDU-S: PDU Session
..................................................
: Bridge_A +-------+ +-------+ :
: [PDU-S] | UPF-A |--| NW_TT | :
+--------+ : /-----+-------+ +-------+--\
| | : +-----+ +-----+--/ :\---+--------+
| |----|DS_TT|--| | : | |
| DetNet | : +-----+ | UE1 | : | DetNet |
| System | ...........| ... |................................ | |
| | ...........| ... |................................ | System |
| | : +-----+ | | [PDU-S] : | |
| |----|DS_TT|--| |-----\ +-------+ +-------+ :/---+--------+
+--------+ : +-----+ +-----+ \--| |--| |--/
: | UPF-B | | NW_TT | :
: +-----+ | |--| | :
+--------+ : +-----+ | | /--+-------+ +-------+ :
| DetNet |----|DS_TT|--| UE2 |-----/ :
| System | : +-----+ | | [PDU-S] :
+--------+ : +-----+ :
: :
: Bridge_B :
..................................................
According to 3GPP TS 23.501 [TS.23.501], a 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers upon the integration into the IP-domain deterministic network. The granularity of the 5GS DetNet node is per UPF for each network instance, or per DNN/S-NSSAI in 3GPP term. For example, in the Figure 2, there are two 5GS DetNet nodes corresponding to two UPFs, i.e., the UPF-A matching to the DetNet node ‘Bridge-A’ and the UPF-B matching to the DetNet node ‘Bridge B’, respectively. A 5GS DetNet node may be identified by the corresponding UPF node ID.¶
The 5GS NF TSCTSF maps the parameters in the DetNet YANG configuration, e.g., DetNet flow attributes, DnTrafficSpec, DnFlowReqs, DnMaxLatency, DnMaxLoss, etc., that are provided from the IP-domain DetNet controller (so-tagged as ‘CPF:DetNet Conoller’ in the Figure 1), to 5GS parameters as defined in TS 23.503 [TS.23.503]. Once the provisioning is completed, the TSCTSF provides a response to the DetNet controller regarding the (success or failure) status of the configuration setup.¶
As of the completion of the 3GPP Rel-18 work, the IETF DetNet YANG model draft [IETF-Draft.DetNet.Yang] has been identified and referenced for the purpose of provisioning the DetNet traffic parameters to a 5GS logical DetNet node. This IETF draft standardizes the specification of the DetNet YANG model for configuration and operational data of a DetNet flow so as to provision the end-to-end service on devices along the path. However, from the perspective of 5GS-being-a-logical-DetNet-node, the QoS requirements, e.g., max-latency, max-loss, etc., have to be (5GS) node-specific. As such, this discrepancy led to liaison exchanges between the 3GPP SA2 and the IETF DetNet working groups [Liaison.3GPP-2-IETF] [Liaison.IETF-2-3GPP]. Due to unfavourable comments by the IETF DetNet WG, 3GPP decided to pursue the 3GPP-centric extension to the IETF draft [IETF-Draft.DetNet.Yang], and plan to define a YANG model by importing [IETF-Draft.DetNet.Yang] with the addition of 3GPP related DetNet specific parameters. The 3GPP defined YANG model will use the 3GPP namespace as defined in IETF RFC 5279 [RFC5279].¶
However, this special 3GPP-extension handling bears a limited scope and will be tailored only for 3GPP and 5GS DetNet node. The per-(logical)-node DetNet traffic parameters are general traffic characteristics that should be standardized best in the IETF DetNet domain. Fortunately, there is an IETF DetNet WG draft that works on defining a YANG data model for DetNet topology discovery and capability configuration on the per-(logical)-node basis [IETF-Draft.Topology.Yang]. We have presented and discussed the draft in the IETF-116, and authors of the draft have been revising it since then. As a consequence, the 3GPP SA2 DetNet team have thus discussed this draft [IETF-Draft.Topology.Yang] and agreed to improve the 5GS standards once the draft matures.¶
Apart from the lack of configuring per-(logical)-node parameters as mentioned in the Section 1.3, we also believe that, based on the requirements of 3GPP extension, the standardized operations of a 5GS DetNet node shall be improved with the definition of certain new DetNet YANG parameters, e.g., the type of a DetNet node, the composite node ID, and the flow direction within a 5GS logical node.¶
The 3GPP document TR 23.700-46 [TR.23.700-46] concludes to define the type of a 5GS DetNet node. It claims to be useful for the IP-domain DetNet controller to identify that the 5GS node is a 3GPP defined 5GS system, rather than a router with fixed interfaces only. This knowledge can be useful for the DetNet controller to consider for the QoS that can be provided for a flow. Further, the node-type parameter can be generalized to non-5GS scenarios. For example, the application of some advanced features, e.g., network slicing, virtual-router setting, etc., would divide a single physical node into multiple logical nodes, for which the node-type will help a DetNet controller do better provisioning.¶
As we have explained in the Section 1.2, a 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers to the IP-domain DetNet. The granularity of the 5GS DetNet node (or router) is per UPF, and a 5GS DetNet node may be identified by the corresponding UPF node ID. Thus, it would be better to define a new parameter to differentiate the higher-level composite node ID.¶
The Section 1.2 illustrates that a 5GS DetNet router can be composed of the NW-TT ports, the user plane (UP) tunnels between the UE and UPF, and the DS-TT ports. This corresponds roughly to directional, i.e., either Uplink/UL or Downlink/DL, associations among ports and tunnels. TS 23.501 [TS.23.501] specifies that the 5GS NF TSCTSF uses the identity of the incoming and outgoing interfaces to determine whether the direction is uplink or downlink. For DetNet related parameters, e.g., per-node max-loss, per-node max-latency, etc., they might have asymmetric settings between the UL and DL directions. So, we propose to define this parameter in YANG model.¶
The spec. 3GPP TS 23.501 also standardizes the reporting of a 5GS DetNet node to the IP-domain DetNet controller. Basically, a 5GS DetNet node may provide exposure information to the DetNet controller using information collected from the 5GS entities. The exposure information can be used by the DetNet controller to build up the network topology information (of a holistic DetNet domain). The exposure may be based on IETF RFC 8343 [RFC8343] and IETF RFC 8344 [RFC8344]. Note that while the configuration provisioning and information reporting may involve the opposite directions of data flow between a 5GS and a DetNet controller, there is no material difference in term of the YANG model definition in either direction. Therefore, we do not need to differentiate them in our YANG model enhancement.¶
Based on the proposed enhancements in Section 2, this section defines how to reuse the existing IETF Yang model in the scenario of 5GS as a logical DetNet node. As described in RFC 8340 [RFC8340], topology Yang model allows the configuration of overlay networks on top of the underlay networks, through supporting network, supporting nodes, supporting links, etc. The 5GS could be treated as an underlay network and used as a logical node in layer 3 DetNet system.¶
[Editor's Notes]: This version just provides the basic idea of what attributes are requested. The formal yang model will be defined in the following version.¶
augment "/nw:networks/nw:network/nw:node/nw:termination-point/nw:supporting-termination-point "{
description
?5GS Composite Node Type?;
leaf 5gs-composite-node-type {
type bool;
description
?Describe whether the node is 5GS Composite Node ?;
}
leaf 5gs-direction {
type bool;
description
?Describe whether the node is downstream ?;
}
}
¶
Reuse the attribute of “node-id” defined in RFC 8340[RFC8340].¶
There are some complicated 5GS related DetNet scenarios that would be considered for future extensions.¶
As explained in the Section 1.2, a 5GS DetNet router champions the binding relationship that is comprised of the DS-TT ports, the UP tunnels between UEs and UPF, and the NW-TT ports. The binding information is stored in the 5GS NF TSCTSF. Evidently, this ‘binding’ is not restricted to a standalone port or an individual UP tunnel. Instead, it indicates an integrated ‘association’ among multiple entities to provide the DetNet service as a whole. Accordingly, the corresponding definition of the YANG model in this scenario should not be independent for each entity, but be considered holistically. This is different from how the normal DetNet (topology) YANG model defines for a node, a port and a Link Termination Point [IETF-Draft.Topology.Yang].¶
A 5GS DetNet node as specified in the Rel-18 can transport IP packets destined not only to the UE's IP address or prefix, but also to a range of IPv4 addresses or IPv6 IP prefixes that have been allocated to end devices which can be reached via its DS-TT interfaces. That is, as shown in the Figure 2, those end devices are located in the DetNet system beyond DS-TT ports. This advanced scenario is termed as ‘Framed Route’ in TS 23.501 [TS.23.501]. In field, this is a very useful deployment case in which enterprise-based customers, connected via 5GS DS-TT ports, could achieve deterministic network services provisioned by a 5GS DetNet node.¶
As per 5GS standard, for DS-TT ports, the framed-route information, i.e., the additional IP addresses or IP prefixes, are not directly assigned to but reachable via the ports. The 5GS NF TSCTSF has to expose the information to and also coordinate with the IP-domain DetNet controller in order to correctly map flows beyond the UE. This is a unique scenario for YANG modelling since the YANG definitions have to embrace the entities that are not within the physical boundary of, but being controllable by, a (5GS) DetNet node.¶
As we have mentioned previously, the 3GPP Rel-18 has so far only realized the functionalities of the DetNet forwarding sub-layer, without supporting the DetNet service sub-layer functions. Along with the recent maturity and then the adoption of service-layer drafts in the IETF DetNet WG, some companies in 3GPP have proposed extensions to align with the IETF DetNet work by standardizing the service-layer functions in a 5GS logical DetNet node. Fundamentally, those proposals intend to apply either multi-UE devices or multi-UE multi-connection schemes with redundancy paths to achieve the PREOF. These proposals are currently being explored for potential inclusion in the 3GPP Rel-19.¶
Generally, this function will not incur additional security issues.¶
This document makes no request of IANA.¶