https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092019-07-05T17:03:28ZOpen Source Mobile CommunicationsOsmoMGW - Feature #4092: Osmux: Support dynamic allocation of osmux socketshttps://projects.osmocom.org/issues/4092?journal_id=150792019-07-05T17:03:28Zpespin
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed" href="/issues/2551">Feature #2551</a>: generalization of OSMUX support in osmo-mgw</i> added</li></ul> OsmoMGW - Feature #4092: Osmux: Support dynamic allocation of osmux socketshttps://projects.osmocom.org/issues/4092?journal_id=150832019-07-05T17:15:33Zpespin
<ul></ul><p>Forgot to say: There should be a VTY flag to change the behavior explained above in the case there's no NAT in the setup, and remoteIP and remotePort can be used. Then no lookup is needed and localPort can be re-used for each <remoteIP,remotePort> tuple.</p> OsmoMGW - Feature #4092: Osmux: Support dynamic allocation of osmux socketshttps://projects.osmocom.org/issues/4092?journal_id=245962022-08-09T17:44:25Zpespin
<ul></ul><p>Now that we are adding Osmux on the BTS<->BSC link, there are also some more topics to take into account:</p>
<p>Let's call each set of CIDs 0-255 an "Osmux CID namespace", which is a CID to be used a destination over an Osmux link identified by <IPaddr,port>. The namespace and its values is hence controlled by the local host, assigning one namespace (0-255) to a <localIP+localPort>. <br />However, since in general we want to group payloads of the same namespace towards the same field, we actually better want to maintain a namespace based on <localIP+localPort,remIP+remPort>.</p>
<p>Example: Since there are several BTS connected to the BSC, that means that in general we want to group all osmux CIDs of the same BTS under the same Osmux CID namespace, so that they can be grouped when sending Osmux frames.</p>
<p>Similarly, a osmux node may handle one or more remote namespaces, each assigned to a given <remoteIP,remotePort>.</p>
<p>Further ranting regarding >256 Osmux users:</p>
<a name="Option-A"></a>
<h3 >[Option A]<a href="#Option-A" class="wiki-anchor">¶</a></h3>
<ul>
<li>On the BSC, when we do the first MGCP CRCX for the BTS side conn (X-Osmux: *), we still don't know the IPaddr and Osmux port which will be used by the BTS, which means osmo-mgw is unable to select a proper namespace from which to allocate a local CID and give it back in MGCP OK:
<ul>
<li>Right now we only support one namespace so it just simply picks the first available one.</li>
<li>When we add support for several namespaces, we probably want to answer MGCP OK with "(X-Osmux: *)" in the case were no remote IPaddr+port is received, then osmo-bsc signal to the BTS IPA CRCX with Osmux-CID IE with special value (0xff?) meaning we want to use Osmux but we still don't know the local CID of the BSC/MGW. Then, in IPA CRCX ACK the BTS provides the BSC with its local CID and IPaddr+port for osmux. Then BTS does MGCP MDCX providing the IPaddr+port+CID and get back the BSC local IPaddr+port+CID, which is set back on the BTS with IPAC MDCX.</li>
</ul></li>
</ul>
<p>With the above proposal, however, we'd have problems on the MSC+MGW, because the MSC also asks for the "X-Osmux: *" without knowing the remote IPaddr+port of the BSC+MGW, and has to send the local CID it got from its MGW before knowing it in BSSMAP Assignment Request. Hence the above proposal wouldn't work there.</p>
<a name="Option-B"></a>
<h3 >[Option B]<a href="#Option-B" class="wiki-anchor">¶</a></h3>
<p>What we could do is adding a new MGCP Extension by the side of "X-Osmux", called "X-Osmux-Namespace-Id" containing an unsigned integer. That would tell the MGW to select/allocate/use a CID from CID namespace identified by that unsigned integer. That Namespace-Id could be mapped dynamically (created first time a Namespace-Id is seen) with hashmap/tree in osmo-mgw in {key=namespace_id -> value=osmux_listen<local_ip,local_port>}.<br />The BSC can then set "X-Osmux-Namespace-Id: <bts-nr>" and "X-Osmux-Namespace-Id: 10000+<msc_nr>" for instance. Similarly, the MSC can set "X-Osmux-Namespace-Id: <bsc-nr>".<br />This way the BSC and the MSC give hints to the MGW on how to group osmux CIDs into namespaces which will potentially have the same IP address and port (same BTS in the case of BSC, same BSC+MGW in the case of MSC).</p>
<a name="Option-C"></a>
<h3 >[Option C]<a href="#Option-C" class="wiki-anchor">¶</a></h3>
We could simply increase Osmux-CID uint8_t -> uint16_t, which means we automatically don't have any problem having to many connections on one Osmux link. Some drawbacks:
<ul>
<li>We break compatibility with older Osmux implementations (not sure there's any running right now). To minimize the breakage, we could use uint8_t if CID < 0x80, and use first bit to indicate a uint16_t is used. This way at least implementations using up to 128 concurrent CIDs would remain compatible. This way we could also extend it to uint32_t if needed in the future (not sure if a MGW_msc would ever handle more than 65536 osmux conns anyway...).</li>
<li>Finding a new free CID becomes more complex now (right now it's done with a 256bitstring in a 256/8 byte array). This can be done now maintaining an ordered list or tree of allocated CIDs, then iterate until a spot is found.</li>
<li>In this case we'd basically maintain a shared unique local CID namespace mapped to a <localIP+localPort> since it would be big enough.</li>
</ul>
<p>Right now "Option B" or "Option C" seem the acceptable ways to me.</p> OsmoMGW - Feature #4092: Osmux: Support dynamic allocation of osmux socketshttps://projects.osmocom.org/issues/4092?journal_id=246022022-08-10T07:50:14Zlaforge
<ul></ul><p>On Tue, Aug 09, 2022 at 05:44:25PM +0000, pespin wrote:</p>
<blockquote>
<p>Right now "Option B" or "Option C" seem the acceptable ways to me.</p>
</blockquote>
<p>I agree, both look fine to me, too.</p>