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 the risk of providing inaccurate information in IETF draft.. > 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. For e.g as I explained above the reason for the existence of TEID - its the one to one mapping of radio bearer to an EPS bearer / QOS flow that demanded it.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
