Change in libosmocore[master]: Gb: add a second NS implementation

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/gerrit-log@lists.osmocom.org/.

laforge gerrit-no-reply at lists.osmocom.org
Fri Sep 4 07:49:03 UTC 2020


laforge has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmocore/+/19417 )

Change subject: Gb: add a second NS implementation
......................................................................


Patch Set 22:

(5 comments)

https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h 
File include/osmocom/gprs/gprs_ns2.h:

https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h@25 
PS22, Line 25: enum gprs_ns2_signal_ns {
             : 	S_NSVC_RESET, /* when a NSVC is in reset */
             : 	S_NSVC_BLOCK, /* when a NSVC become blocked */
             : 	S_NSVC_UNBLOCK, /* when a NSVC become unblocked */
             : 	S_NSVC_ALIVE_EXP, /* Tns-alive expired more than N times */
             : 	S_NSVC_REPLACED, /* nsvc object is replaced (sets old_nsvc) */
             : 	S_NSVC_MISMATCH, /* got an unexpected IE (sets msg, pdu_type, ie_type) */
             : 	S_NSVC_DELETED, /* when a NSVC gets deleted */
             : 	S_SNS_CONFIGURED, /* IP-SNS configuration completed */
             : 	S_NSE_AVAILABLE, /* NSE is available */
             : 	S_NSE_UNAVAILABLE, /* NSE is unavailable */
             : };
             : 
             : struct gprs_ns2_signal_data {
             : 	struct gprs_ns2_nse *nse;
             : 	uint16_t nsei;
             : 	struct gprs_ns2_vc *nsvc;
             : 	struct gprs_ns2_vc *old_nsvc;
             : 	uint8_t cause;
             : 	uint8_t pdu_type;
             : 	uint8_t ie_type;
             : 	struct msgb *msg;
             : };
             : 
             : enum gprs_ns2_vc_mode {
             : 	NS2_VC_MODE_ALIVE, /* The VC will use RESET/BLOCK/UNBLOCK to start the connection and do ALIVE/ACK */
             : 	NS2_VC_MODE_BLOCKRESET, /* The will only use ALIVE/ACK no initiation */
             : };
             : 
             : /*! Osmoco NS events */
             : enum gprs_ns2_evt {
             : 	GPRS_NS_EVT_UNIT_DATA,
             : };
             : 
             : /* callbacks for messages transfer */
             : /*! Osmocom GPRS callback function type */
             : typedef int gprs_ns2_cb_t(enum gprs_ns2_evt event, struct msgb *msg,
             : 			  uint16_t nsei, uint16_t bvci);
I know this patch has been very long in the pipeline already.  I would think if we modernize the NS implementation, we should switch from those old signals to moving towards primitives.  Look at the SCCP USER SAP or the LAPDm code.  Section 5 of TS 48.016 describes the abstract primitives, we would "just" have to give thme a concrete encoding.  Plus add some for the various notifications we do with signals now.

Not a strict requirement, but an idea at least.


https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h@65 
PS22, Line 65: gprs_ns2_cb_t
this would then be a call-back that receives msgb-wrapped osmo_prim from NS to the NS-user


https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h@71 
PS22, Line 71: int gprs_ns2_send(struct gprs_ns2_inst *inst,struct msgb *msg);
             : int gprs_ns2_send_nse(struct gprs_ns2_nse *nse, struct msgb *msg);
             : int gprs_ns2_send_nsei(struct gprs_ns2_inst *nsi, uint16_t nsei, struct msgb *msg);
             : int gprs_ns2_recv_vc(struct gprs_ns2_inst *nsi,
             : 		     struct gprs_ns2_vc *nsvc,
             : 		     struct msgb *msg);
and those would basically be convenience wrapper functions which generate a msgb-wrapped osmo_prim sent down from the user into the NS


https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h@86 
PS22, Line 86: int gprs_ns2_tx_block(struct gprs_ns2_vc *nsvc, uint8_t cause);
             : int gprs_ns2_tx_block_ack(struct gprs_ns2_vc *nsvc);
             : 
             : int gprs_ns2_tx_reset(struct gprs_ns2_vc *nsvc, uint8_t cause);
             : int gprs_ns2_tx_reset_ack(struct gprs_ns2_vc *nsvc);
             : 
             : int gprs_ns2_tx_unblock(struct gprs_ns2_vc *nsvc);
             : int gprs_ns2_tx_unblock_ack(struct gprs_ns2_vc *nsvc);
             : 
             : int gprs_ns2_tx_alive(struct gprs_ns2_vc *nsvc);
             : int gprs_ns2_tx_alive_ack(struct gprs_ns2_vc *nsvc);
I think those low-level functions may not actually need to be exposed.  User applications should trigger procedurs (like start an UNBLOCK procedure), but a proper NS implementation then should by itself take care of whateve else ise required (like waiting for the ACK, re-transmitting [if specified], have a timer, notify the user of failure/success)


https://gerrit.osmocom.org/c/libosmocore/+/19417/22/include/osmocom/gprs/gprs_ns2.h@104 
PS22, Line 104: nt gprs_ns2_tx_sns_ack(struct gprs_ns2_vc *nsvc, uint8_t trans_id, uint8_t *cause,
              : 			const struct gprs_ns_ie_ip4_elem *ip4_elems,
              : 			unsigned int num_ip4_elems,
              : 			const struct gprs_ns_ie_ip6_elem *ip6_elems,
              : 			unsigned int num_ip6_elems);
              : int gprs_ns2_tx_sns_config(struct gprs_ns2_vc *nsvc, bool end_flag,
              : 			   const struct gprs_ns_ie_ip4_elem *ip4_elems,
              : 			   unsigned int num_ip4_elems,
              : 			   const struct gprs_ns_ie_ip6_elem *ip6_elems,
              : 			   unsigned int num_ip6_elems);
              : int gprs_ns2_tx_sns_config_ack(struct gprs_ns2_vc *nsvc, uint8_t *cause);
              : int gprs_ns2_tx_sns_size(struct gprs_ns2_vc *nsvc, bool reset_flag, uint16_t max_nr_nsvc,
              : 			 int ip4_ep_nr, int ip6_ep_nr);
              : int gprs_ns2_tx_sns_size_ack(struct gprs_ns2_vc *nsvc, uint8_t *cause);
likewise all of those above. Those should be internal low-level functions inside the NS stack.  The stack should (depending on its configuration) handle inbound SNS or trigger outbound SNS.  The user should provide configuration and get notifications about successfull/failed SNS procedures.



-- 
To view, visit https://gerrit.osmocom.org/c/libosmocore/+/19417
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: libosmocore
Gerrit-Branch: master
Gerrit-Change-Id: I3525beef205588dfab9d3880a34115f1a2676e48
Gerrit-Change-Number: 19417
Gerrit-PatchSet: 22
Gerrit-Owner: lynxis lazus <lynxis at fe80.eu>
Gerrit-Assignee: daniel <daniel at totalueberwachung.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: daniel <dwillmann at sysmocom.de>
Gerrit-Reviewer: lynxis lazus <lynxis at fe80.eu>
Gerrit-CC: daniel <daniel at totalueberwachung.de>
Gerrit-CC: laforge <laforge at osmocom.org>
Gerrit-CC: pespin <pespin at sysmocom.de>
Gerrit-Comment-Date: Fri, 04 Sep 2020 07:49:03 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20200904/d22a0682/attachment.htm>


More information about the gerrit-log mailing list