Hi John, Thank you for this new version. I'm fine with the section 3.2 and the rest of the document. However, I still have some problems with part of the text contained in section 2 and section 3. As I said, draft should be refocused on the use of GTP-U over F1-U/N3/N9. In that direction, please consider the following comments.
Comments: #1: GTP is not used in the fronthaul and, therefore, fronthaul should remain out of scope of this document. OLD: 2. Scope of Transport Networks in 5G Slicing 3GPP [TS.28.530-3GPP] discusses transport network in the context of network slice subnets, but does not specify further details. This section provides an overview of the processes to provision and map 5G slices in backhaul, mid-haul and front haul network segments with GTP-U (UDP) source port number. NEW: 2. Scope of Transport Networks in 5G Slicing 3GPP [TS.28.530-3GPP] discusses transport network in the context of network slice subnets, but does not specify further details. This section provides an overview of the processes to provision and map 5G slices in backhaul and mid-haul network segments with GTP-U (UDP) source port number. #2: in 5GS, split of gNB is only an option. As it is described, it seems to assume that any 5GS will have split gNB. ODL: Figure 1 depicts 5GS expanded to show the IP transport and PE (Provider Edge) providing IP transport service to 5GS user plane entities 5G-AN (e.g., gNB) and UPF. NEW: Figure 1 depicts a 5G System (5GS) in which a gNB is split into a gNB-CU-CP, multiple gNB-CU-UPs and multiple gNB-DUs, as described in TS 38.401 [x] . In addition, the figure is expanded to show the IP transport and PE (Provider Edge) providing IP transport service to 5GS user plane entities 5G-AN (e.g., gNB) and UPF. #3: maybe good to introduce N3, N9 and F1-U interfaces OLD: The N3, N9 and F1-U user planes use GTP-U specified in [TS.29.281-3GPP] to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured). NEW: In this architecture, end-to-end user plane connectivity between the UE and a specific Data Network (DN) is supported by the F1-U interface (between gNB-DU and gNB-CU-UP) in, the N3 interface between the gNB-CU-CP and the UPF, and the N9 interface between UPFs in the core network. Over these interfaces, GTP-U is used to transport UE PDUs (IPv4, IPv6, IPv4v6, Ethernet or Unstructured) as specified in [TS.29.281-3GPP]. #4: because fronthaul is likely out of scope of this draft, the following paragraph could be safely removed: When gNB functionality is split between a central unit (CU) and a distributed unit (DU), a mid-haul transport segment provides the connectivity as shown in Figure 1. [...] For the front-haul described further in Section 3.1, an Ethernet transport with VLANs can be expected to be the case in many deployments. #5: instead, a note can be included. NEW: The gNB-DU can also be split into two entities (O-RU and O-DU) as defined by O-RAN Alliance and therefore the the user plane includes the fronthaul interface between O-RU and O-DU. However, as this interface does not rely on GTP-U to transport UE PDU, the fronthaul interface is out of scope of this document. #6: if fronthaul is out of scope, section 3.1 should be renamed and the first part on O-RAN should be removed OLD: 3.1. Fronthaul and Mid-Haul Transport Network The O-RAN Alliance defined a lower layer split at the physical layer of the radio access network whereby the gNB-DU is split into two entities (O-RU and O-DU) and has specified the fronthaul interface between the O-RU and the O-DU in [ORAN-WG4.CUS-O-RAN]. The radio layer information, in the form of In-phase (I) and Quadrature (Q) samples are transported using enhanced Common Public Radio Interface (eCPRI) framing over Ethernet or UDP. On an Ethernet based fronthaul interface, the network slice instance (NSI) information is carried in the Ethernet header through the VLAN tags and/or PCP marking. The Ethernet switches in the fronthaul transport network inspects the slice information (VLAN tag and/or PCP marking) in the Ethernet header and provide the provisioned capabilities. The mapping of I and Q samples of different radio resources (radio resource blocks or carriers) to different slices and to their respective VLAN tags and or PCP marking on the fronthaul interface is controlled by the O-RAN fronthaul C-Plane and M-Plane interfaces. The fronthaul transport network is latency and jitter sensitive. The provisioned slice capabilities in the fronthaul transport network MUST take care of the latency and jitter budgets of the specific slice for the fronthaul interface. The provisioning of the fronthaul transport network is handled by the NC pertaining to the fronthaul transport. 3GPP functions gNB-CU (user plane) and gNB-DU may also be distributed and have a mid-haul transport between the two 3GPP network functions. [...] NEW: 3.1. Mid-Haul Transport Network As described in Figure 1, 3GPP functions gNB-CU (user plane) and gNB-DU may also be distributed and have a mid-haul transport between the two 3GPP network functions. [...] #7: As the content of the 3.1 has be simplified, section 3.1 and 3.3 could be merged to become 3.1 " Mid-Haul and Backhaul Transport Networks" No further comment. Best Regards, Lionel -----Original Message----- From: Kaippallimalil John <john.kaippallima...@futurewei.com> Sent: vendredi 27 décembre 2024 18:30 To: Lionel Morand <lionel.mor...@huawei.com>; Ran Atkinson <ran.atkin...@gmail.com>; t...@ietf.org; d...@ietf.org Cc: opsawg@ietf.org Subject: RE: [Teas] Re: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-14 Hi Lionel, Ran, all, Thank you for the comments. Please see new version that addresses the comments: https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/ A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-15 Some info on the changes: Sections 1 and 2.1 in r14 has some overlap and has been revised to simplify while retaining just enough to be self-contained. A new section 2 (derived from section 2.1 in r14) contains aspects of TN and 5G slicing as it relates to using GTP-U source port number for mapping. (and includes aspects for 5QI, handling per user/PDU session and per interface for front haul). Redundant text between section 1 and 2.1 (in r14) have been removed. The changes are editorial and no changes have been made in subsequent sections that describe detailed mechanisms. If the WG is happy with these changes, the authors would like to request for WG last call. Best Regards, John > -----Original Message----- > From: Lionel Morand <lionel.morand=40huawei....@dmarc.ietf.org> > Sent: Wednesday, December 18, 2024 12:45 PM > To: Ran Atkinson <ran.atkin...@gmail.com>; t...@ietf.org > Cc: d...@ietf.org; opsawg@ietf.org > Subject: [Teas] Re: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-14 > > Hi Ran, > > I think that the main goal of this draft is not to describe the 3GPP > system architecture (fronthaul, midhaul, backhaul) nor to redefine the > mapping between IETF IP transport slice and 3GPP slices. It is already > well covered by other 3GPP/IETF documents. > > With the removed/simplified sections, the draft would still be self-contained. > The key issue is addressed in section 2.4, i.e. how to ensure slice > Mapping when GTP-U is secured by IPsec, which is just a corner case of > the generic use case. And the section 3 provides a solution to map > GTP/UDP source ports to slice types. > And section 4 extends the YANG service data model defined in I-D.ietf- > opsawg-teas-attachment-circuit to carry UDP source port number/range > to support slice mapping based UDP source port when GTP-U is secured by IPsec. > > Let me know if I've missed something. > > As I said, the goal is only to make the document simpler and more readable. > People that will implement this draft will have to go anyway through > other companion documents from IETF or 3GPP. > > Regards, > > Lionel > > -----Original Message----- > From: Ran Atkinson <ran.atkin...@gmail.com> > Sent: mercredi 18 décembre 2024 15:29 > To: t...@ietf.org > Cc: d...@ietf.org; opsawg@ietf.org > Subject: [DMM] Re: [Teas] draft-ietf-dmm-tn-aware-mobility-14 > > Hi, > > In many situations, I think it is quite helpful to have self-contained > documents. > > Often, someone who has not participated in any IETF activity will be > assigned by their employer to “go implement RFC-xyz” for some product. > Having a self- contained document greatly helps implementers who are > well-intentioned, but have not participated in IETF (or 3GPP or > whatever else) during the creation of the specification. > > Yours, > > Ran > > > On Dec 18, 2024, at 04:30, Lionel Morand > <lionel.morand=40huawei....@dmarc.ietf.org> wrote: > > > > Hi John, > > Thank you for the new version, taking into account the comments > > raised > after the last IETF meeting. > > I have been through and it could be ready for WGLC. > > > > However, if I may, I think the draft could be simplified a bit. > > As it is, the document is structured as a self-contained document > > whereas it > might not be required. > > _______________________________________________ > dmm mailing list -- d...@ietf.org > To unsubscribe send an email to dmm-le...@ietf.org > _______________________________________________ > Teas mailing list -- t...@ietf.org > To unsubscribe send an email to teas-le...@ietf.org _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
