diff options
author | Xin Miao <xin.miao@us.fujitsu.com> | 2020-03-05 19:54:39 +0000 |
---|---|---|
committer | Morgan Richomme <morgan.richomme@orange.com> | 2020-03-10 13:56:06 +0000 |
commit | 57a161d8f533d30a1d27cf72856fe8274aea7aca (patch) | |
tree | 9be45171064c421ec67993afb62088548a6fba37 /docs | |
parent | 99b8b9ef5eec91d511cd31d548f2e1174f70a069 (diff) |
Add MDONS sections
Issue-ID: INT-1474
Signed-off-by: Xin Miao <xin.miao@us.fujitsu.com>
Change-Id: I57483601ac9962c486657c7c0941cfe7faf3a222
Diffstat (limited to 'docs')
-rw-r--r-- | docs/docs_CCVPN.rst | 34 |
1 files changed, 33 insertions, 1 deletions
diff --git a/docs/docs_CCVPN.rst b/docs/docs_CCVPN.rst index 556e54a47..9eb8830d5 100644 --- a/docs/docs_CCVPN.rst +++ b/docs/docs_CCVPN.rst @@ -52,6 +52,38 @@ https://wiki.onap.org/display/DW/E-LINE+over+OTN+Inter+Domain+Test+Cases Test status can be found here: https://wiki.onap.org/display/DW/2%3A+Frankfurt+Release+Integration+Testing+Status +MDONS (Multi-Domain Optical Network Services) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Overall Description +~~~~~~~~~~~~~~~~~~~ +The MDONS use-case aims to automate the design, activation & operations resulting from an optical transport (L0/L1) service request exchange between service providers and/or independent operational entities within a service provider network by delivering E2E optical orchestration capabilities into ONAP. MDONS extends upon the CCVPN use-case by incorporating support for L0/L1 network management capabilities leveraging open standards & common data models defined by OpenROADM, Transport-API & MEF. + +Frankfurt Scope and Impacted modules +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +MDONS implementation for the Frankfurt release will incorporate the following: +- Design & modelling of optical services based on MEF L1 subscriber & operator properties +- E2E optical service workflow definitions for service instantiation & deletion +- UI portal with L1 service instantiation templates +- Optical Transport domain management (topology, resource onboarding) through standard models / APIs - OpenROADM, T-API +Impacted ONAP modules include: A&AI, SDC, SDN-C, SO, UUI + +OpenROADM reference: https://github.com/OpenROADM/OpenROADM_MSA_Public +ONF Transport-API (TAPI): https://github.com/OpenNetworkingFoundation/TAPI +MEF: https://wiki.mef.net/display/CESG/MEF+63+-+Subscriber+Layer+1+Service+Attributes + +Functional/Integration Test Cases +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +For integration test case and description, refer to this following wiki-page: +https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case + +Installation Procedure +~~~~~~~~~~~~~~~~~~~~~~ +The integration test environment is established to have ONAP instance with Frankfurt release interfacing to 3rd party transport domain controllers. One controller instance manages OpenROADM OTN topology and the other 2 instances manage TAPI OTN topology. L0 infrastructure and WDM services are pre-provisioned to support L1 topology discovery and OTN service orchestration from ONAP. + +Testing Procedure +~~~~~~~~~~~~~~~~~ +Test environment is described in Installation Procedure section and test procedure is described in https://wiki.onap.org/display/DW/MDONS+Integration+Test+Case. + Update for Dublin release ~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -205,4 +237,4 @@ d. Followed the steps provided in this link(https://wiki.onap.org/display/DW/ONA As per wiki (Policy on OOM), push-policied.sh script is used to install policies. but I observed that CCVPN policy is not added in this script. So merged CCVPN policy using POLICY-1356 JIRA ticket. but policy is pushed by using push-policy_casablanca.sh script during integration test. It is found that the changes made were overwritten and hence had to patch the DG manually. This will be tracked by the JIRA SDNC-540. -all above manual steps can be found https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing
\ No newline at end of file +all above manual steps can be found https://wiki.onap.org/display/DW/Manual+steps+for+CCVPN+Integration+Testing |