Internet DRAFT - draft-jlg-detnet-5gs
draft-jlg-detnet-5gs
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,
<https://www.rfc-editor.org/info/rfc5279>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas,
"Deterministic Networking Architecture", RFC 8655,
DOI 10.17487/RFC8655, October 2019,
<https://www.rfc-editor.org/info/rfc8655>.
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]
