Project

General

Profile

Actions

Bug #4889

closed

implement truncating of BSSGP STATUS when exceeding the FR MTU

Added by laforge almost 2 years ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
12/06/2020
Due date:
% Done:

100%

Spec Reference:
48.018 10.4.14

Description

It might be that we receive a BVC-STATUS on the IP side with a UDP packet size that exceeds the FR MTU, at which point we need to truncate it (see "NOTE" in 48.018 10.4.14).

The same can also occur when generating a BVC-STATUS in response to a BVC messag received on a FR link. Let's assume we e.g. receive a UL-UNITDATA that's exactly the FR MTU of 1600 for a non-existant BVCI. Then the generated BSSGP STATUS must truncate the "PDU IN Error" IE accordingly.

To make all of this work, we have to "learn" the MTU from the underlying network device (we receive it together with the link status event messages but currently ignore it). Plus we then need to use this value when generating STATUS or even when passing on STATUS


Related issues

Related to osmo-gbproxy - Feature #4472: Intra-domain connection of OsmoGBPROXY to multiple SGSNs (pooling)Resolveddaniel03/29/2020

Actions
Actions #1

Updated by laforge almost 2 years ago

  • Related to Feature #4472: Intra-domain connection of OsmoGBPROXY to multiple SGSNs (pooling) added
Actions #2

Updated by daniel almost 2 years ago

  • Description updated (diff)
  • Status changed from New to In Progress
Actions #3

Updated by daniel almost 2 years ago

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.
Actions #4

Updated by daniel almost 2 years ago

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

Actions #5

Updated by daniel almost 2 years ago

  • % Done changed from 0 to 10

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.

Actions #6

Updated by daniel almost 2 years ago

  • % Done changed from 10 to 30

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

Actions #7

Updated by daniel over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 30 to 100

Fixed with 38b9c9a9

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)