Detnet Working Group T. Jiang Internet-Draft P. Liu Intended status: Informational China Mobile Expires: 22 April 2024 X. Geng Huawei Technologies 20 October 2023 DetNet YANG Model Extension for 5GS as a Logical DetNet Node draft-jlg-detnet-5gs-01 Abstract 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 deterministic network domain. A 5GS logical DetNet node bears the ‘composite’ architecture in that it could act as one or more DetNet routers. While the 3GPP 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 (composite) DetNet node, the composite node ID, and the flow direction within a composite (5GS logical) node, via reusing the existing IETF DetNet YANG model. Toward the end, we also discuss some complicated 5GS related DetNet scenarios that would be considered for future extensions. 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 22 April 2024. Jiang, et al. Expires 22 April 2024 [Page 1] Internet-Draft 5GS DetNet Node 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 5GS – A Logical DetNet Transit Node . . . . . . . . . . . 3 1.2. Composite Architecture of a 5GS Logical DetNet Node . . . 4 1.3. YANG Configuration Provisioning of 5GS Logical DetNet Node . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Enhance DetNet YANG Configuration for 5GS Logical Node . . . 6 2.1. Type of a DetNet node . . . . . . . . . . . . . . . . . . 7 2.2. Composite node ID & DetNet node ID . . . . . . . . . . . 7 2.3. Directions of 5GS DetNet parameters: Uplink vs. Downlink . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. YANG Model for 5GS Information Exposure . . . . . . . . . 7 3. YANG Model Definition of 5GS as a logical DetNet node . . . . 8 3.1. 5GS as a logical DetNet node: Augment Composite-Node-Type and Direction in IETF YANG Model . . . . . . . . . . . . 8 3.2. 5GS as a logical DetNet node: Composite-Node-ID in YANG Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Discussions upon Supporting More Complicated 5GS DetNet Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. DetNet YANG for the Binding Relationship . . . . . . . . 9 4.2. DetNet YANG for Framed-route . . . . . . . . . . . . . . 9 4.3. 5GS DetNet Extension for Future 3GPP Release . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Jiang, et al. Expires 22 April 2024 [Page 2] Internet-Draft 5GS DetNet Node October 2023 1. Introduction 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]. 1.1. 5GS – A Logical DetNet Transit Node 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-+ : ........................................... Figure 1: A 5GS Logical DetNet Node Jiang, et al. Expires 22 April 2024 [Page 3] Internet-Draft 5GS DetNet Node October 2023 The 5GS logical DetNet node, as a whole, 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, the 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] 1.2. Composite Architecture of a 5GS Logical DetNet Node As shown in the Figure 2, a 5GS (composite) node (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 node, the NW-TT ports, the DS-TT ports and the correspondingly associated PDU Sessions together support the 5GS connectivity to the deterministic network. Jiang, et al. Expires 22 April 2024 [Page 4] Internet-Draft 5GS DetNet Node October 2023 PDU-S: PDU Session .................................................. : Bridge_A +-------+ +-------+ : : [PDU-S] | UPF-A |--| NW_TT | : +--------+ : /-----+-------+ +-------+--\ | | : +-----+ +-----+--/ :\---+--------+ | |----|DS_TT|--| | : | | | DetNet | : +-----+ | UE1 | : | | | System | ...........| ... |................................ | DetNet | | | | | | | | | ...........| ... |................................ | System | | | : +-----+ | | [PDU-S] : | | | |----|DS_TT|--| |-----\ +-------+ +-------+ :/---+--------+ +--------+ : +-----+ +-----+ \--| |--| |--/ : | UPF-B | | NW_TT | : : +-----+ | |--| | : +--------+ : +-----+ | | /--+-------+ +-------+ : | DetNet |----|DS_TT|--| UE2 |-----/ : | System | : +-----+ | | [PDU-S] : +--------+ : +-----+ : : : : Bridge_B : .................................................. Figure 2: 5GS DetNet Node Composite Architecture 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 determining a 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 respectively 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. 1.3. YANG Configuration Provisioning of 5GS Logical DetNet Node The 5GS NF TSCTSF maps the configuration parameters in the format of DetNet YANG model, 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 (IP-domain) DetNet controller regarding the (success or failure) Jiang, et al. Expires 22 April 2024 [Page 5] Internet-Draft 5GS DetNet Node October 2023 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 WG. 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. 2. Enhance DetNet YANG Configuration for 5GS Logical Node 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 (composite) DetNet node, the composite node ID, and the flow direction within a 5GS logical node. Jiang, et al. Expires 22 April 2024 [Page 6] Internet-Draft 5GS DetNet Node October 2023 2.1. Type of a DetNet 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 other 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 parameter will help a DetNet controller do better provisioning. 2.2. Composite node ID & DetNet node ID 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 Deterministic Network. 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 nature of a 5GS node. 2.3. Directions of 5GS DetNet parameters: Uplink vs. Downlink The Section 1.2 illustrates that a 5GS DetNet router can be comprised 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 identities of the incoming and outgoing interfaces, i.e., DS-TT and NW-TT ports, 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 a 'direction' parameter in the enhanced YANG model. 2.4. YANG Model for 5GS Information Exposure The spec. 3GPP TS 23.501 also standardizes the reporting scheme of a 5GS DetNet node to the IP-domain DetNet controller. Basically, a 5GS DetNet node may provide exposure information to the IP-domain 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 (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 the information Jiang, et al. Expires 22 April 2024 [Page 7] Internet-Draft 5GS DetNet Node October 2023 reporting 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. 3. YANG Model Definition of 5GS as a logical DetNet node 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 the 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. 3.1. 5GS as a logical DetNet node: Augment Composite-Node-Type and Direction in IETF YANG Model 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 "; } } 3.2. 5GS as a logical DetNet node: Composite-Node-ID in YANG Model Reuse the attribute of “node-id” defined in RFC 8340[RFC8340]. 4. Discussions upon Supporting More Complicated 5GS DetNet Scenarios There are some complicated 5GS related DetNet scenarios that would be considered for future extensions. Jiang, et al. Expires 22 April 2024 [Page 8] Internet-Draft 5GS DetNet Node October 2023 4.1. DetNet YANG for the Binding Relationship As explained in the Section 1.2, a 5GS DetNet router champions the binding relationships that consist of DS-TT ports, user-plane tunnels between UEs and UPF, and NW-TT ports. The binding information is stored in the 5GS NF TSCTSF (see the Figure 1). Evidently, this ‘binding’ is not restricted to a standalone, fixed 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]. 4.2. DetNet YANG for Framed-route A 5GS (logical) 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 their DS-TT ports. That is, as shown in the Figure 2, those end devices are located in the DetNet system beyond DS-TT ports (toward the left). 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 (logical) 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 in this situation have to embrace the entities that are not within the physical boundary of, but being controllable by, a (5GS) DetNet node. 4.3. 5GS DetNet Extension for Future 3GPP Release 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, 3GPP may pursue extensions in future release to align with the IETF DetNet work by standardizing the service-layer functions in a 5GS (logical) DetNet node. E.g., those Jiang, et al. Expires 22 April 2024 [Page 9] Internet-Draft 5GS DetNet Node October 2023 proposals may apply either multi-UE devices or multi-UE multi- connection schemes with redundancy paths to achieve the PREOF. 5. Security Considerations Generally, this function will not incur additional security issues. 6. IANA Considerations This document makes no request of IANA. 7. References 7.1. Normative References [IETF-Draft.DetNet.Yang] Geng, X., Ryoo, Y., Fedyk, D., Rahman, R., and Z. Li, "Deterministic Networking (DetNet) YANG Model", draft- ietf-detnet-yang-17, April 2023. [IETF-Draft.Topology.Yang] Geng, X., Chen, M., Li, Z., and R. Rahman, "Deterministic Networking (DetNet) Topology YANG Model", draft-ietf- detnet-topology-yang-01, April 2023. [RFC5279] Monrad, A. and S. Loreto, "A Uniform Resource Name (URN) Namespace for the 3rd Generation Partnership Project (3GPP)", RFC 5279, DOI 10.17487/RFC5279, July 2008, . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8344] Bjorklund, M., "A YANG Data Model for IP Management", RFC 8344, DOI 10.17487/RFC8344, March 2018, . [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . Jiang, et al. Expires 22 April 2024 [Page 10] Internet-Draft 5GS DetNet Node October 2023 [TR.23.700-46] "3GPP TR 23.700-46 (V18.0.0): Study on 5GS Deterministic Networking (DetNet) interworking", 3GPP TR 23.700-46, March 2023. [TS.23.501] "3GPP TS 23.501 (V18.2.1): System Architecture for the 5G System (5GS)", 3GPP TS 23.501, June 2023. [TS.23.503] "3GPP TS 23.503 (V18.2.0): Policy and charging control framework for the 5G System (5GS); Stage 2", 3GPP TS 23.503, June 2023. 7.2. Informative References [Liaison.3GPP-2-IETF] "LS on 3GPP 5G System acting as a Detnet node", https://datatracker.ietf.org/liaison/1800/, October 2022. [Liaison.IETF-2-3GPP] "Response to 3GPP SA2 LS on 3GPP 5G System acting as a DetNet node", https://datatracker.ietf.org/liaison/1816/, February 2023. Authors' Addresses Tianji Jiang China Mobile Email: tianjijiang@chinamobile.com Peng Liu China Mobile Email: liupengyjy@chinamobile.com Xuesong Geng Huawei Technologies Email: gengxuesong@huawei.com Jiang, et al. Expires 22 April 2024 [Page 11]