On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran <[email protected]> wrote: > 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.
Sridhar, Couldn't the TEID be encoded in the outer IP address of an encpasulation or network overlay in a similar way that VNIs are encoded in IP addresses in virtual networking? Tom > > 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 > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
