Model Overview
BBS use case aims at using ONAP for the design, creation and activation of the High Speed Internet Access CFS.
Model Design
Representation in SDC
Resource Representations
Modeled Resource | SDC Representation | A&AI object | TOSCA file |
---|---|---|---|
ONT NNI | Connection Point | cp | ontNni.yaml & ontNni.json (for import) |
PON UNI | Connection Point | cp | ponUni.yaml & ponUni.json (for import) |
OLT NNI | Connection Point | cp | oltNni.yaml & oltNni.json (for import) |
ODN Connection | VNF Virtual Link | N/A | |
Access Connectivity | Virtual Function Component | generic-vnf | accessConnectivity.yaml |
Internet Profile | Virtual Function Component | generic-vnf | internetProfile.yaml |
CPE (PNF) | Virtual Function Component | pnf | cpePnf.yaml |
Composition of services
Service | Composed Of |
---|---|
HSIA CFS (BBS E2E Service) | CPE VF* ONT-NNI CP ODN Connection Vnf Virtual Link PON-UNI CP Access Connectivity VF OLT-NNI CP Internet Profile VF (*) with workaround to model PNF in SDC |
Representation in A&AI
Model Parameter Life-cycle
Table on information model 'storage' and discovery-inventory analysis for BBS use case parameters
BBS Parameter Table
ONAP Awareness | SDNC (Access Discovery) | SDN-C (Edge Discovery) | SDC (Service Creation from Portal) | DCAE Registration PNF | SDN-C (Access Service) | DCAE CPE Auth | A&AI |
---|---|---|---|---|---|---|---|
Service (HSIA) | |||||||
RG MAC Add | Input | Input | |||||
Service Type | Input | Input | |||||
Upstream Speed | Input | Input | |||||
Downstream Speed | Input | Input | |||||
Remote ID | Input (Optional) | Input | Input (used to find the CFS associated with PNF) | Input | |||
Orch Status | Derived - Obtained from CFS associated with PNF in PNF Registration | Derived - Obtained from CFS associated w PNF and MAC Address | Input | ||||
HSIA Access | |||||||
CPE/ONT PNF | |||||||
PNF Name | Input (CorrelationID) | SourceName | SourceName | Input | |||
MAC Address | Input | Input | Input | ||||
Manufacturer | Onboarded CSAR Artifact | Input | Input | ||||
Serial Number | Input |
| Input | ||||
Model | Input | Input | |||||
Type | Onboarded CSAR Artifact | Input | Input | ||||
SW Version | Input (Optional) | Input (Optional) | Input | ||||
Attachment Point (new field) | Input | Input | |||||
CPE Authentication State | Input (Used to derive the CFS orchestration status) | ||||||
ONT NNI (PORT) | Input from response when access connectivity is created | Input | |||||
ODN Virtual Link | Input from response when access connectivity is created | Input | |||||
Access Connectivity | |||||||
Service Type | Input (from CFS) | ||||||
Upstream Speed | Input (from CFS) | ||||||
Downstream Speed | Input (from CFS) | ||||||
PON UNI | |||||||
CVLAN | Input (Optional) | Input | Input when access connectivity is created or CFS if not in DCAE Reg | Input | |||
Expected ONT ID | Input (Optional) | Input (from CFS) | Input | ||||
OLT Name | Input | Derived (Attachment Point) | Input | ||||
OLT PON Slot | Input | Derived (Attachment Point) | Input | ||||
OLT PON Port | Input | Derived (Attachment Point) | Input | ||||
OLT NNI | |||||||
SVLAN | Input | Input (Optional) | Input | Input when access connectivity is created or CFS if not in DCAE Reg | Input | ||
OLT Name | Input | Input | |||||
OLT NNI Slot | Input | Input | |||||
OLT NNI Port | Input | Input |
Service-instance-related information
BBS Properties Per HSIA CFS Service Instance | Input Source | ONAP Components that must fetch the value from A&AI | Does it really need A&AI storage? | A&AI Metaname (for Metadata) |
---|---|---|---|---|
RG MAC Address | Service Order via Ext API It also comes in the CPE Authentication Event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF CPE authentication event in order to deduce if there is any mismatch) | Yes, as metadata of CFS service instance | rgw-mac-address |
Correlation ID (PNF-name) | Service Order via Ext API It also comes in the sourceName of the PNF registration event's commonEventHeader | Yes, as property of PNF object | ||
Service Type | Service Order via Ext API | SO / bbs-apex-policy (during Access Connectivity and Internet Profile VFCs creation & update) | Yes, as metadata of CFS service instance | service-type |
Access ID | PNF registration event | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | remote-id |
Upstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | up-speed |
Downstream Speed | Service Order via Ext API | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | down-speed |
OLT Name | PNF registration event (extracted from attachment point) | |||
OLT PON port | PNF registration event (extracted from attachment point) | |||
OLT PON slot | PNF registration event (extracted from attachment point) | |||
CVLAN | PNF registration event Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | cvlan |
SVLAN | PNF registration event Service Order via Ext API [optional - if not provided by Access SDN M&C] | SDN-C or SO? / bbs-apex-policy (during Internet Profile VFC creation & update) | Yes, as metadata of CFS service instance | svlan |
Expected ONT ID | Service Order via Ext API [optional] | SDN-C or SO? (for Access Connectivity VFC creation) | Yes, as metadata of CFS service instance | expected-ont-id |
CPE Manufacturer | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Model | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Equipment Type | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE Serial Number | PNF registration event | Yes, as property of PNF object | Not Applicable | |
CPE SW Version | PNF registration event (also present in CPE Authentication Event) | Yes, as property of PNF object | Not Applicable | |
Attachment Point (Not a real BBS modeling property, since its constituent parts are captured in other model properties) | PNF registration event | bbs-event-processor DCAE microservice (it fetches existing value from A&AI to compare it with the new value coming from PNF re-registration event in order to deduce if it is a true relocation) | Yes, as value of link-name property of a logical-link bridged to the PNF object | Not Applicable |
ONT NNI Port | CPE PNF onboarding in SDC | |||
OLT NNI Slot | PNF registration event | |||
OLT NNI Port | PNF registration event |
28 Comments
Stavros Kanarakis
This is a first conceptual proposal on how we could model the use case. It is a high level decomposition of the RFS services/resources based on the initial Wiki modeling depiction. It does not contain any specific domain models per RFS yet.
ASSUMPTIONS
NOTES
The steps mentioned below are not meant to be a flow diagram representation. It is just an enumeration of generic steps and how they relate with the RFS services/resources depicted in the diagram.
HSIA activation sub-use case (incorporating Topology Discovery) based on proposed modeling
David Perez Caparros
This is good. Just a couple of comments:
- Does the concept of allotted resource apply here? See Allotted Resource Model.
"Allotted Resources are portions of one service which can be allotted to be used as resources by another."
Perhaps, the option of connecting ONTF RFS with Access Conn. RFS fits better, let's discuss it.
- How could we add here the option where the traffic shaping (speed profile) is enforced by the Access Conn RFS? e.g. SEBA case
Stavros Kanarakis
Hi David,
I know that Allotted Resource Model is best suited for a shared service concept. I used it because many ONT RFS instances could re-use the same Access Conn. RFS in case they land on the same PON port of that specific OLT (one Access Conn. RFS is bound to a specific PON port having been discovered by topology discovery).
I have seen allotted resource model usage in the CCVPN but in their case I admit it is a better fit. That is why I have made a comment about allotted resources in step 8 of my list above.
If there is any conceptually better alternative, I will be more than happy to discuss it of course.
For your second question, could you please elaborate a bit more? I am not familiar with the SEBA case.
Stavros Kanarakis
I have edited the proposal to remove the Allotted Resource concept between the ONT RFS and the Access Connectivity RFS. David is right, the concept is towards 1-1 mapping between the two RFSs instead of a shared service.
David Perez Caparros
As of today, we (Swisscom) do subscriber traffic shaping in the BNG and not in the OLT/Central Office. With proposals like SEBA (SDN Enabled Broadband Access), traffic shaping seems to be done directly in the Access POD (Central Office), before the metro link. If you look at the OSAM use case, which is using SEBA, subscriber speed profiles are configured in the Access POD (Models for OSAM) and (Flows for OSAM#4-SubscriberRegistrationFlow). SEBA exposes speed profile management (https://drive.google.com/drive/folders/1DTU68lFim6sIQ7Rpd3PPTY0gfWdeD9oO). The Access POD/SEBA is seen as a big OLT by OSS/BSS (at least in AT&T case: https://docs.google.com/document/d/1nou2c8AsRzhaDJmA_eYvFgd0Y33KiCsioveU77AOVCI/edit).
Keong Lim
Hi David Perez Caparros,
Why are the SEBA files hosted on google docs and google drive rather than on the ONAP wiki?
There was a similar issue at the VF2F ONAP Project Developers Event, Dec 10 - 12, 2018, (Virtual Webinars) using the gitlab wiki instead of ONAP wiki (see chat log Dec 12 from 07:05:24) Gildas Lanilis .
David Perez Caparros
Hi Keong, SEBA is an ONF project (https://www.opennetworking.org/seba/), not related to ONAP. OSAM is an ONAP use case using SEBA.
Stavros Kanarakis
To my understanding, when SO workflow will request from SDN-C to configure OLT/ONT, at that point, the respective DG that will be executed, can query A&AI to fetch the actual subscription speed value from either the HSIA CFS service instance or the Internet Access RFS instance (in case we instantiate it earlier … something that is not depicted in the steps I have above in the proposal).
So, DG logic has the option of propagating this piece of information towards Access SDN M&C in case traffic shaping is done in Access POD.
Does this answer your second question?
Weitao Gao
I tried to classify the BBS related modeling by using SDC/TOSCA language:
PNF
Attributes
ONT(CPE)
String: ONT Serial Number
String: ONT Port
String: version
String: EquipmentID (type)
OLT
String: OLT Name
String: OLT Slot
String: OLT Port
(v)BNG
No Specific Requirements
2. Modeled as External Connection Point
ExtCP
Attributes
Remark
ONT NNI
No Specific Attributes
PON UNI
String: Service Type
String: Upstream Bandwidth
String: Downstream Bandwidth
String: CVLAN-ID
String: A-OLT Name
String: OLT-Port
String: OLT-SLOT
String: ONT Serial No.
String: ONT-Port
OLT NNI
String: SVLAN-ID
String: A-OLT Name
String: OLT-Port
String: OLT-SLOT
BNG UNI
String: SVLAN-ID
Maybe the BNG Uni could reuse thesegmentIdas the SVLAN-ID insideVirtualLink?
BNG NNI
String: IPAddress
Ipaddress also could reuse thestartIpandendIpas theIpaddress
VTEP
?
3. Modeled As Virtual Link
Link
Attributes
Access Link
String: OTO ID
String: OMDF connector
String: Splitting ratio
Metro Link
?
Tim Carey
For the TOSCA definition:
Use of olt in names - there are actually different types of ANs (e.g., DSLAM, OLT) - so maybe we need a generic Access RFS and then a specialized AccessOLT RFS with the PON parameters (e.g. Fiber).
We could then name the common elements an_name, an_uni_xxx, an_nni_xxx. Also you probably need a an_nni_slot unless the UNI/NNI naming conventions will include shelf/slot/port - if you don't need the an_uni_slot attribute.
Tim Carey
In the TOSCA definitions - I thought we descoped the transport elements from this use case for Dublin? If so do we need the TOSCA definitions?
Weitao Gao
Agree, the Transport part is pre-instantiated and no Usecase involve this part currently.
Stavros Kanarakis
I agree that is is descoped but what is not clear to me is how we are going to select any pre-defined static links if not modeled somehow in our final modeling. We can discuss it further.
Weitao Gao
Stavros Kanarakis , Seems like your modeling proposal based on the Target Internal DM Reference. As far as I know, this DM will not be implemented in Dublin Release. Thinh Nguyenphu Xu Yang user-7acabPlease correct me if I'm wrong.
Weitao Gao
Agreement from Stavros and Victor:
BNG UNI/NNI will be modeled as VNF CP?
Stavros Kanarakis
Changed the conceptual diagram to reflect what we agreed with Victor
michail salichos
Just a clarification, we are not planning to support separate VNF's for BNG, AAA and DHCP servers at the Edge, there will be a single Ubuntu-based VM running these services and ONAP will be "seeing" the Edge as an external SDN controller. Also, to reflect on the aforementioned Edge design, the conceptual diagrams in this wiki page depict an internal network between AAA, BNG and DHCP, which will not be the case
Tim Carey
Michail,
Ok that works as well - we weren't sure of the Infrastructure edge - What would you like to call the single VNF that combines the BNG, AAA and DHCP servers?
michail salichos
No preference, how about "Edge VNF"?
David Perez Caparros
just BNG VNF, Edge VNF may be too abstract
Stavros Kanarakis
Ok, we will remove all VNFs in the Edge leaving only a BNG VNF.
Need to decide if we need any properties/attributes for the resources below
At least BNG UNI is needed as a CP in order to connect with the OLT NNI via a Transport Connection virtual link. I want to clarify if we also need BNG NNI somehow in our model to hold something actually useful for us in the use case.
Also, having it as a CP, requires a virtual link somewhere that we can link to. This virtual link could represent the internet in the conceptual diagram but I think it does not buy us anything for our use case.
What do you think?
David Perez Caparros
I agree. Let's use BNG VNF and BNG UNI CP. At least for Dublin, we don't need to model the BNG NNI CP.
Stavros Kanarakis
David,
I have removed all clutter in the conceptual diagram.
Can you please comment if you think we might need any new properties/attributes for BNG (both VNF and internal CP)?
David Perez Caparros
Hi Stavros,
BNG:
- name
BNG UNI CP:
- UNI slot
- UNI port
- S-VLAN
I don't foresee additional properties at the moment.
user-2586f
I have a question about PON-UNI : why does Fiber-ID appear here? we can create service without Fiber-ID.
Assuming it must be needed,how can we get it?
Stavros Kanarakis
Fiber-ID is still in question. It has not yet been finalized. Please note that this attribute is assignable, it does not need to exist as an input for the service. Rather, it will be attached to the resource instance at run-time.
David Perez Caparros
- Fiber-ID should be part of the ODN vLink, but for Dublin we are not adding extra properties to vLinks. I think we can safely remove it from PON UNI CP
- What is the reasoning for keeping 'OLT name' in both PON UNI CP and PON NNI CP?
- we should keep Internet Profile RFS outside HSIA Access RFS, as it can be applied to both Access or HSIA Edge RGS, correct? can we avoid having service type, upSpeed, downSpeed properties in both Access Device RFS and Internet Profile RFS?
We need to review and finalize the model during this week's call.
Stavros Kanarakis
Fiber-ID has been removed for Dublin.
'OLT Name' exists in both CPs because it will help us identify the proper topology object in AAI (topology discovery will have the terminal-points under a node). We can discuss it further if we have a different view on this.
We can also further discuss the Internet Profile RFS positioning and relevant properties in our meeting, I agree.