OLT app subscriber provisioning API

[Jonathan Hart]

Hi everyone,

I want to propose some changes to the OLT app API to change how we are provisioning the s-tags for subscribers.

Currently s-tags are configured for OLTs in ONOS, and you can only configure one s-tag per OLT. This works when you are only using one PON port, but when using multiple PON ports we need at least one s-tag per PON port. 

ONOS doesn't see the PON ports or understand which UNIs map to which OLT PON ports, so I don't think it makes sense to configure this information in ONOS. Instead, this should be provisioned when the subscriber VLANs are provisioned in ONOS, so instead of passing just UNI port and c-tag, we would extend the API to pass UNI port, c-tag and s-tag when we provision the subscriber.

I've submitted the proposed API changes to Gerrit here - let me know if you have any feedback on this.

Thanks,

Jono

[GASSER, MICHAEL D]

In fact to support a 64 way ONT split 2 s-tags per port are used.

 

Mike Gasser

--
You received this message because you are subscribed to the Google Groups "SEBA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seba-dev+u...@opennetworking.org.
To post to this group, send email to seba...@opennetworking.org.
Visit this group at https://groups.google.com/a/opennetworking.org/group/seba-dev/.
To view this discussion on the web visit https://groups.google.com/a/opennetworking.org/d/msgid/seba-dev/CAA1CJdd8WPWd8_EsA_FjRjTxGZwFRLPnfvp_w%2BNS_rquJudW0g%40mail.gmail.com.
For more options, visit https://groups.google.com/a/opennetworking.org/d/optout.

[Amit Ghosh]

Hi Jono,

I think there should be the flexibility of having the S-tag different even for each subscriber. Some of the operators are using it that way. 

I had submitted a patch (https://jira.opencord.org/browse/VOL-540) quite sometime back for having this flexibility over the oltApp REST interface (this patch has not yet been merged), maybe we could leverage this.

Thanks,

Amit Ghosh

[David Bainbridge]

I am a bit confused. The tags can be queried via SADIS (https://github.com/opencord/sadis). How does this relate?

--
You received this message because you are subscribed to the Google Groups "VOLTHA Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to voltha-discus...@opencord.org.
To post to this group, send email to voltha-...@opencord.org.
Visit this group at https://groups.google.com/a/opencord.org/group/voltha-discuss/.
To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/388580ff-860b-4bec-8a42-9a337f969ddd%40opencord.org.
For more options, visit https://groups.google.com/a/opencord.org/d/optout.

[nicolas.pal...@gmail.com]

Hi,

Jono 's proposal will indeed allow to choose the (s_tag, c_tag) for each subscriber. The problem with using SADIS is that in the current configuration SADIS just contains an s_tag per device, which is not granular enough for what we want to do.

I think as long as Jono's changes are backward compatible (we keep both the API endpoint with c_tag, with S_tag lookup in SADIS and the one with s_tag and c_tag passed in) it is fine.

Thanks,

Nick

[David Bainbridge]

If you look at the readme (https://github.com/opencord/sadis), SADIS contains an S and C tag. Also, SADIS isn't static, it is an integration interface, so even if it didn't have both tags it could be added.

I think there is a philosophical question here about is everything in stored, maintained, and set via API to an ONOS app, or is there another system of record to which ONOS integrations via an integration interface and pulls the information?

To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/e6d7f6a7-a641-42c8-bea2-70348bd9ceb7%40opencord.org.

[Shaun Missett]

Also bear in mind that some Operators support multiple C and S tag Flow combinations per Subscriber/UNI, and the SADIS interface seems like it can be easily expanded to accommodate that model - does the alternate model also support this?

Shaun

You received this message because you are subscribed to the Google Groups "SEBA Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to seba-dev+u...@opennetworking.org.
To post to this group, send email to seba...@opennetworking.org.
Visit this group at https://groups.google.com/a/opennetworking.org/group/seba-dev/.
To view this discussion on the web visit https://groups.google.com/a/opennetworking.org/d/msgid/seba-dev/CAFDTwPQ_6jUTyKmj8OVRPdHUPJerSO3icC7Pu8OMT1LQoRckow%40mail.gmail.com.
For more options, visit https://groups.google.com/a/opennetworking.org/d/optout.

[Jonathan Hart]

The OLT app was never querying the c-tag from SADIS, it was being passed to the OLT app as part of the provisionSubscriber() call. My proposal is basically just to extend this call to take an s-tag as well.

Even if we get the tags from SADIS, the OLT app still needs to be triggered to install the flows for the subscriber. I guess you could make a call to the OLT app to trigger it to install the flows, then it would use SADIS to find the VLAN tags. This seems a bit strange in the case of SEBA because both of these things are coming from the same place (NEM) so why not just pass the tags at the same time as you make the call?

But this doesn't address the point that Shaun and Amit brought up of multiple tag combinations per subscriber (I assume this is for different services?). How do we know which tag combination to use on a given provisioning call? ONU SN + service name? Either of the methods could be extended to support this; neither of them support it today.

Thanks,

Jono

To view this discussion on the web visit https://groups.google.com/a/opennetworking.org/d/msgid/seba-dev/CA%2BYfzeddu9x5zCBoU1COst%2BJq9ws2%3D-uUq6LidXv%3Dg9bch_NaA%40mail.gmail.com.

[David Bainbridge]

NEM can still supply the tags, just via the SADIS integration interface as opposed to pass down in the add subscriber call. This way all data is kept in a single place and the OLT can just query the tags via the integration interface as the other apps are doing.

To view this discussion on the web visit https://groups.google.com/a/opennetworking.org/d/msgid/seba-dev/CAA1CJde9X5xx0xOHU%2BWuFdBw7UiVZmYAvTXcZALgR_Pwiu_3qg%40mail.gmail.com.

[David Bainbridge]

And as a side note, we don't want VOLTHA to be SEBA focused ...

[Matt Jeanneret]

Jono, it is still possible to mimic the existing way with this change correct?  

The old assumption of an S VLAN tag per OLT uplink port is limiting, especially if carriers use different algorithms to generate the S and C pair.   But as long as folks can re-create that setup (in some way), i generally think its a good change.

-matt

To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/CAFDTwPSDMWFBeUiuBkw-T9_kNBjWVKbiECtuVq%2BK50UHfV%2BFeA%40mail.gmail.com.

[Jonathan Hart]

Just to close the loop on this, this was solved in a different way by Amit's patch. This patch pulls the c and s tags from SADIS.

Thanks,

Jono

[Shaun Missett]

Sounds good Jono - we would also need to support the ability to add a Tech Profile Flow ID, Upstream BWP Name and Downstream BWP name in the Future.

The current subscriber record also has assumptions around the match action rules applied at the UNI we may need to be able to specify these explicity when 

we support multiple Flows per UNI - each with their own Technology Profile, BWPs etc. 

Shaun

--

You received this message because you are subscribed to the Google Groups "VOLTHA Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to voltha-discus...@opencord.org.
To post to this group, send email to voltha-...@opencord.org.
Visit this group at https://groups.google.com/a/opencord.org/group/voltha-discuss/.

To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/CAA1CJdd8WPWd8_EsA_FjRjTxGZwFRLPnfvp_w%2BNS_rquJudW0g%40mail.gmail.com.

[Jonathan Hart]

Yes agreed, none of these things have been addressed yet but they do need to be.