Re: [DMM] questions and comments to draft-ietf-dmm-tn-aware-mobility-07
Hi Linda, Thank you for the comments and questions. I am providing below my answers inline with tag [SB] as a co-author On Sat, Sep 2, 2023 at 8:07 AM Linda Dunbar wrote: > Uma, John, Sridhar, Jeff, and Praveen, > > > > draft-ietf-dmm-tn-aware-mobility-07 has very good description of 5G system > and 5G slices mapping to transport network VPNs. > > > > I have some questions and comments: > >- Section 3.1: > > There are data plane traffic (i.e. UE<-> service instance in DC) and > Control Plane traffic (UE<->gNB<-> 5G functions). Is the 5G End-to-End > network slicing for the control plane and data plane? > [SB] It is for both. In the control plane, slice specific isolated control functions (SMF, PCF, NRF, NSSF etc) are selected during UE registration procedure as specified in 3GPP TS 23.501. The AMF remains common for a set of slices. In view of the ability to select separate and distinct instances for these control plane functions, it is possible to assign control plane interface IPs to these functions from different IP pools. It is possible to engineer the IP transport networks for different slice requirements based on these IP pool differentiations. In the user plane, entropy is built into each packet to identify the slice it belongs. One of the suggested methods in this draft is to use the UDP source port. For the data plane traffic, the End-to-End network sliding should continue > from UPFs to the service destination (which could be VMs in data center). > [SB] UPF to service destination path is outside the scope of 3GPP. Any IETF based mechanism can be used here for slicing (e.g. Service function chaining, SRv6, SR-MPLS etc) > >- Section3.2: > > Fronthaul network is very time sensitive. So must have very few links > (hops) from IP perspective. Do you see applicability of TE in the Fronthaul > network? > [SB] This section also talks about L2 network for fronthaul. In fact for the fronthaul eCPRI over Ethernet is more common than eCPRI over IP. The following statement clearly mentions that the provisioned capabilities shall take into account overall delay budget “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” So this could imply reducing the number of hops. Actually IETF need not be prescriptive here. The key thing is the overall delay budget shall be met (for e.g. if the fronthaul delay budget is 100 microseconds then irrespective of number of hops this budget shall be met). > >- Section 4: it would be clearer to emphasize that the transport >network is really among 5G functions. So, from data plane perspective, the >End-to-End transport has to traverse the IP network between the UPFs and >the service destinations. > > > [SB] This is a good comment. We can consider revising the text to emphasize this in the next revision. Thank you. > > Linda Dunbar > > > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13
Hi Pablo / Dave all, See my additional comment inline marked [SB] Regards Sridhar On Wed, Jul 28, 2021 at 12:06 AM Pablo Camarillo (pcamaril) wrote: > Hi Dave, > > Many thanks for your comments. Inline with PC. > > Cheers, > Pablo. > > -Original Message- > From: dmm On Behalf Of David Allan I > Sent: viernes, 23 de julio de 2021 19:51 > To: dmm@ietf.org > Subject: Re: [DMM] Additional questions/comments on > draft-ietf-dmm-srv6-mobile-uplane-13 > > Hi: > > Looking over this draft it strikes me that IF you are discussing a GTP > replacement, there are a few unaddressed gaps...or at least I see no > mention of them. > > - adding X2 to the list of interfaces to be supported > [PC] Do you think there is any new mechanism to be added to the currently > defined ones? > > [SB] If we are including X2 then F1U also needs to be considered. Both X2 and F1U also have GTPU flow control mechanism defined in TS 38.425. I am not sure if a corresponding feedback mechanism exists in SRv6 for flow control. - support for end-marker for handoff stream synchronization (probably > could fit the unused bit in Args.Mob.Session but frankly I have not studied > this in detail) > [PC] User Plane Message encoding is out of the scope of this draft. > However, draft-murakami-dmm-user-plane-message-encoding-03 proposes a > mechanism to encode the Echo Request, Echo Reply, Error Indication, and End > Marker. > > - support for QMP (quality measurement protocol), which I believe needs > to also extend across the radio interface so is not simply local to the GTP > domain and can be "stunt doubled" > [PC] Excellent point. Seems we missed this one in draft-murakami! We can > add in there the QoS Monitoring Packet indicator, as well as the encoding > for the timestamps and average DL/UL delays. > > - support for paging policy presence/indication > [PC] Same as previous. Many thanks. > > [PC], By the way, I've posted an updated revision as the reference to > draft-murakami was missing. > > If this has come up elsewhere, let me know > > Cheers > Dave > > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core
Hi Gengxuesong, On, >> Maybe the existing question becomes whether DSCP is sufficient for passing information from the mobile network to transport network? whether there is any simplification or omission of information in the mapping to the DSCP? 3GPP allows mapping of a GTP-u tunnel (PDU session) to an index to a transport network configuration / policy via "Network Instance" concept. When the GTP-u tunnel is setup in the UPF by the signalling plane, it provides a "Network Instance" which is just a string that acts as an index into UPF's transport layer configuration. Now what the transport layer configuration is - 3GPP doesn't care as it is out of their remit. If you are using just plain IP routing, then DSCP (for IPv4) and Flow label (IPv6) are the options to map a QFI within a GTP-u tunnel to IP transport. However if you are using - say a source routing technology like SRv6, you may potentially configure the UPF to map a slice (PDU session / TEID) and QFI to a specific SID list. If you use PPR (Preferred path routing), then MTCN-ID is an option. Also note that on the N3 interface between UPF and gNB, if it is going to traverse a public network, operators would employ IPSec tunneling for security. So any markings at the transport protocol layer (e.g. UDP source port) will not be visible to on path routers due to IPSec. In such a case, the mapping of Slice (PDU Session / TEID) and QFI should be to the outer IP header in the IPSec tunnel. This is where a solution at IP header level helps (e.g DSCP / flow label / SID list) Regards Sridhar On Mon, Feb 1, 2021 at 8:10 AM Gengxuesong (Geng Xuesong) < gengxues...@huawei.com> wrote: > Hi Sridhar, > > > > Thanks for your explanation. It is much clearer for me as the following: > > ž UPF < - GTP-u tunnel [PDU session]-- > gNB > > ž PDU session contains multiple QoS flows [QFI marker->5QI] > > ž QFI marker in GTP-u extension header > > 5QI is not in GTP-u header directly but could be indicated by QFI. So the > QoS requirements presented by 5QI can’t be used/seen by transport network > in the existing in the current implementation (TEID is similar). And DSCP > can act as a mediator between transport network and UPF/gNB. > > Maybe the existing question becomes whether DSCP is sufficient for passing > information from the mobile network to transport network? whether there is > any simplification or omission of information in the mapping to the DSCP? > > > > Best > > Xuesong > > > > > > *From:* Apn [mailto:apn-boun...@ietf.org] *On Behalf Of *Sridhar Bhaskaran > *Sent:* Friday, January 29, 2021 8:06 PM > *To:* Gengxuesong (Geng Xuesong) > *Cc:* a...@ietf.org; Uma Chunduri ; Kaippallimalil > John ; dmm ; Lizhenbin < > lizhen...@huawei.com> > *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core > > > > Hi Gengxuesong, > > > > QFI (mapped to 5QI) and TEID are to identify QoS flows and PDU sessions > within UPF and gNB. They are not meant for transport network to look into. > UPF and gNB map QFI to DSCP marking in the outer IP header which the > transport network can use for differentiated services. > > > > Regards > > Sridhar > > > > On Fri, Jan 29, 2021 at 3:37 PM Gengxuesong (Geng Xuesong) < > gengxues...@huawei.com> wrote: > > Hi Sridhar, > > > > Thank you for your additional information. Can I come to a conclusion > that: both 5QI and TEID have the potential to provide additional > information for differentiated services in transport network, although the > two parameters act in different scopes? > > > > Best > > Xuesong > > > > *From:* Sridhar Bhaskaran [mailto:sridhar.bhaska...@gmail.com] > *Sent:* Friday, January 22, 2021 12:39 PM > *To:* Kaippallimalil John > *Cc:* Gengxuesong (Geng Xuesong) ; Uma Chunduri < > umac.i...@gmail.com>; Lizhenbin ; a...@ietf.org; dmm > > *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core > > > > Hi Xuesong, > > > > In addition to what John said, in 3GPP networks there is one GTP-u tunnel > per bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case of > 5G). > > > > One UE (user equipment - i.e mobile device) may have multiple PDU sessions > and hence in the network there may be more than one tunnel for a UE. The > scope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go all the > way upto UE. The GTP-u header has a field called "TEID" (tunnel endpoint > identifier). The TEID in the header identifies a context in UPF and gNB. > The context gets established through signalling plane. The context provides > information on the QoS to be provided for the bearer, PDCP ciphering keys > appl
Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core
Hi Gengxuesong, QFI (mapped to 5QI) and TEID are to identify QoS flows and PDU sessions within UPF and gNB. They are not meant for transport network to look into. UPF and gNB map QFI to DSCP marking in the outer IP header which the transport network can use for differentiated services. Regards Sridhar On Fri, Jan 29, 2021 at 3:37 PM Gengxuesong (Geng Xuesong) < gengxues...@huawei.com> wrote: > Hi Sridhar, > > > > Thank you for your additional information. Can I come to a conclusion > that: both 5QI and TEID have the potential to provide additional > information for differentiated services in transport network, although the > two parameters act in different scopes? > > > > Best > > Xuesong > > > > *From:* Sridhar Bhaskaran [mailto:sridhar.bhaska...@gmail.com] > *Sent:* Friday, January 22, 2021 12:39 PM > *To:* Kaippallimalil John > *Cc:* Gengxuesong (Geng Xuesong) ; Uma Chunduri < > umac.i...@gmail.com>; Lizhenbin ; a...@ietf.org; dmm > > *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core > > > > Hi Xuesong, > > > > In addition to what John said, in 3GPP networks there is one GTP-u tunnel > per bearer (in case of 4G) and one GTP-u tunnel per PDU session (in case of > 5G). > > > > One UE (user equipment - i.e mobile device) may have multiple PDU sessions > and hence in the network there may be more than one tunnel for a UE. The > scope of GTP-u tunnel is from UPF to gNB only. GTP-u does not go all the > way upto UE. The GTP-u header has a field called "TEID" (tunnel endpoint > identifier). The TEID in the header identifies a context in UPF and gNB. > The context gets established through signalling plane. The context provides > information on the QoS to be provided for the bearer, PDCP ciphering keys > applicable for the bearer context etc.,. If there are a million UE that are > getting connected to a UPF, there could be few million GTP-u tunnels > (TEID). > > > > In summary: > > 1. The 5QI / QFI marking in the GTP-u extension header provides a lookup > for the general QoS characteristic applicable for that 5QI > > 2. TEID in the GTP-u header provides a lookup for UE and bearer specific > contextual information for any differentiated treatment. > > > > Regards > > Sridhar > > > > On Fri, Jan 22, 2021 at 2:55 AM Kaippallimalil John < > john.kaippallima...@futurewei.com> wrote: > > Hi Xuesong, > > > > Traffic policy for subscribers is managed per PDU session at the UPF (and > gNB). > > GTP-u does provide encapsulation between the end points, but its control > fields are meant for conveying control semantics between the GTP endpoints: > they were not intended for IP transport/ traffic underlays. 5QI/QCI etc are > in the GTP extension header which may not be ideal to lookup to classify > each packet in the transport network. > > > > The entity that classifies data packets (upstream at gNB and downstream at > UPF-PSA) also inserts the DSCP for that GTP packet. The classification is > based on subscriber aspects but may also on be based on its content (e.g., > using DPI). > > > > Best Regards, > > John > > > > > > *From:* dmm *On Behalf Of *Gengxuesong (Geng > Xuesong) > *Sent:* Wednesday, January 20, 2021 8:23 PM > *To:* Uma Chunduri ; Lizhenbin > *Cc:* a...@ietf.org; dmm > *Subject:* Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core > > > > Hi Uma and all, > > > > I have read the document and got a few questions: > > In my understanding, in the UPF where traffic policy is enforced, the > fine-granularity services are provided. Then what fields in the GTP-u > encapsulation indicates the traffic's service requirements? When a GTP-u > tunnel goes into a SRv6 policy, according to which fields in the GTP-u > encapsulation the DSCP is generated? We know that there are parameters such > as 5QI/QCI and QFI, whether they are associated with a GTP-u tunnel? > > > > Best > > Xuesong > > *From:* Apn [mailto:apn-boun...@ietf.org ] *On > Behalf Of *Uma Chunduri > *Sent:* Tuesday, January 19, 2021 3:17 AM > *To:* Lizhenbin > *Cc:* a...@ietf.org; dmm > *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core > > > > Hi Robin, > > > > In-line.. > > > > Cheers! > -- > > Uma C. > > > > On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin wrote: > > Hi APNers and DMMers, > > I remember that in the mobile core scenarios the GTP-u tunnel can be set > up according to the user and application requirements, but I do not > understand the details. > > > > [Uma]: Obviously, the best
Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core
https://www.ietf.org/mailman/listinfo/dmm > <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=04%7C01%7Cjohn.kaippallimalil%40futurewei.com%7C77632db844b34a8e561108d8bdb38cb8%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467926158632424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=oHJnGPO3hUL9xPkObVLsJ5S1JnwGOF6IeJrLADLrTVA%3D=0> > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document
Hi all, As a co-author of this draft I support the adoption of this draft by the work group. While 3GPP specifies slicing aspects within the 3GPP network, how it gets mapped to transport networks when there are different transport network options is not clearly specified anywhere. In this regard this draft provides mechanisms for plumbing 3GPP network slicing with transport network slicing and in the context of realizing end to end use cases, it naturally fits into DMM WG's charter. The authors have addressed most of the comments received earlier and there is a general interest in this draft. Regards Sridhar On Mon, Jan 4, 2021 at 3:47 AM Jeff Tantsura wrote: > Hi, > > I support adoption of the draft as co-author. > The draft provides very much needed TN aware mobility framework. > Co-authors have addressed all the comments provided. > I believe there’s singifincat interest in the work, also outside of IETF > > Cheers, > Jeff > On Dec 30, 2020, 10:45 AM -0800, Sri Gundavelli 40cisco@dmarc.ietf.org>, wrote: > > > Folks: > > The authors of the document, Transport Network aware Mobility for 5G, have > presented the proposal and the need for standardization in multiple IETF WG > meetings. There have been good amount of discussions in the mailers and > there is some level of interest for the work from the community. We are > therefore considering the adoption of this document as a DMM WG document, > to be moved on Informational Standards track. > > *Transport Network aware Mobility for 5G* > tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08 > > > With this background, we would like to ask the WG to provide some feedback > on their interest for this work. Please provide substantial comments as why > this SHOULD be adopted, or why it SHOULD NOT be adopted. If there is > interest, and if there are no other concerns from AD/IESG/Others, then we > may take up this work. > > The adoption call will end on 18th of January, 2021. > > Regards > DMM WG Chairs > > > ___ > dmm mailing list > dmm@ietf.org > www.ietf.org/mailman/listinfo/dmm > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt
Dear authors, I have the following comments on the draft. 1. Section 4. The following statement is not clear >> The user plane described in this document does not depend on any specific architecture. What does "this document" mean here? The previous paragraph talks about TS 23.501. Does "this" document mean 23.501 or this IETF draft? 2. If "this document" meant 23.501, then the statement " does not depend on any specific architecture" is incorrect. 3GPP TS 23.501 requires, the packet detection and forwarding rules at every UPF in the forwarding path be controlled via N4. See TS 23.501 clause 5.8.2.4.1 ** The SMF is responsible for instructing the UP function about how to detect user data traffic belonging to a Packet Detection Rule (PDR). The other parameters provided within a PDR describe how the UP function shall treat a packet that matches the detection information. * 3. Section 4 - the following statement is not accurate Sometimes multiple UPFs may be used, providing richer service functions. A UE gets its IP address from the DHCP block of its UPF. IP address allocation is not always by way of DHCP. A UPF may serve an IP pool and SMF may assign IP address to UE from the pool. Suggest to change it as "A UE gets its IP address via N1 SM NAS signaling from the SMF. The IP address management mechanism is specified in clause 5.8.2.2 of 3GPP TS 23.501" 4. Throughout the document there is this term "UE session" repeating. Its better to clarify that this refers to "UE PDU Session". 5. Section 5.1.1 gNB_out : (gNB, U1::1) (A,Z) -> T.Encaps.Red UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP Also note that the conventions in section 2.2 says: * U1::1 is an IPv6 address (SID) assigned to UPF1. o U2::1 is an IPv6 address (SID) assigned to UPF2. a. How does UPF1 identify the N4 session related to the UE PDU session? b. Does End.MAP function provide a PDU session specific mapping? c. Since U1::1 and U2::1 are just IPv6 addresses as specified in section 2.2, how does the UPF1 and UPF2 use it to identify the PDU session specific forwarding / packet handling rules? 6. Same question as above for downlink direction - in section 5.1.2 7. Section 5.2.1 gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red If I understand correctly in enhanced mode, you propose to insert SID list. a. Isn't the SID list part of SRH? b. If so, why use T.Encaps.Red which is defined as encapsulation without SRH insertion? c. Aren't U2::1 and C1 part of the SID list? d. How does UPF 2 identify the N4 session related to the UE PDU session? 8. Section 5.2.2 UPF2_in : (Z,A) -> UPF2 maps the flow w/ SID list UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)-> T.Encaps.Red First step talks about UPF 2 inserting SID list while second step talks about using T.Encaps.Red which is a function that does not insert SRH. So how is SID list inserted into the packet? All other questions raised in /7/ above hold here as well. 9. Section 5.3.1 o The SRGW removes GTP, finds the SID list related to DA, and adds SRH with the SID list. Does the SID list added here only contain UPF or SR node addresses? How does each UPF in the SID list identify the specific N4 session related to the PDU session the packet belongs? How does each UPF apply the packet forwarding treatment as provided in the N4 session creation request into the UPF for the PDU session? I may have number of other questions. But a basic clarity on the above is required first. Could the authors please clarify? Regards Sridhar Bhaskaran -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org Sent: Tuesday, March 12, 2019 1:42 AM To: i-d-annou...@ietf.org Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-srv6-mobile-uplane-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Distributed Mobility Management WG of the IETF. Title : Segment Routing IPv6 for Mobile User Plane Authors : Satoru Matsushima Clarence Filsfils Miya Kohno Pablo Camarillo Garvia Daniel Voyer Charles E. Perkins Filename: draft-ietf-dmm-srv6-mobile-uplane-04.txt Pages : 28 Date: 2019-03-11 Abstract: This document shows the applicability of SRv6 (Segment Routing IPv6) to the user-plane of mobile networks. The network programming nature of SRv6 accomplish mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying tra
[DMM] Comments on draft-clt-dmm-tn-aware-mobility-02
Dear all, I reviewed draft-clt-dmm-tn-aware-mobility-02 and I have the following comments based on 3GPP architectural definitions in TS 23.501 / 23.502 1. Section 2.1 - RQI is just a flag to tell the UE that it has to reflect back the same QFI in the uplink packet. RQI on its own is not a QoS indicator. Hence the use of RQI in the following sentence is not correct Mapping of the PDU sessions to TE paths can be done based on the source UDP port ranges (if these are assigned based on the PDU session QCIs, as done in some deployments with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or RQI values in the GTP-U header. 2. Section 2.1, 2.2 - and almost everywhere - Restricting to description of gNB as the radio side is not correct. 5G architecture allows the radio or access node to be any of the following: a) gNB (which means radio is NR) b) Ng-eNB (which means radio is EUTRA) c) Untrusted WLAN d) From R16 onwards wireline and Trusted wireless LAN access So the draft should generally mention as 5G-AN and not as gNB. 3. The draft mixes SSC modes with slicing concept. SSC modes and slicing are two independent concepts. UL/CL and BP UPF are applicable to all SSC modes. SSC modes do not have any relevance when selecting a transport path. The description of SSC modes need to be corrected to rather reflect how / where the PPR-ID is applied for different SSC modes. Regards Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00
Dear Shunsuke, Thank you for your responses. My further comments inline marked [SB-2] Regards Sridhar Bhaskaran -Original Message- From: Shunsuke Homma [mailto:homma.shuns...@lab.ntt.co.jp] Sent: Wednesday, January 16, 2019 9:30 AM To: Sridhar Bhaskaran ; dmm@ietf.org Subject: Re: [DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00 Hi Sridhar, Thank you for your review and comments. (And I'm sorry for the late replay...) Please find my replies in-line.(Tagged with [SH].) Best regards, Shunsuke On 2019/01/09 12:00, Sridhar Bhaskaran wrote: > Dear authors of draft-ietf-dmm-5g-uplane-analysis-00, > > Thank you for the draft. > > I have the following questions for clarification and comments on > draft-ietf-dmm-5g-uplane-analysis-00 > > Questions > > 1. Section 3.6 - could you elaborate on what you mean by > >>> [GTP-U-6]: Does not support to response ICMP PTB for Path MTU > Discovery. > [SH] What we want to say in this observations is that 3GPP does not define PMTUD in user plane while TS23.060 requires well managed MTU size.Thereby there's no specification on how to handle ICMP Packet Too Big message at U-Plane functions like UPF. But if ICMP PTB message is generated at an intermediate router, the UPF which receives PTB message may not take any action due to lack of 3GPP specification. It may cause black hole for mobile user. [SB-2] It would be better to clarify how 3GPP allows MTU size communication to UE now and when the statement marked [GTP-U-6] is applicable. In my opinion this becomes applicable when the MTU size provided to UE as specified in TS 23.060 is not adhered to by UE or when that size is incorrect. > 2. Section 4.1 > >>> These tunnels are available to be handled by other > authorized functions through the control plane. > > Could you elaborate on what you mean by "other" authorized functions? Right > now only SMF is allows to setup / teardown tunnels via N4 at UPF. > [SH] "other authorized functions" means functions which are external to the 5GS owned by the NOP. The 5GS has NEF and it provides some controllabilties to external parties. For example, an MVNO may handle UP tunnels/traffic flows on UPFs via NEF, SMF, and N4 interface. I can modify this text to describe the above more clearly. [SB-2] You may clarify this in the draft clearly stating that tunnel setup is controlled only by SMF (by N4) while the SMF may be provided information regarding the routing path based on API request from AF (application function) to NEF / PCF. > 3. Section 4.2 Arch-Req-3: Could you please clarify the following sentence? > First part of sentence talks about multiple PDU sessions but end of the > sentence talks about one PDU session. So its not clear to me which case this > is talking about. > > However > it should be the multiple PDU sessions multihoming case where the > destination gNB or UPF needs to maintain multiple tunnel states under > the one PDU session to one UP tunnel architectural principle. > [SH] What we want to express here is that multihoming with P2P needs to maintain a tunnel state for each source UPF which leads increase of loads on management of tunnel states. [SB-2] Please consider rewording the above sentence to make it clear. > > 4. Section 4.2 - Arch-Req-5. I am not able to understand the following > sentences. Could you clarify what you mean by "connecting them without extra > anchor points"? Also what does "them" refer to here? Does it refer to UE or > UPF? > > In addition, deployment of multiple UPFs as anchors closed to UEs' > site and connecting them without extra anchor points enable to make > data path more efficient. > [SH] In the current LTE, all of UP traffic is forwarded to a P-GW which is centralized and it may cause trombone routing. On the other hand, the 5GS allows flexible deployment of UPFs mainly for MEC use cases. For example, in case these UPFs are distributed geographically, UP flows can be applied LBO or forwarded between UPFs nearby src and dst directly. Anyway, I think it should be described in ARCH-Req-4: Flexible UPF selection, and I'll move this text to there. [SB-2] But the sentence reads as "multiple UPFs as *anchors*" closer to UE" --> are you talking about BP UPF / ULCL UPF case? For UE to UE routing (e.g. for voice call) within same network - are you hinting at routing via an anchor UPF closer to RAN? Some details on the exact scenarios you are mentioning will help the reader. Even if you move this to Arch-Req-4 the statements need to be clearly elaborated as per scenarios you are considering. > > 5. Section Arch-Req-5: Are the following statements an architectural > requirement derived from 23.501 or an a
[DMM] Questions and comments on draft-ietf-dmm-5g-uplane-analysis-00
Dear authors of draft-ietf-dmm-5g-uplane-analysis-00, Thank you for the draft. I have the following questions for clarification and comments on draft-ietf-dmm-5g-uplane-analysis-00 Questions 1. Section 3.6 - could you elaborate on what you mean by >>[GTP-U-6]: Does not support to response ICMP PTB for Path MTU Discovery. 2. Section 4.1 >>These tunnels are available to be handled by other authorized functions through the control plane. Could you elaborate on what you mean by "other" authorized functions? Right now only SMF is allows to setup / teardown tunnels via N4 at UPF. 3. Section 4.2 Arch-Req-3: Could you please clarify the following sentence? First part of sentence talks about multiple PDU sessions but end of the sentence talks about one PDU session. So its not clear to me which case this is talking about. However it should be the multiple PDU sessions multihoming case where the destination gNB or UPF needs to maintain multiple tunnel states under the one PDU session to one UP tunnel architectural principle. 4. Section 4.2 - Arch-Req-5. I am not able to understand the following sentences. Could you clarify what you mean by "connecting them without extra anchor points"? Also what does "them" refer to here? Does it refer to UE or UPF? In addition, deployment of multiple UPFs as anchors closed to UEs' site and connecting them without extra anchor points enable to make data path more efficient. 5. Section Arch-Req-5: Are the following statements an architectural requirement derived from 23.501 or an architectural requirement this draft is putting on 3GPP? Atleast the words " UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel." Seems like this draft is putting a requirement on 3GPP. It is expected that multiple UPFs with per session tunnel handling for a PDU session becomes complicated task more and more for a SMF by increasing number of UPFs, and UP protocol shall support to aggregate several PDU sessions into a tunnel or shall be a session-less tunnel. Comments: == 1. Section 4.1.1 - traffic detection based on UE IP address and SDF filters is missing in the below list o For IPv4 or IPv6 PDU Session type * PDU Session * QFI * Application Identifier: The Application ID is an index to a set of application detection rules configured in UPF 2. Section 4.2 Arch-Req-2: >> The 5G system requires IP connectivity for N3, N6, and N9 interfaces. There is a specific case where IP connectivity on N6 is not mandatory. For Ethernet PDU sessions, the anchor UPF could use L2 switching on N6 side. You refer clause 5.6.10.2 of TS 23.501 especially the statements below - Configurations, where more than one PDU Session to the same DNN (e.g. for more than one UE) corresponds to the same N6 interface. In this case the UPF acting as PSA needs to be aware of MAC addresses used by the UE in the PDU Session in order to map down-link Ethernet frames received over N6 to the appropriate PDU Session. Forwarding behaviour of the UPF acting as PSA is managed by SMF as specified in clause 5.8.2.5. 3. Section 4.2 Arch-Req-3: Multihoming is provided with Branching Point (BP) or Uplink Classifier (UL CL) which are functionalities of UPF. ULCL is not used for multihoming. ULCL is used for traffic splitting towards a local DN. Only BP is used for multihoming case. 4. Section 5 is missing one evaluation aspect. GTP-U supports "End markers" to help RAN sequence the packets when there is a change of UPF during mobility procedures. So any user plane protocol that is to be evaluated need to support some mechanism to help the last downlink node on path (e.g gNB) to sequence the packets coming from multiple UPFs during mobility cases. 5. Section 5.7 - Need justification for the following statement: However some means need to indicate a slice on the shared underlying networks of the UP over the wire. What is broken or what is the issue if slice for transport is not indicated on the UP over the wire? What are the issues with providing a "network instance" (which could be mapped to a transport path) in the forwarding action rule of a PDU session? What are the advantages of carrying slice information in every packet? Regards Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document
Hi David Lake, Could you please clarify what is your reference for the following statement? >> The CT4 study for future user-plane makes it clear ***that for cross-domain >> connections GTP is problematic on N9 and alternatives could be >> considered. Regards Sridhar Bhaskaran -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of d.lake=40surrey.ac...@dmarc.ietf.org Sent: Thursday, November 15, 2018 3:09 PM To: homma.shuns...@lab.ntt.co.jp; dmm@ietf.org; david.i.al...@ericsson.com Cc: s.homma0718+i...@gmail.com Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document Dave I agree with you. In Rel 15 it is clear that the user plane protocol on both N3 and N9 is GTP. The CT4 study for future user-plane makes it clear that for cross-domain connections GTP is problematic on N9 and alternatives could be considered. The timeframe is Rel 16 and the working document is TR 29.892. So far there are TWO candidate protocols in the document: 1) GTP 2) SRv6 However, this is a working document and there is plenty of scope to add other candidates in advance of the adoption of the output of CT4 (not sure what date that is - my guess would be sometime round the end of 2019?) So I think IN SCOPE for DMM is suggesting, detailing, explaining new User Plane candidate protocols. OUT OF SCOPE of the DMM is deciding which of those protocols makes it into Rel 16. Surely there are more than 2 candidate protocols we could consider for N3 and N9!? David -Original Message- From: dmm On Behalf Of Shunsuke Homma Sent: 15 November 2018 09:19 To: dmm@ietf.org; david.i.al...@ericsson.com Cc: s.homma0718+i...@gmail.com Subject: Re: [DMM] Call for adoption of draft-hmm-dmm-5g-uplane-analysis-02 as DMM WG document Hi Dave, Thank you for reviewing our draft and sending your thought for the adoption. When I reviewed the charter I couldn't find any text to make the draft to be out of scope. Could you please elaborate it with the text in the charter? Best regards, Shunsuke On 2018/11/15 6:52, David Allan I wrote: > HI > > AFAIK 3GPP CT4 is looking for work it can adopt, and has indicated > that it wishes to perform the analysis itself. When they were directed > to this document in the recent IETF DMM liaison, it resulted in a > liaison reply clearly indicated they would define their own criteria. > > https://datatracker.ietf.org/liaison/1590/ > > However in the draft it states in the introduction: "However we > believe that to provide adequate information for 3GPP, we need to > clearly understand what the current user plane protocol is in Release > 15, and architectural requirements for the user plane." And in the > conclusion "Our conclusion here is that we suggest the UP protocol > study work in 3GPP takes into account the evaluation aspects described > in Section 5.", there is more, but I do not feel a need to be pedantic about > it. > > So the purpose of this draft seems to explicitly be to do work for > 3GPP that they have explicitly said they DO NOT WANT. > > At the same time I do not see anything in the charter that suggests we > should be doing this work either. It would appear to have little to > do with DMM's chartered direction. > > As such I am opposed to adoption of the draft. > > Cheers > > Dave > > > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- -- Shunsuke Homma TEL: +81 422 59 3486 FAX: +81 422 60 7460 NTT Network Service Systems Labs. Musashino city, Tokyo, Japan -- ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
;>>>>>>> > >>>>>>>>>> A factor worth considering though is that the use of GTP and > >>>>>>>>>> TEID in mobile > >>>>>>>>> core allows operators to deal with QoS on their own terms. The > >>>>>>>>> tunnels with specific operator-controlled QoS are established > >>>>>>>>> by the control plane between eNB, SGW, and PGW. UEs or > >>>>>>>>> applications sitting in the UEs have no say in this. Well at > >>>>>>>>> least till the packet exits operator's > >>>>>>> network. > >>>>>>>>> > >>>>>>>>> The problem with one header, is that if you re-mark (known as > >>>>>>>>> PHB markign in the ole days) you lose the original value. > >>>>>>>>> Encapsulation is useful here because you can map the inner to > >>>>>>>>> outer and anywhere along the path you can PHB remark on the > >>>>>>>>> outer header. And then the destination can see the orignal > >>>>>>>>> source’s ToS/QoS/TC/flow-label > >>>>> whatever. > >>>>>>>> > >>>>>>>> > >>>>>>>> [Arashmid] Yes, I agree. The original value is lost with PHB. > >>>>>>>> Encapsulation certainly makes things easier and the inner to > >>>>>>>> outer mapping trick has been widely used in IP and MPLS(multiple > >>>>>>>> labels like service and transport) > >>>>>>>> > >>>>>>>>> > >>>>>>>>>> Using the information in UE's IP packet header can jeopardise > >>>>>>>>>> the above tight QoS control. I think going > >>>>>>>>> > >>>>>>>>> Not if you encapsulate. But note with SRv6, you can possibly > >>>>>>>>> retain the original flow-label if the SID can retain those bits > >>>>>>>>> before overwriting the destination address from the option’s > value. > >>>>>>>> > >>>>>>>> [Arashmid] Agree. Encapsulation does the trick again. That's why > >>>>>>>> GTP has worked well and served the purpos in the mobile > >>>>>>>> back-haul so far. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Dino > >>>>>>>>> > >>>>>>>>>> down this path, operators need proof that they will be still > >>>>>>>>>> in the driving > >>>>>>>>> seat and QoS cannot be dictated/tampered by the UE or any > >>>>>>>>> application running in it. > >>>>>>>>>> > >>>>>>>>>> Now, here is an interesting question for the operators. Would > >>>>>>>>>> any operator > >>>>>>>>> be interested in allowing QoS to be set by the UE or by > >>>>>>>>> applications running in the UE and charged for by the network? > >>>>>>>>> "Yes" could potentially imply impacts on the air interface, UE > >>>>>>>>> resource block allocation and can make scheduling on the RAN > >>>>>>>>> side > >>>>> much more complex. > >>>>>>>>>> > >>>>>>>>>> Arashmid > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> -Original Message- > >>>>>>>>>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino > >>>>>>>>>>> Farinacci > >>>>>>>>>>> Sent: 06 September 2018 12:45 > >>>>>>>>>>> To: Tom Herbert > >>>>>>>>>>> Cc: ta-miyas...@kddi-research.jp; dmm > >>>>>>>>>>> Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane- > >>>>> analysis- > >>>>>>> 01 > >>>>>>>>>>> > >>>>>>>>>>>> Behcet, > >>>>>>>>>>>> > >>>>>>>>>>>> I was thinking if TEID is need then that can be encoded in a > >>>>>>>>>>>> locator easily enough. > >>>>>>>>>>>> > >>>>>>>>>>>> Tom > >>>>>>>>>>> > >>>>>>>>>>> Not if a locator is a PGW that is shared by many UEs. > >>>>>>>>>>> > >>>>>>>>>>> 3GPP wants per bearer awareness so they need a specific ID, > >>>>>>>>>>> that could have been the UE’s IP address. And with IPv6 it > >>>>>>>>>>> can be unique and not the issue that Sridhar brought up. > >>>>>>>>>>> > >>>>>>>>>>> If ILA was in use, just use the ILA-ID for this purpose. > >>>>>>>>>>> > >>>>>>>>>>> Dino > >>>>>>>>>>> > >>>>>>>>>>> ___ > >>>>>>>>>>> dmm mailing list > >>>>>>>>>>> dmm@ietf.org > >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm > >>>>>>>> > >>>> > >>> > >>> ___ > >>> dmm mailing list > >>> dmm@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dmm > >>> > >> > >> > > > > ___ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > ___ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > -- > Shunsuke Homma > > > TEL: +81 422 59 3486 > FAX: +81 422 60 7460 > > NTT Network Service Systems Labs. > Musashino city, Tokyo, Japan > -- > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > ___ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- o__ _> /__ (_) \(_)... Burn fat not fuel - Bike along to a healthier life and cleaner world! :) Sridhar Bhaskaran ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
My comments inline marked [SB] > >>> It was never clear to me and no one could ever explain exactly why a > TEID is needed. I presumed for accounting reasons. But if there was a > one-to-one mapping between tunnel and user, why couldn’t the inner > addresses be used for accounting? > > > > [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a > tunnel and hence consequently a bearer. Once the bearer context is > identified the QoS and charging policy applicable to the bearer is applied. > So the purpose of TEID is not just for accounting. Its for QoS treatment, > charging and bearer context identification. > > You told me what a TEID is but you didn’t say why you need to use it > versus using the destination IP address for the tunnel. > > > In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU > session whereas the QFI carried in GTPU extension header identifies the > flow. So in 5G TEID + QFI is used for QoS treatment and charging. > > When a packet is encapsulated in a tunnel, a packet has 4 addresses, which > tells us (1) the UE, (2) the destination it is talking to, (3) the > encapsualting node, and (4) the decapsulating node. > > So again, why use more space in the packet, when you have sufficient > information to identify a user, and therefore their packet policy? > > [SB] Lets say we only use UE IP address and no TEID. How will you identify the bearer context the packet belongs? One UE may use multiple radio bearers / QoS flows. DSCP in IPv4 and Flow Label in IPv6 is one option but these are IP level markings which could be changed by any on path routers. In order to uniquely identify the bearer / qos flow a particular packet for a UE belongs, GTPU uses TEID. Also the IP addresses (at least for IPv4) allocated to UE by PGW / SMF are not always unique. The same IP pools can be shared across multiple PDNs / DNs as long as these PDNs / DNs are separate autonomous networks. So just relying on UE IP address alone will result in wrong context identification for the uplink traffic. There is a clear one to one mapping of Radio bearer to the EPS bearer / QoS flow required all the way upto the anchor node for charging and QoS treatment. This comes from the requirements in stage 2 documents (c.f section 4.7 of TS 23.401 for EPC and 5.7 of TS 23.501 for 5G). There are also requirements to support non-IP protocols like Ethernet PDU and Unstructured PDU types in 5G. >> > > >>> How can packets be sent if the session is not setup. If the session > is not setup, the encapsulator should have no state. And packets should be > dropped locally and not go far to get an error back. This sounds > architecturally broken. > > > > [Sridhar] The purpose of GTP-U error indication is to signal in band to > the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is > lost for any reason. "No session exist" does not mean Session > > What does lost mean? You mean the path from encapsulator to decapsulator > is not working? And since we are in a packet network, that path can be > restored quite quickly. > [SB] Lost here means - the "context" at the receiving entity is deleted. For e.g due to administrative reasons, gNB or eNB removes the radio bearers and correspondingly the GTPU context. If gNB or eNB loses a context for known reasons, there could be signaling from gNB / eNB to AMF/MME and corresponding removal of PDU session / EPS bearer at the core network. But if the context is removed due to administrative reasons or unforeseen local errors, signaling from gNB / eNB to AMF / MME may not happen. Hence the GTPU error indication is an inband error detection mechanism. Note TEID identifies a context at the receiving side. So all GTPU error indication tells is that the receiver is not able to identify any context for the received TEID. > > is not setup. "No session exist" scenario after a session setup can > happen due to local error conditions, bearers released for administrative > reasons etc. > > So at the encapsulator, do you choose another decapsultor? Note that > tunnels *usually* stay up since the topology that realizes the tunnel is > robust and redundant. > > >> > > >>> You should explain in summary form the model the control-plane uses.. > Does it use TCP for reliability, does it use multicast, is it like a > routing protocol, is it like a management protocol. What are the failure > modes, the state/bandwidth tradeoffs. > > > > [Sridhar] Explaining all these in IETF draft is simply reproducing what > is already there in TS 29.244. A reference to TS 29.244 should be enough. > See section 6.4 of TS 29.244 for reliable delivery of PFCP messages. > > Just pointing people to drafts doesn’t help in understanding. It requires > people to go off, put in a lot of time where the odds are their question > will not be answered. > [SB] TS 29.244 is not a draft but rather a full fledged technical specification. The issue with repeating content from elsewhere instead of just pointing is
Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01
Dear Dino, Some clarifications on your comments >>> It was never clear to me and no one could ever explain exactly why a TEID is needed. I presumed for accounting reasons. But if there was a one-to-one mapping between tunnel and user, why couldn’t the inner addresses be used for accounting? [Sridhar] In EPC, each bearer has a GTPU tunnel. TEID identifies a tunnel and hence consequently a bearer. Once the bearer context is identified the QoS and charging policy applicable to the bearer is applied. So the purpose of TEID is not just for accounting. Its for QoS treatment, charging and bearer context identification. In 5G, each PDU session has a GTPU tunnel. So TEID identifies the PDU session whereas the QFI carried in GTPU extension header identifies the flow. So in 5G TEID + QFI is used for QoS treatment and charging. >>> How can packets be sent if the session is not setup. If the session is not setup, the encapsulator should have no state. And packets should be dropped locally and not go far to get an error back. This sounds architecturally broken. [Sridhar] The purpose of GTP-U error indication is to signal in band to the sender that a GTP-U tunnel endpoint (TEID) at the receiving side is lost for any reason. "No session exist" does not mean Session is not setup. "No session exist" scenario after a session setup can happen due to local error conditions, bearers released for administrative reasons etc. >>> You should explain in summary form the model the control-plane uses. Does it use TCP for reliability, does it use multicast, is it like a routing protocol, is it like a management protocol. What are the failure modes, the state/bandwidth tradeoffs. [Sridhar] Explaining all these in IETF draft is simply reproducing what is already there in TS 29.244. A reference to TS 29.244 should be enough. See section 6.4 of TS 29.244 for reliable delivery of PFCP messages. Thanks Sridhar 3GPP CT4 Delegate ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt
Dear Satoru, I am Sridhar Bhaskaran - 3GPP CT4 delegate. In addition to John's questions, I have few more questions for clarification. 1. Section 5.2.2 of the draft says, UPF2_in : (Z,A) -> UPF2 maps the flow w/ SID list <C1,S1, gNB> When the packet arrives to the UPF2, the UPF2 will map that particular flow into a UE session. Does this mean the UPF2 is aware of the gNB the UE is latched on and hence after each mobility, the information regarding current gNB is signaled / programmed till the UPF2 (which could be the PDU session anchor UPF)? 2. For traditional mode (basic mode), could you please elaborate on the MTU overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer IPv4 header + 8 octets UDP header + 12 octets GTPU header + Extension header for QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying QFI (this part is not clear - see my next question). In your blog https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/ I noticed in Fig.1 the MPLS / TE headers included in calculation. So does the MTU overhead saving talked about for SRv6 assume that underlay TE technologies are replaced? It is not clear from the draft. If there are any other drafts that provide a clear calculation on the MTU savings, could you please point to them? 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced mode)? In GTPU the QFI/RQI markings are carried in a GTPU extension header, defined as a container. Please refer the following documents for details Incoming LS from RAN3 to CT4: http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182214.zip Corresponding agreed CR in CT4: http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182246.zip LS out from CT4 to RAN3: http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Montreal/Docs/C4-182247.zip Thanks Sridhar -Original Message- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru Matsushima Sent: Tuesday, March 13, 2018 6:55 AM To: John Kaippallimalil <john.kaippallima...@huawei.com> Cc: dmm <dmm@ietf.org> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt John, > 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール: > > A few questions for clarification: > 1. Section 5.1.1, "..Since there is only one SID, there is no need to push an > SRH..." > In this case the outer IPv6 address representing a SID would contain a TEID. > So for 1000 PDU sessions - would there be as many IPv6 addresses > (representing SIDs/TEID in the outer header) Right. It is not limited but in a typical case given that a /64 per node for the SID space which allows each node allocate a SID per session basis. > > 2. Section 5.2 (& Figure 3), suppose there were more than 1 UPF on > path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns - > S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to chain > functions along the path to UPF1, > or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. > upto the anchor UPF2. Please see the section 5.2.1 of packet flow on uplink. We assume that there’s no UPF1 along the path in the diagram. > > 3. Section 5.2, "The SR policy MAY include SIDs for traffic engineering and > service chaining ..." > 3GPP service chaining is at N6 interface, but in this case, is the policy for > traffic steering implemented at the N3 interface. > Would PCF/SMF provision this at gNB. When it comes to enhanced mode for control-plane side, it may literally be enhanced. But at this revision of the draft, it is assumed that gNB is capable to resolve SR policy from remote endpoint address of tunnel to SIDs list while N2 is unchanged and kept as it is. Cheers, --satoru > > Thanks, > John > > > > -Original Message- > From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] > Sent: Mittwoch, 7. März 2018 12:23 > To: Marco Liebsch > Cc: dmm > Subject: Re: [DMM] Fwd: I-D Action: > draft-ietf-dmm-srv6-mobile-uplane-01.txt > > Marco, > >> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール: >> >> Satoru, >> >> since I read this at different places, let me ask one clarifying question >> about the stateless motivation: >> >> I see that for SRv6 you may not need a state at the egress (at least >> not for traffic forwarding) but for Uplink/Downlink (UL/DL) you need >> a state at both edges of the communication since the DL egress serves as >> uplink ingress, correct? > > 2x unidirectional tunnels to form bidirectional paths
