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 result in a xxxbase.jar file for each <xxxbase> directory that can be (and is) used by any of the service layers, which is why they are packaged in a seperate .jar file.

The contents of the <xxxbase> directory in general is structured as follows: (again, remember that xxx represents a MEF entity, specifically : cos, or evc, or svc, or uni)

<xxxbase>/src/main/java/com/cablelabs/vcpe/xxx/xxxbase/
  <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
    

<xxxmgr>

<xxxmgr> directories contain code that supports the actual RESTFUL service for each MEF entity. The code in contained in <xxxmgr> may have dependencies on any of the <xxxbase> .jar files (for example <evcmgr> is dependent upon <cosbase> in order to make rest calls the the cosmgr REST server.

The contents of the <xxxmgr> directory in general is structured as follows:

xxxmgr/src/main/java/com/cablelabs/vcpe/xxx/xxxmgr/*.java ... contains code for serving xxx rest requests

The one exception the the directory structures defined above is <unimgr> directory. The lsoapi service layers do NOT include a UNI service layer (i.e. UNI manager), but rather, the UNI Manager will be contained within OpenDaylight.

However, the lsoapi code base does provide a nodejs UNI Manager Emulator, which can receive and process all REST messages defined by the ODL UNI Manager northbound interface. The emulator can be useful if you do not have OpenDaylight installed on you development machine, but you would like to test the UNI Northbound REST API messaging.

Specifically, the <evcmgr> code consumes the ODL Uni manager northbound REST interface (i.e. it makes NETCONF REST calls to OpenDaylight, which can be alternately served by the emulator).

The details for configuring and running the emulator can be found in the lsoapi/README.md file

Return to main project page