Cellular Network Infrastructure » Core Network (CN) » osmo-gbproxy

Some more questions came up while discussing this with lynxis:

• What happens if we receive a BSSGP message, but it is larger then the MTU on the destination NSE? Return with status?
• Do we need to dynamically change the MTU, how should we deal with NSEs where differnet NS-VCs have different MTUs (think VLAN interface vs. plain ethernet)? Report the lowest?
• What if the MTU changes because one NS-VC with a different MTU became (un)available? We need to update the BSSGP MTU on the fly.

Some more observations:

gbproxy still uses a mixture of bssgp and bssgp2/bssgp_fsm code. For status bssgp_tx_status is used which is completely unaware of the BSSGP FSMs.
I'm not sure if and when we want to use osmo primitives in bssgp2, but this would probably a bigger refactor which we don't have time for right now.

So right now I would make the bssgp fsm mtu-aware and add a REQ_STATUS event to the BSSGP fsm which then sends a (truncated) STATUS through it's BVC. This would then be used by the gbproxy

Relevant comment from https://gerrit.osmocom.org/c/libosmocore/+/22343

also here I'm not sure if we really should worry about the MTU of the ethernet.

In the end, we have potentially larger BSSGP frames and there is no way to influence the size of the upper layer frames. Think of a PDP context with MTU 1500 (or close to that), plus the LLC, SNDCP, BSSGP overhead -> boom.

Yes, we may end up generating IP fragments. But then, the bandwidth of GPRS is ultra low, so what do we care about some more packets in the core network over wired interfaces that likely have more than a thousand time more bandwidth than our radio interface.

If we enforce staying within the MTU of the ethernet device, we would start dropping packets with no way to inform this up the protocol stack so that the LLC/SNDCP XID exchange could negotiate smaller packet sizes. - i.e. we'd effectively break the network completely.

I think the only situation wherer the MTU matters is in the case of FR, where we have a fixed, well-known MTU and no support from the transport (FR) to do segmentation / fragmentation by itself. Luckily it's 1600, and hence we do have some room for BSSGP/LLC/SNDCP overhead

Since we can fragement in IP the MTU should only ever matter when using frame-relay. There are not NSEs that have mixed ll-types (e.g. FR/GRE and FR) so the MTU of an NSE should never change during its lifetime.

There is an update for support from NS https://gerrit.osmocom.org/c/libosmocore/+/22343 and I started working on BSSGP support.

See
https://gerrit.osmocom.org/q/topic:%22os%25234889%22+(status:open%20OR%20status:merged)
for the list of patches

Fixed with 38b9c9a9