On Thu, Sep 6, 2018 at 9:18 AM, Behcet Sarikaya <sarikaya2...@gmail.com> wrote: > > > On Thu, Sep 6, 2018 at 10:40 AM Tom Herbert <t...@quantonium.net> wrote: >> >> On Thu, Sep 6, 2018 at 3:24 AM, Sridhar Bhaskaran >> <sridhar.bhaska...@gmail.com> 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 >> > > ILA if used would remove any need for tunneling and TEID is for tunneling. > Behcet,
I was thinking if TEID is need then that can be encoded in a locator easily enough. Tom > Actually if you read 29.244 it is completely based on legacy protocols with > no IdLoc content at all, as Shunsuke mentioned. > > Behcet >> >> > >> > 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 >> > 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
