On Thu, Sep 6, 2018 at 9:39 AM, Marco Liebsch <marco.lieb...@neclab.eu> wrote: > Tom, Behcet, I think TEID may still be needed in some cases, e.g. for mapping > to a radio bearer > or to avoid superfluous packet classification if it has been done on the > packet's path beforehand > already. > > IMO, for non-encapsulation protocols, overloading of id-loc space seems > interesting if the attribute > cannot be carried in extensions. What about encoding QoS class/flow IDs in > that space as well ;-) ? > Marco,
Yes, there is a lot of opportunity to encode different things in addresses. The giantic address space of IPv6 almost begs us to do that! :-) The amount of data is limited, so it's unlikely that we can encapsulate all of the GTP-U extension headers. But with some careful planning, we could probably encode the critical information that is most common for fast data path. Address encoding is critical to ILA and is what can eliminate the overhead of encapsulation for a fast, low latency, data path. Tom > marco > > -----Original Message----- > From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert > Sent: Donnerstag, 6. September 2018 18:22 > To: Behcet Sarikaya > Cc: ta-miyas...@kddi-research.jp; dmm > Subject: Re: [DMM] Comments to draft-hmm-dmm-5g-uplane-analysis-01 > > 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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
