Folks, let's not forget that most of these things you are talking about are session layer issues. According to OSI layering, the session layer is Layer 5, above Layer 4 which is transport layer. 3GPP is using UDP which is Layer 4 for this session layer coding. I think probably it is a better layer than the Internet layer which would be the case with IdLoc protocols, I think even with LISP which uses UDP encapsulation.
Behcet On Thu, Sep 6, 2018 at 11:21 AM Tom Herbert <t...@quantonium.net> wrote: > 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
