Wiki

The Metro Ethernet Forums (MEF) defines an architecture targeted at enabling virtual Ethernet Services. The MEF architecture includes the definition of reference entities, the relationships between the reference entities, and attribute groups.

lsoapi is a software stack that enables the creation of MEF defined services. The structure of the code is heavily influenced by MEF concepts and attribute definitions. The following MEF documents were referenced when designing the lsoapi software

Primary MEF References

• MEF 6.2: EVC Ethernet Services Definitions Phase 3, August, 2014
• MEF 10.3: Ethernet Services Attributes Phase 3, October 2013

Secondary MEF References

• MEF 26.1: External Network Network Interface (ENNI) – Phase 2, January 2012
• MEF 4: Metro Ethernet Network Architecture Framework - Part 1: Generic Framework, May 2004
• MEF 11: User Network Interface (UNI) Requirements and Framework, November 2004
• MEF 7.2: Carrier Ethernet Management Information Model, April 2013
• MEF 12.1 Carrier Ethernet Network Architecture Framework Part 2: Ethernet Services Layer - Base Elements, April 15, 2010
• MEF 12.1.1 Carrier Ethernet Network Architecture Framework, Part 2: Ethernet Services Layer - External Interface Extensions, October 14, 2011

The software is partitioned into services layers, each layer is dedicated to creating, persisting, and managing a specific MEF defined entity, along with the associated attributes.

Each service layer presents a Northbound Rest Interface, which in general allows requesters to create, delete, modify, suspend, and resume entities for which it is responsible. Each layer may requests the services the layer directly beneath it via REST calls in order to carry out it’s responsibilities.

The following diagram provides a high level overview of the service layers defined, along with general responsibilities of each service layer, and the REST communications that place among them (the components of this architecture that are implemented in the lsoapi code base are shown in blue)

The lsoapi service code is dependent upon the following technologies

• Java
• Maven to buid the lsoapi .war and .jar files
• tomcat to serve lsoapi .war files
• JAXRS/Jersey for REST interactions
• see lsoapi/README.md for detailed instruction on installing these technologies

In addition of you need to run the OpenDaylight UNI-Manager emulator, the following dependencies come into play

• nodejs/npm to install dependencies for and run the UNI-Manager emulator nodejs app
• see lsoapi/README.md for detailed instruction on installing these technologies

Finally, if you decide to run the demo-ui, the following dependencies come into play

• nodejs/npm to install dependencies for and run the nodejs serving the UI
• bower to install front end web UI dependencies (like angular)
• grunt for front end web UI preprocessing tasks (like less to css)
• see lsoapi/demo-ui/README.md for detailed instruction on installing these technologies

The lsoapi services code is organized into the following directory structure (directory names enclosed in <>). Each directory identified below contains to a unique maven .pom file.

<lsoapi> ........ project root directory
  <common> ...... common utilities
  <cos>
    <cosbase> ... CoS code unrelated to providing REST services
    <cosmgr> .... code for providing REST services to CRUD CoS instances
  <svc>
    <svcbase> ... MEF Services (EPL) code unrelated to providing REST services
    <svcmgr> .... code for providing REST services to CRUD MEF Services (EPL) instances
  <evc>
    <svcbase> ... EVC code unrelated to providing REST services
    <svcmgr> .... code for providing REST services to CRUD EVC instances
  <uni>
    <unibase> ... UNI code unrelated to providing REST services
    <unimgr> .... OpenDaylight UNI Manger Emulator
    

In general, the <xxxbase> and <xxxmgr> directories (where xxx is cos, svc, evc, and uni, are organized in the same manner, as described below.

<xxxbase>

<xxxbase> directories contain code that supports the definition and management of MEF entities, but contain no code specific to providing the REST service layer for that entity. The build results in in a xxxbase.jar file. This .jar file for each of these directories, that can be (and is) used by any of the service layers, which is why the are packaged in a seperate .jar file.

The contents of the <xxxbase> in general is structured as follows: (again, remember that xxx = cos, or evc, or svc, or uni)

<xxxbase>/src/main/java/com/cablelabs/vcpe/**xxx**/**xxx**base/
  <client> ...... code supporting the sending of REST messages to the **xxx** server
  <model> ....... defines the **xxx** class with accompanying MEF attributes
  <repository> .. data store for **xxx** entities