Sridhar, > [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.
Then you have proven there is a lot of simplication opportunity. That is, use the IP header for charging, and for ethernet serivce encapsulate that at the UE so the eNodeB has a common and single way of classifying packets. > > >> > > >>> 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. Right, you are using “sessions” or “connections” at a packet layer. That is the fundamental problem. Why can't this 3GPP network be more like an IP network? You know that most of the critical traffic is IP traffic, even voice these days. It looks like the dmm WG should propose a slice that is called an IP slice where we just do good ole datagram routing over it. Do charging with packet counters and strive to make the 3GPP network like an ethernet (or wifi network). I would like to hear arguments why this can’t be done. It is definitely a good place to start for 5G IMO. You do this and we can give users IP mobility from 3GPP to wifi more seamlessly. IMO, if 3GPP does not solve the 3GPP to wifi mobility problem, it has failed to solve real world problems. > > 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 the risk of providing inaccurate information in IETF draft. My point is that if you would simply summarize here in email, a lot of people could learn from you. That would be user friendly. Refering to a sequence of documents is not really helpfull. > The points I’m trying to make is not “what it is” you are designing but “why > you did what you did” in the design. That is rarely in the specs. > > [SB] 3GPP SA/CT groups follow a waterfall model - service requirements are in > 22 series specs, system architecture in 23 series specs and protocol in 29 > series specs. You could always trace back the reason for a particular design > aspect in a protocol to a corresponding architectural requirement in 23 > series or a system requirement in 22 series specs. Are you saying since there are so many specifications, you can’t in an email explain “why you did it this way”? Thanks for the reply, Dino _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
