> Dear Dino, > > Some clarifications on your comments I am going to use general terms here so we don’t get hung up in IETF and/or 3GPP terminology. Which doesn’t make things clear to anyone really. So we can stay on point.
> >>> 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? >> > >>> 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. > 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. 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. Dino > > Thanks > Sridhar > 3GPP CT4 Delegate _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
