This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Neels Hofmeyr nhofmeyr at sysmocom.deOn Wed, Nov 04, 2015 at 04:46:41PM +0100, Andreas Schultz wrote: > The specs say to send replies to the IP and port where the request > originated. The GSN control plan address is only to be used when we > want to send a request to the other side. Goodness, really? > * for each request, cache the source IP+Port and forward the reply back > to that, Let's consider IP address and port separately. - IP address: The only time when the sender IP *can* even differ is during Create PDP Context messages. The only question is, where does the response to a Create PDP Context Request go. All other cases are clear. (For Update, only the Response can have differing IP address, but that's already the reply.) And even there it doesn't really make sense to have different addresses: the Create PDP Context Response coming back from the GGSN is explicitly addressed to the TEI that was declared in the Request. Why then would it be sent to a different IP address than the one that was also declared in the Request, explicitly to negotiate that TEI for that IP address? Like, for one more reply, the TEI belongs to the sender address, and just after that it belongs to the negotiated address? If this is used in practice, can anyone illustrate for what situation it is useful to negotiate a PDP context where the sender differs from the negotiated Ctrl address? Load balancing for User, yes, but Ctrl?? In the user plane the entire ambiguity does not exist at all. Messages are sent to the address that was in the Create PDP Context request, period. So I actually assume the ctrl plane works the same. OpenGGSN does actually reply to the same IP *and* port it received from, always. It also replies to the same IP address even if the IE's address in the Create Context Request differs. This may just disprove all my points. > >- Disallow mismatch of CTRL sender and address in CTRL IE. > > Seems like the reasonable thing to do. In that case, the SGSN sender address and the CTRL address in the Create PDP Context Request must be identical and all the awkwardness is cut out. And wouldn't work if someone tried to do that, of course. Does anyone? - Port: Ports can differ all the time. Any port number can be used as sender to send to a standard port of a peer. This becomes weird as soon as we're talking GTP packets that contain a nonzero destination TEI to send to. Echos send no TEI (zero), but they also don't require any resolution or tracing of peers: just reply, done. They go back to where they came from: 29.060 10.1.2.2: "NOTE: The source IP address of the Echo Response message shall be the same as the destination IP address of the Echo Request message." To see this "NOTE"d as loudly makes me assume that Echo is an exception in that way. If I'm sending a message for a specific TEI, sending it to a different port feels wrong. The TEI was negotiated as part of a Create PDP Context for an IP address, with no port information attached. The TEI hence, at least in my head, resolves to an IP address with the standard port. No matter if it's a request or a response. That was my first guess... But again OpenGGSN always replies to the sender. Say different ports are used, what is the scope for TEI, recovery and sequence number? Does an IP address share these across all its ports, or does each port have a separate set of TEIs? In case two separate ports know about the same TEIs, how then is it a problem if replies only ever go back to the default port? gtphub implementation wise, a known sequence number can be used to trace back to the sender port, and the TEI can then be ignored. Once an unknown sequence number arises, the TEI resolves to the default port. Having to manage ports per request seems unneccessary, on top of all the TEI business. Is there a benefit? Load balancing is done on the IP address level already, right? Is this ever used in the field? > I'm still trying to understand some of the finer points of GTP myself. If anyone can enlighten us with hard facts from the daily grunge of actual GTP usage, that would be appreciated :) We could examine some traces and check... - whether sender addresses ever differ from PDP Context message IE addresses, and where responses go. - whether port numbers are ever nonstandard, - where responses go, and - how TEIs and seq nrs seem to scope. > >I'm handling IPv4 and v6 transparently, BTW. The difference in the IE is only > >detectable from the IE length, as 7.7.32 doesn't include the GSN address' type > >field. Let's hope IPv8 will have the same length as IPv6 :P > > Lets hope all peers you are talking to are on the same IP version. Mixing IPv4 > and IPv6 peer will be fun (see the Alternative GGSN Address). Hmm yes, I just noticed that, too. Shall this and shall that. According to spec, you can't run a v6 GSN without also supplying alternative v4 addresses. I'll just let v6 tag along until it becomes relevant... Thanks again, this discussion helps a lot! ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20151104/c29edc83/attachment.bin>