Skip to end of metadata
Go to start of metadata




Guidelines for WT-412 work.

Test-cases should not refer to a given AppNote instantiation.  The portfolio of test-cases should not have to map one to one with a certain AppNote.  This will allow re-useability of Test-cases across AppNotes.

AppNotes need to be instantiated for OBLabs so they can test them.  The instantiation is therefor a means to, but not an endorsement from BBF as to why certain products were used in the instantiation.  The instantiation is a something the AppNote User/Author and OBLabs agree to amongst themselves.

The detailed outcome of the tested AppNote Instance shouldn’t be publically posted, they are only shared between the AppNote User and OBLabs.  WT-412 should document :

  • Test Case

  • Global result of the test (interactions pass/fail without mentioning instance specific details)

  • input to WT-411/413 as it relates to what Interface ‘type’ was used (and potentially what ‘version’)

  • input to Open Source community as it relates to gaps in functionality wrt the interfaces (BBF work, process needs to be defined and depends on OS community)

  • input to standards committee as it relates to gaps in functionality wrt the interfaces (BBF work through liaisons, etc)




Overview

This is the project page for the WT-412 Test Cases for Cloud CO Applications project. The eventual goal of the project is to development a document external to the Wiki to detail the test cases and reporting requirements.  This page / space serves as a collaboration point for contributors and Cloud CO participants.  

JIRA Contributions

The following open JIRA contributions / issues exist for this project.

Key Summary Updated Reporter Status
Loading...
Refresh

Discussion Points

Proposed Table of Contents

Here is the proposed table of contents for the for the document.  This is being done here on the Wiki to allow collaboration / commenting.

  1. Executive summary
  2. Scope
    1. Purpose
  3. References and Terminology
  4. Test Environment and Setup
  5. Reporting Requirements
  6. Functional Test Cases


1 Executive Summary

TR-384 defines the reference architectural infrastructure of the Cloud CO, whose functionality can be access via its Northbound API, allowing the service providers to consume the functionality and build their own services. This infrastructure is fundamentally different in many ways from legacy broadband networks.

To instruct readers how to consume a Cloud CO “service”, BBF is developing the Application Notes to describe the implementable use cases by using Cloud CO functionality (https://wiki.broadband-forum.org/display/BBF/Application+Notes).  

This document provides a set of test cases to verify the Application Notes, and thus validate Cloud CO functionality.

2 Proposed Purpose and Scope

2.1 Purpose

The purpose of this Working Text is to provide a set of test cases to validate Cloud CO functionality defined in TR-384 and uses of that functionality as documented in the various Cloud CO applications notes (App Notes). The Cloud CO functionality incorporates multiple Cloud CO components, their behaviors and interactions.

Application Notes, describing the implementable use cases for Cloud CO 'services', will provide inputs for the test cases to validate these Cloud CO 'services'. However, the portfolio of test-cases should not have to map one to one with a certain AppNote.  This will allow re-usability of test-cases across App Notes. For more information about the relationship between Application Notes and Test Cases, please refer to the following wiki link: https://wiki.broadband-forum.org/display/BBF/Application+Notes+and+how+they+relate+to+other+work.

These test cases will be consumed by the Open Broadband Labs (OBLabs) when they get approval. The OBLabs will provide the test beds, test results and corresponding test reports to AppNote users. The detailed outcome of the tested AppNote Instance shouldn’t be publicly posted, they are only shared between the AppNote users and OBLab producing those results. 

In summary, WT-412 provides:

  • Detailed Test Cases (Purpose, Procedures, Metrics, etc.) applicable to one or more app notes.
  • Guidelines on reporting test outcomes, including requirements on documentation of the application note instance (hardware and software specifics)
  • Guidelines on providing feedback from testing to the Broadband Forum projects relating to Cloud CO
  • Guidelines on providing feedback from testing to the Open Source Community

2.2 Scope

The test cases focus on the verifying the functionality of the implementation Application Nodes, but do not include the sort of tests more commonly associated with commercial communication infrastructure, such as performance, resilience, scalability and etc. The OBLabs will provide adequate resources for the execution of these tests and might offer additional resources to testing beyond the scope of this test plan.  

3 References and Terminology

3.1. Conventions

In this Working Text, several words are used to signify the requirements of the specification. These words are always capitalized. More information can be found be in RFC 2119 [5].

MUST

This word, or the term "REQUIRED", means that the definition is an absolute requirement of the specification.

MUST NOT

This phrase means that the definition is an absolute prohibition of the specification.

SHOULD

This word, or the term "RECOMMENDED", means that there could exist valid reasons in particular circumstances to ignore this item, but the full implications need to be understood and carefully weighed before choosing a different course.

SHOULD NOT

This phrase, or the phrase "NOT RECOMMENDED" means that there could exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications need to be understood and the case carefully weighed before implementing any behavior described with this label.

MAY

This word, or the term "OPTIONAL", means that this item is one of an allowed set of alternatives. An implementation that does not include this option MUST be prepared to inter-operate with another implementation that does include the option.

3.2. References

The following references are of relevance to this Working Text. At the time of publication, the editions indicated were valid. All references are subject to revision; users of this Working Text are therefore encouraged to investigate the possibility of applying the most recent edition of the references listed below.

A list of currently valid Broadband Forum Technical Reports is published at www.broadband-forum.org.

Document

Title

Source

Year

TR-384

Cloud Central Office Reference Architectural Framework

BBF

2017

3.3. Definitions

The following terminology is used throughout this Working Text.

Application Node

An AppNote is using the TR-384 framework to describe an implementable Use Case for a CloudCO 'application'.  



3.4. Abbreviations

This Working Text uses the following abbreviations:

CCO

Cloud CO

WA

Work Area

WT

Working Text

4. Test Environment and Setup

In the context of Cloud CO, the test environment basically consists of an NFVI, a set of Access I/O and a set of Network I/O. The NFVI is sized according to need, and includes compute and storage (not shown) nodes, as well as a leaf-spine fabric. In addition, the test environment contains the test devices to enable controlling the test execution and collecting the test measurements, and other assistant devices, like LCD to present the test results. 

In traditional test environment, the physical test device established session with device under test (DUT) and exchanges traffic to assess the network functions and their performance. However, some network functions under test in Cloud CO environment are instantiated and executed as VNFs that are deployed on the general-purpose resources. To validate the VNFs, the test devices used in Cloud CO test cases will not only include the traditional hardware-based tools, but also include the virtual tools running as software to execute the same testing work. 

The following figure indicates a generic testing architecture providing an abstract framework within which any specific test cases can fit it. The generic testing architecture helps to provide a structure for the test cases later. In a specific test case, it may be required to define several specific functions under test to execute the whole testing and achieve the ‘service’ in the Application Node.

5. Reporting Requirements and Guidelines

TBD

6. Functional Test Cases

6.1 General

This section outlines a series of test cases to demonstrate the “services” depicted in the Application Nodes. There are no test cases for the suspending or rejecting Application Nodes, and ensure each test case to cover at least one approved Application Node. There are no high-performance test cases either, since validating functionality is the main objective of this document. 

Each test case contains the following contents:

  • Objective: to state the purpose of the test, which Application Node is covered by the test
  • Test architecture: outlines the System Under Test (SUT) and the test tools
  • Prerequisites: a high level description of the state of SUT and pre-configurations
  • Procedures: a description of the procedure to be followed for the test
  • Expected results: a high level description of the behavior should the test succeed
  • Actual results: a description of the actual results of the test, it is Pass or Incomplete.
  • Follow-on activities: a description of the potential input for the WT-411/WT-413, the Open Source communities or other standard committees. 

6.2 Test Case for APPN-000

 

Objective:

This test case aims to validate the service depicted the AppNote-000 (Bootstrapping an NFVI into a Cloud Central Office), in which the NFVI bootstrapping in a Cloud CO domain is described. The more information about APPN-000, please refer to the following link:

https://wiki.broadband-forum.org/display/BBF/CloudCO-APPN-000+-+Bootstrapping+an+NFVI+into+a+Cloud+Central+Office 


Test architecture: 

The test architecture is built in Open Broadband Laboratory Asia, which will provide the test bed and conduct the test procedure.

 


Prerequisites:

  • The COTS and OLT are physically connected with switch fabric.
  • The VIM is installed in the COTS.
  • The OLT is configured with a VLAN and this VLAN is extended to across the switch connected to the OLT.  The VLAN is also extended to the compute hosts that are connected to this switch.

Table 1: The System Under Test (SUT) Hardware and Software versions

SUT

Hardware

Number

Firmware/Software Version

COTS

 

 

 

Switch Fabric

 

 

 

OLT

 

 

 

Table 2: The Test Tools

Vendor

Hardware

Number

Firmware/Software Version

 

 

 

 

Table 3: The VNF Software

Vendor

 

 

Software and Version

Vendor

 

 

 

       TBD: Depending on the environment and resource of the OBLA.

 

Procedure:

  1. VIM creates the overlay networks to interconnect the various elements of CloudCO Domain, such as CCO DO, VIM and SDN Controllers.
  2. VIM deploys the CCO DO and SDN controllers.
  3. CCO DO interconnects VIM and SDN controllers via the overlay networks.
  4. Operator uses CCO NB API to create a Service Provider tenant.
  5. CCO DO creates a Service Provider tenant instances on the SDN Controllers.

 

Expected results:

  1.  The elements of CloudCO Domain are setup.
  2. The connectivity of above elements is setup.
  3. Service Provider tenant is created.

 

Actual results:

TBD

 

Follow-on activities:

6.3 Test Case for APPN-447

 

Objective:

This test case aims to validate the service depicted the AppNote-447 (NERG Service Initialization with Overlay LSL Connectivity with vG_MUX PNF), in which the NERG service is instantiated in a Cloud CO domain. In this test case,  the vG_MUX function is executed as a PNF on a L3 switch rather than a VNF running on the COTS. The corresponding test has been done in Open Broadband Lab Asia in late August.


Test architecture: 

The test architecture is built in Open Broadband Laboratory Asia, which provides the test bed and conducts the test procedures.


Prerequisites:

  • The COTS and OLT are physically connected with switch fabric.
  • The VIM is installed in the COTS.
  • The OLT is configured with a VLAN and this VLAN is extended to across the switch connected to the OLT.  The VLAN is also extended to the compute hosts that are connected to this switch.

Table 1: The System Under Test (SUT) Hardware

SUT

Hardware

Number

COTS

(2288V3)

• CPU:
Intel® Xeon® E5-2699 v3 2.3GHz/18-core; 
• Firmware: 
BIOS/EFI compatible for x86-family blades;
• Disks:
4*600G (or greater capacity)
• Memory:
8*16GB
• NIC:
4*GE +4*10GE(intel 82599)

 4

Switch Fabric

•S5720 (24 Ethernet 10/100/1000 ports,4 Gig SFP,4 10 Gig SFP+,AC 110/220V,front access)

 2

OLT

 • HW MA5800-X7

 1

BRG • Huawei HS8245W1

Table 2: The System Under Test (SUT) Software

SUT

Software

OS 

 • Ubuntu

Orchestrator

•  NetOpen Platform (Huawei)

SDN Controller

• Agile Control (Huawei)

VIM

• Openstack  Mikata

VNFM

• Cloud CSM (Huawei)

vG VNF

• vRG (Huawei)

Distributed Router

• USG6000 (Huawei)


Interaction 1

Procedure:

  1. CCO DO requests VIM to create a Distributed Router across the NFVI through the VIM, associated with a pool of public IP addresses.
  2. CCO DO requests VIM to create a overlay network to connect the uplink of Distributed Router, 
  3. DC SDN M&C sets up a bridge on the switch#2 to connect the overlay network to a pre-created S-VLAN configured on the switch#2 . The switch#2 is a L3 switch and supports VTEP function of the overlay network.
  4. The switch#2 is connected to the video server via above pre-created S-VLAN.
  5. vG_MUX function is supported on the switch#1, it is pre-configured with reachable IP address.
  6. CCO DO requests VIM to create a new overlay network inside the NFVI and connect this overlay network between the vG_MUX and the Edge SDN M&C. The vG_MUX is managed by the Edge SDN M&C via this overlay network.

 Expected results:

  1. Distributed Router is created. 
  2. Routed User Plane Connectivity is created, from the Distributed Router  to switch#2 to the video server.
  3. vG_MUX function is set up on the switch#1 with reachable IP address.

 Actual results:

  1. Distributed Router is created with IP pool 117.117.10.0/24.
  2. Routed User Plane Connectivity is created, from the Distributed Router to switch#2 (117.117.100.2) to the video server (117.117.117.100).
  3. vG_MUX function is set up on the switch#1 with reachable IP address 10.100.100.100.

 

Interaction 2

Procedure:

  1. CCO DO requests VIM to deploy an IPAM VNF inside the CloudCO Domain.
  2. CCO DO requests VIM to establish the connectivity between the Access SDN M&C and the IPAM VNF.
  3. CCO DO requests Access SDN M&C to configure an S-VLAN on the Access PNF, as well as assigning Access UNIs to that S-VLAN.
  4. CCO DO requests DC SDN M&C to configure the S-VLAN on the switch#1 attached to the Access PNF on all of its ports.

 Expected results:

  1. IPAM VNF is created.
  2. Management and control plane is established between the Premise PNF (BRG) and the IPAM VNF.

 Actual results:

  1. IPAM VNF is created.
  2. S-VLAN (4000) is assigned to Access UNI and NNI of the OLT.
  3. Switch#1 is configure with S-VLAN (4000) on its port to OLT.

 

Interaction 3

Procedure:

  1. CCO DO requests the Edge SDN M&C to configure the IPAM VNF with the end user’s addresses.

 Expected results:

  1. IPAM VNF is configured with IP address pool. 

 Actual results:

  1. The IP address pool for the BRG WAN interface is 137.137.11.0, mask is 255.255.255.0.

 

Interaction 4

Procedure:

  1. BRG attaches to the Access Network, the Access PNF relays the DHCP request to the IPAM VNF. 
  2. IPAM VNF responds with the address information, the tunnel information (vG_MUX's address) for the enduser (tenant).
  3. The Access SDN M&C reports a enduser(tenant) activation to the CCO DO with the attachment point.
  4. CCO DO requests VIM to deploy a vG instance and create a new overlay network inside the NFVI and connect this overlay network between the vG and the Edge SDN M&C. The vG is managed by the Edge SDN M&C via this overlay network.
  5. The vG_MUX is configured with the mapping information between the BRG and the vG.
  6. CCO DO requests VIM to create one new overlay network inside the NFIV and connect this overlay network between the WAN facing interface of the vG_MUX and the LAN facing interface of the vG to establish the user-plane connectivity between them.  
  7. CCO DO requests VIM to create another new overlay network inside the NFVI and connect this overlay network between the WAN facing interface of the vG and the Distributed Router to establish the user-plane connectivity between them.

 Expected results:

  1. BRG gets its WAN IP address information and tunnel information
  2. The vG VNF is created.
  3. The user plane connectivity between the BRG, vG_MUX, vG and Distributed Router is established.
  4. The Service User behind the BRG accesses the video service

 Actual results:

  1. WAN IP address of BRG is 137.137.11.252.
  2. vG is created with IP address 172.18.0.10.
  3. vG_MUX is configured with the mapping between BRG and vG.
  4. The laptop behind the BRG successfully accesses the video server (117.117.117.100).

 

Follow-on activities:

  1. Inputs for WT-411: 
    1. Occo-Nf-sdn-pnf:  CCO DO intteracts with Edge SDN M&C to do FCAPS for vG_MUX PNF.
    2. Occo-Nf-sdn-vnf:   CCO DO intteracts with Edge SDN M&C to do FCAPS for vG VNF.


6.4 Test Case for APPN-011

 

Objective:

This test case aims to validate the service depicted the AppNote-011 (Parental Control on NERG), in which the Parental Control Value Added Service is instantiated in a Cloud CO domain. Even if AppnNote-011 can also apply to other similar VASs chained with NERG service, only Parental Control Service is tested in this test case.


The more information about APPN-011, please refer to the following link:

https://wiki.broadband-forum.org/display/BBF/CloudCO-APPN-011+%3A+Parental+Control+on+NERG


Test architecture: 

The test architecture is built in Open Broadband Laboratory Asia, which provides the test bed and conducts the test procedures.


Prerequisites:

  • The Cloud CO Domain instance is already fully bootstrapped. 
  • The NERG service is already successfully instantiated in the Cloud CO Domain.
  • The filtering policies of this service for tenants are executed by a multi-tenant Firewall VNF. This VNF is managed through the Ms refenece point by the Edge SDN M&C . 

Table 1: The System Under Test (SUT) Hardware

SUT

Hardware

Number

COTS

(2288V3)

• CPU:
Intel® Xeon® E5-2699 v3 2.3GHz/18-core; 
• Firmware: 
BIOS/EFI compatible for x86-family blades;
• Disks:
4*600G (or greater capacity)
• Memory:
8*16GB
• NIC:
4*GE +4*10GE(intel 82599)

 4

Switch Fabric

•S5720 (24 Ethernet 10/100/1000 ports,4 Gig SFP,4 10 Gig SFP+,AC 110/220V,front access)

 2

OLT

 • HW MA5800-X7

 1

BRG • Huawei HS8245W1

Table 2: The System Under Test (SUT) Software

SUT

Software

OS 

 • Ubuntu

Orchestrator

•  NetOpen Platform (Huawei)

SDN Controller

• Agile Control (Huawei)

VIM

• Openstack  Mikata

VNFM

• Cloud CSM (Huawei)

vG VNF

• vRG (Huawei)

vFW VNF• vFW (Huawei)

Distributed Router

• USG6000 (Huawei)


Interaction 1

Procedure:

  1. CCO DO receives a Parental Control Service creation request. 
  2. CCO DO requests VIM to deploy and instantiate a multi-tenant Firewall VNF inside the CloudCO Domain. This VNF is managed by the Edge SDN M&C via the Ms reference point.
  3. CCO DO requests VIM to create a virtual network to connect the vG VNF and the Firewall VNF.

 Expected results:

  1. The Firewall VNF is successfully deployed and instantiated in CCO.
  2. The virtual network between vG VNF and Firewall VNF has been setup.
  3. The virtual network between Edge SDN M&C and Firewall VNF has been setup

 Actual results:

  1. vFW is assigned IP address 10.110.110.119. 

  2. The overlay network is setup between vG and vFW.

  3. The overlay network is setup between SDN M&C and vFW.

 

Interaction 2

Procedure:

  1. CCO DO receives a Parental Control Service User creation request with tenant filtering policies.
  2. CCO DO requests the Edge SDN M&C to configure the vG VNF to forward the traffic of the tenant to the vFW, rather than forwarding to the Distributed Router directly.
  3. CCO DO requests the Edge SDN M&C to configure the vFW with the tenant filtering policies.

 Expected results:

  1. vG VNF is configured to forward the traffic of the tenant to Firewall VNF.
  2. Firewall VNF is configured with the filtering policies of the tenant.

 Actual results:

  1. vG is configured to forward the traffic to vFW based on the ACL rules.
  2. vFW is configured with the filtering policy via the overlay network. The management IP address of vFW is 172.16.1.200.


Interaction 3

  1. The service user visits the web site blocked by the tenant filtering policies
  2. The vG VNF forwards the user plane traffic to the vFW via the virtual network between them.
  3. The vFW blocks the traffic based on the filtering rules.

 Expected results:

  1. The service user can not access the web site blocked by the tenant filtering policies.

 Actual results:

  1. The service user cannot access the video service while another service user inside the same house can access the video service .

 

Follow-on activities:

Inputs for WT-411: 

  1. Occo-Nf-sdn-vnf:   CCO DO intteracts with Edge SDN M&C to do FCAPS for vFW VNF.


6.5 Test Case for APPN-010

This test case aims to validate the service depicted the AppNote-010 (Converged Core-as-a-Service (with PNF based User Plane), in which the Converged Core service is instantiated in a Cloud CO domain. The  Converged Core can serve both wireline and wireless services by providing the functionalities such as BNG, EPC and etc. In this test case, the Converged Core is only offering the BNG functionality.


The more information about APPN-010, please refer to the following link:

https://wiki.broadband-forum.org/pages/viewpage.action?pageId=44145700


Test architecture: 

The test architecture is built in Open Broadband Laboratory Asia, which provides the test bed and conducts the test procedures.


Prerequisites:

  • The Cloud CO Domain instance is already fully bootstrapped. 
  • The BNG User Plane PNFs have been deployed to fulfill the  BNG user plane. The BNG User Plane PNFs have IP addresses to communicate with Edge SDN M&C if BNG User Plane PNFs support the standard northbound Minf and Mfc interfaces.
     

Table 1: The System Under Test (SUT) Hardware

SUT

Hardware

Number

COTS

(2288V3)


 

Switch Fabric


 

vBNG-UP PNF



Table 2: The System Under Test (SUT) Software

SUT

Software

OS 

 • Ubuntu

Orchestrator

•  NetOpen Platform (Huawei)

SDN Controller

• Agile Control (Huawei)

VIM

• Openstack  Mikata

VNFM

• Cloud CSM (Huawei)

vBNG-CP VNF



Interaction 1

Procedure:

  1. CCO DO requests VIM to deploy a BNG Control Plane VNF instance and establish the connectivity between the BNG Control Plane VNF and the  Edge SDN M&C. 
  2. CCO DO requests Edge SDN M&C to configure the BNG Control Plane VNF assigned for the Service Provider tenant in compliance with their commercial agreements.
  3. CCO DO requests Edge SDN M&C to configure the BNG User Plane PNF assigned for the Service Provider tenant as well.

Note: When above procedures are achieved, there will be a few BNG function testes following, such as subscriber sessions establishing, centralized IP address pool management, carrier-grade network address translation etc.

 Expected results:

  1. BNG resources, i.e., VNF and PNF, have been allocated.

  2. The following BNG function testes have been done successfully

 Actual results:

  1. TBD

 

Follow-on activities:

Inputs for WT-411: 



6.6 Test Case for APPN-006

This test case aims to validate the interactions depicted the AppNote-006 (Virtual Access Node - based FANs service), in which a Fixed Access Network Sharing service provided by an Infrastructure Provider (InP) is established via a fixed access CloudCO Domain architecture.



Test architecture: 

In the context of CloudCO, the generic test environment consists of an NFVI, a set of Access I/O and a set of Network I/O. The following Figure 1 illustrates a testing architecture providing an abstract framework within which the FANS use case can fit it.


The test bed includes a fabric switch and a minimal server farm as required in section 7.1 of TR-384 [TBA].

The minimal server farm includes at least one compute server and one controller server if HA is not required in the CloudCO. The test architecture is built in an Open Broadband Laboratory (OBLabs), which provides the test bed and conducts the test procedures.

The configurations for the server and switch are recommended as per the tables below.

Table 1: The System Under Test (SUT) Hardware

Key Hardware

Description

QuantityNote

Server

CPU

Intel® Xeon® E5-2699 v3 2.3GHz/18-core

4

Firmware

BIOS/EFI compatible for x86-family blades

4
Local Storage4*600G4Additional and/or faster disks are nice to have and may produce a better result.
Memory4*16GB4
NIC4*1GE4
4*10GE4Intel® 82599 10 Gigabit Ethernet Controller
Power SupplySingle Power Supply acceptable1Redundant power not required/nice to have

Networking

Switch24 Port TOR Switch (Combination of 1GE and 10GE based on network topology options)2
OLTTBD1Depending on the Vendor solution
ONTTBD2Depending on the Vendor solution


Table 2: The System Under Test (SUT) Software

Key Software

Description

VersionNote

OS 

  Ubuntu

>= 16.04 LTSFurther releases to be evaluated

CCO DO

TBD

TBDDepending on the Vendor solution

Access SDN M&C

TBD

TBDDepending on the Vendor solution

VIM

Openstack  Mikata

>= 6.0.0Further releases to be evaluated

VNFM

TBD

TBDDepending on the Vendor solution

vAN

TBD

TBDDepending on the Vendor solution


TBD: Depending on the environment and resources availabilities in the OBLab.

Prerequisites:

  • The CloudCO Domain Orchestrator instance and the SDN Manager&Controller are already fully bootstrapped
  • A single VNFM is deployed in the CloudCO and it is the solely responsible for instantiate the VNFs (vANs)
  • The VIM is installed in the COTS within the NFVI

Note: For ease of setup, it is assumed that the CloudCO DO, SDN Manager&Controller, VNFM and VIM instances run locally over the compute host. This shall not considered as a restrictive choice with regard to a more realistic architecture with distribution of these functions at different locations (and hosts) in the network.

  • The OLT is physically connected with switch fabric
  • The OLT is configured with a VLAN dedicated to management and control. Traffic over this VLAN is extended to across the switch connected to the OLT. The VLAN is also extended to the compute hosts that are connected to this switch

Procedure:

Please refer to the “CloudCO-APPN-006 - Virtual Access Node (vAN)-based FANS” service, section 6.

https://www.broadband-forum.org/technical/download/BBF-119-AppNotes-APPN-006-vAN-V2.pdf

Expected results:

Interaction 1 - Create a VNO Network:

  1. VNOs can access to its OLTs network map according to the list agreed with the InP

Interaction 2 - Create a VNO L2 Service:

  1. L2 resources of the target OLT are configured and allocated per VNO request. 

  2. InP’s full network view and VNO’s scoped network view are updated per the above configuration.

Interaction 3 - Pre-previsioning of a VNO's ONT:

  1. L2 resources of the target ONT are configured and allocated per VNO request. 

  2. InP’s full network view and VNO’s scoped network view are updated per the above configuration.

Interaction 4 - Activate a VNO's ONT:

  1. L1 and L2 connectivity is established between the ONT and the OLT’s uplink interface. 

  2. VNO is able to deliver the service to the end customer.

Interaction 5 - L2 Performance Monitoring on a VNO ONT:

  1. L2 PM collection is carried out as configured. 

  2. Collected L2 PM counters are reported and stored in the SDN Manager&Controller.
  3. Collected L2 PM counters are made available to the VNO Orchestrator.

Interaction 6 - Handling a Customer Migration:

  1. The customer termination is removed from the VNOA’s manageable resources

  2. The customer migration is completed successfully and the customer can access to connectivity and services through VNOB network.



Actual results:

  1. TBD

 

Follow-on activities:

Inputs for WT-411/WT-413: 

a)      Os-Ma-ccodo: A FANS tailored interface is needed to be exposed by the CCO DO to the VNO Orchestrator to integrate Service Configurations and Management for different Virtual Network Operators (VNOs). The current set of parameters as well as their degree of abstraction of their representation on the VNO Orchestrator depends on the technical, commercial and/or regulatory agreements of each deployment environment.

b)      Occo-Nf-sdn-pnf: CCO DO interacts with the Access SDN M&C to do FCAPS for the physical OLT.

c)      Occo-Nf-sdn-vnf: CCO DO interacts with the Access SDN M&C to do FCAPS for the vAN.

d)      Minf: Access SDN M&C interacts with the OLT for configuring and reading attributes (e.g., configure VLANs).


e)      Ms: Access SDN M&C interacts with the vAN for configuring and reading attributes.


  • No labels