aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorXin Miao <xin.miao@us.fujitsu.com>2020-03-05 19:54:39 +0000
committerMorgan Richomme <morgan.richomme@orange.com>2020-03-10 13:56:06 +0000
commit57a161d8f533d30a1d27cf72856fe8274aea7aca (patch)
tree9be45171064c421ec67993afb62088548a6fba37
parent99b8b9ef5eec91d511cd31d548f2e1174f70a069 (diff)
Add MDONS sections
Issue-ID: INT-1474 Signed-off-by: Xin Miao <xin.miao@us.fujitsu.com> Change-Id: I57483601ac9962c486657c7c0941cfe7faf3a222
-rw-r--r--docs/docs_CCVPN.rst34
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