This document describes the objectives, achievements and recommendations resulting from the work of several teams at the Euro16 LSO Hackathon which took place in Rome on April 27-29 with the participation of 19 organizations and over 45 individuals.

The primary objectives of the event included:- Acceleration of the development of LSO Presto related OpenDaylight and ONOS solutions for contribution to open source projects; Feedback to the MEF Technical and Operations Committee projects on standardized ordering via LSO Sonata Ordering API and the provisioning of CE 2.0 services via LSO Presto NRP API; Introduction of OpenLSO Service Function Chaining into CE 2.0 services; Development of the OpenCS Packet WAN and OpenCS Data Center use cases; Introduction of MEFnet for hosting both the OpenCS and the OpenLSO implementations; Introduction of Remote Teams into the LSO Hackathon environment.

A wide range of recommendations ensued from the work of the teams in the Euro16 LSO Hackathon including:- Recommendation to introduce intent-level abstraction at LSO Presto; Importance of L3 Forwarding Constructs for OpenLSO Service Function Chaining; Recommendation to qualify addresses separately from the Serviceability and Ordering APIs at the LSO Sonata Reference Point; Publishing discovered inventory over the LSO Presto NRP API.

The next phase of the LSO Hackathon is planned for MEF16 in November 2016 where the work will be extended and integrated to support overarching Third Network service projects that are built upon underlying OpenLSO scenarios and OpenCS use cases.



The MEF has embarked on a series of initiatives aimed at facilitating its Third Network vision. The Euro16 LSO Hackathon is the second in the series of LSO Hackathon events facilitated by the MEF in order to accelerate the use of development of Third Network services based on LSO, SDN, NFV and CE 2.0 services encapsulated in OpenLSO scenarios and OpenCS use cases as shown in the diagram above.

OpenLSO scenarios express the capabilities required by service providers in order to orchestrate end to end services as described by MEF specifications and are essential elements in all aspects of the lifecycles of Third Network services.

OpenCS use case instances represent the services under the control of a specific Operator and which are not directly visible to the Third Network service provider, but are orchestrated as part of a federated system initiated by that same Third Network service provider via LSO Presto APIs.

The Euro16 LSO Hackathon had the following objectives:

  • Accelerate the development of comprehensive OpenLSO scenarios and OpenCS use cases as part of the MEF's Open Initiative for the benefit of the open source projects and the industry as a whole
  • Provide feedback to ongoing MEF projects in support of the MEF's Agile Standards Development approach to specification development
  • Facilitate discussion, collaboration and the development of ideas, sample code and solutions that can be used for the benefit of service providers and technology vendors
  • Encourage interdepartmental collaboration and communications within MEF member companies - especially between BSS/OSS/service orchestration professionals and networking service/infrastructure professionals.

In the Euro16 LSO Hackathon, the OpenLSO scenarios that were worked upon by the hackathoners were OpenLSO Service Function Chaining and Open LSO Inter-Carrier Ordering. The OpenCS use cases were OpenCS Data Center and OpenCS Packet WAN. End to end Third Network services were not specified and will be introduced in the MEF16 LSO Hackathon.


The event was held on Wednesday 27th - Friday 29th April 2016 with around 35 people participating in the face to face event in Rome, an AT&T Remote Team in Plano, TX in the US and other participants attending remotely from other parts of the US.

This White Paper describes the event and the outcomes, how the 4 objectives listed above were achieved, as well as providing proposals for work in the next LSO Hackathon.


Daniel Bar-Lev - MEF

Charles Eckel - Cisco Devnet

Table of Contents




OpenCS Packet WAN E-Line Instance

The OpenCS Packet WAN use case is oriented around orchestrating CE 2.0 services using SDN controllers in combination with CE 2.0 networking devices. The current instance is focused on using the OpenDaylight SDN controller in combination with CE 2.0 certified devices from Cisco and other MEF members.

The OpenCS Packet WAN team led by Donald Hunter and Charles Eckel of Cisco (see list of participants at right of page) at the Euro16 LSO Hackathon focused on the following objectives:

  • Extending the OpenDaylight 'UNI Manager' plug-in for use in the OpenCS Packet WAN use case
  • Implementing the latest work of the MEF LSO Presto Network Resources Provisioning (NRP) API project
  • Providing an OpenCS solution for the OpenLSO Service Chaining use case (see section below)


The OpenDaylight 'UNI Manager' incubation project was initiated by CableLabs in 2015 to introduce E-Line service solutions into OpenDaylight. Leading up to the hackathon, David Goldberg from HP Enterprises was elected the new Project Lead as individuals from several companies, including those in the Open CS Packet WAN team, expressed interest in moving the project forward.


The team worked closely with Jack Pugaczewski at CenturyLink who is leading the specifications work for the LSO Presto NRP API project and produced an SDK for the team. The team also provided feedback to the NRP API team to improve its continued development as part of the Agile Standards Development process.

The following describes the highlights of the team's work and their recommendations.

Project Goals

The goals fell into two categories - recommendations for the MEF LSO Presto NRP API project and code contributions and recommendations for the OpenDaylight community.

  • Refactor OpenDaylight UNI Manager project with layers of abstraction
    The objective here was to introduce layers of abstraction between the MEF NRP Interface Model and vendor-specific device models. The approach to abstraction in the area of the LSO Presto Reference Point and above (e.g. LSO Legato Reference Point) has evolved substantially since the GEN15 LSO Hackathon and the team felt it necessary to update the architecture of the UNI Manager plug-in accordingly.
  • Hack on business logic for layer to layer transformation
    The purpose here was to improve the business logic to be able to take incoming orders and transform them into service creation activities for point to point services, with an eye to supporting other service constructs in the future.
  • Integrate NRP_Interface YANG model
    The NRP API project is developing a UML model and related YANG model as part of the SDK to be used by the hackathon team. The team aimed to make this YANG model available to the OpenDaylight community through a contribution to the UNI Manager project.
  • Migrate Cisco XR NETCONF driver from SCA API to NRP API as a vendor specific device layer implementation
    Following on from the progress made by the Cisco hackathoners in the GEN15 LSO Hackathon based on the LSO Presto SCA (Service Configuration and Activation) API, it was made an objective to make the Cisco XR NETCONF driver available in the context of the NRP API.
  • Develop a Microsemi NETCONF driver
    This was an opportunity to introduce a device driver framework that could support multiple vendors, and Microsemi was able to develop an example NETCONF driver.
  • Enhance EAGLE xmi2yang tool
    The team wanted to use the hackathon to deal with some known weaknesses in the tool when using it for generating YANG models from UML models.


  • Integration of NRP_Interface YANG model into ODL Uni-manager
    Much time was spent on simplifying the YANG model in order to make it more valid for use with RESTCONF. Several limitations were exposed during the LSO Hackathon when attempting to use the YANG model in OpenDaylight and these had to be addressed in order to make progress. This will result in substantial feedback for the MEF LSO Presto NRP Interface Profile, the ONF Core Model and the EAGLE xmi2yang generation tool.
  • Created multi-vendor "Activation Driver' framework
    A framework to support drivers from multiple vendors was created.
  • Build NETCONF activation drivers for Cisco XR, Microsemi, Tail-f NSO
    The work was started to support 3 different backends but time did not permit completion.  
  • Designed framework for extensible Uni-manager

Lessons Learned

  • NRP model needs to be less granular - abstract out some of the NRP details
    The Euro16 LSO Hackathon highlighted the need to make the NRP model more abstract 
  • Versioning of the NRP model will be important to support maintainability/interoperability
    It is clear that multiple versions of the NRP model will be in use by orchestrators simultaneously. A discussion is needed to come up with a plan for versioning.
  • Need to publish NRP inventory/instance data by making data available to orchestrators via LSO Presto
    OpenDaylight is well suited to provide inventory/instance information to high level orchestrators. This should be addressed in future work of the LSO Presto APIs.
  • The Information Models and the tools used to generate the YANG models can greatly impact the quality of the resulting YANG models and their integration into the IETF topology
    It became very apparent from the team's hackathon work how sensitive to the underlying MEF and ONF Information Models the YANG model generation can be. Also, nobody at present is willing to invest in the xmi2yang tool which is a very important part of the toolbox for YANG model generation and eventual integration into the IETF topology. This will need to be addressed. 

Next Developments

  • Refactor existing OVS-DB backend into new framework
    The existing OpenDaylight UNI Manager project will need to be refactored to take into account the new contribution resulting from the hackathon. 
  • Move each activation driver into separate bundle to allow for packaging and runtime flexibility
    Make it easier for vendors to create new activation drivers and package them separately to take advantage of the LSO Presto NRP API effectively 
  • Model & toolchain requirements
    • Reevaluate the use of the ONF Core Model, which is very broad
    • MEF Network Resource & NRP models
    • Refactoring goals
    • xmi2yang enhancements
    • Explore alternative toolchains
    • Build a code-generation test suite


MEFnet Setup
  • Cisco CE 2.0 switch/routers were setup and configured in Iometrix for remote use by Rome hackathoners.
  • The OpenDaylight SDN controller was setup and configured on servers in Iometrix for remote use by Rome hackathoners.
  • The CE 2.0 service test setup (see below) was setup and configured in Iometrix for local operation by Iometrix staff.

OpenCS Data Center E-Line Instance

The OpenCS Data Center use case describes the hardware/software architecture to deliver single domain Third Network services using approaches already common in data centers - specifically providing a carrier-grade Network as a Service built on an open platform bringing data center economy and hyper-scalability as well as cloud agility. The OpenCS Data Center project is collaborating closely with ON.Lab to adopt the E-CORD approach. As part of this close collaboration, ON.Lab joined the Euro16 LSO Hackathon to identify the next steps for ON.Lab and MEF to implement in order to show how to deliver E-Line services in an E-CORD environment.



Project Goals

The OpenCS Data Center E-Line team focused on identifying the key elements missing for enabling the delivery of EPLs in an E-CORD setup.

  • Integrate LSO Presto NRP API with ONOS
    This was the first time that an ONOS plug-in for LSO Presto NRP API was worked on (cf. OpenDaylight plug-in for LSO Presto NRP API in GEN15 LSO Hackathon in November 2015 and in Euro16 LSO Hackathon)
  • Provide LSO Presto NRP API project with OpenCS Data Center requirements
    The evolving work in the TOC project defining the LSO Presto NRP API is greatly influenced by the ongoing work in the LSO Hackathons, specifically lessons from development of API plug-ins in the open source SDN controller projects.
  • Demonstrate EPL connectivity via at least one Forwarding Construct
    Delivering an EPL service over E-CORD is the base line for success in the OpenCS Data Center use case and therefore an important objective for the team
  • Create intent subsystems
    Rather than interacting directly with flow rules, the team aimed to demonstrate abstraction into flow objectives and thus hide specific table types and pipeline (see diagram below)




  • Application developed for using NRP API with ONOS
    Swagger-generated Java models were used to create the application, together with a translator to convert to/from ONOS carrierethernet app Java objects
  • Enhancement of Carrier Ethernet app
    UNIs, ENNIs and NNIs were added to the app in addition to forwarding constructs and LogitalTerminationPoint.
  • Feedback for TOC LSO Presto NRP API project
    The team continuously reviewed NRP API drafts and prrovided feedback to the project for modifications/corrections/enhancements of the API
  • Outline of Intents for future use with Carrier Ethernet
    The Intent approach with better abstraction at the LSO Presto interface will be of great benefit to the ONOS community going forward.
  • Demo using Mininet with CPqD OF1.3 switches
    The team demonstrated GET LogicalTerminationPoint, with the latter automatically obtained from the ONOS topology. The demo also successfully POSTed two forwarding constructs using REST NRP API and showed end-to-end connectivity through those forwarding constructs

Lessons Learned

  • Logistics
    A great deal more time and preparation is required in advance of the LSO Hackathon event and the remote aspect of MEFnet needs to worked on

Next Developments

  • Extend OpenCS Data Center instance
    The roadmap will be set by the OpenCS Data Center group led by Lucy Yong (Huawei) and Jack Pugaczewski (CenturyLink)
MEFnet Setup
  • Edge Core Network open spec hardware switches were setup and configured in hyperscale leaf-spine arrangement in Iometrix for remote use by Rome hackathoners.
  • The ONOS SDN controller was setup and configured on servers by ON.Lab in Iometrix for remote use by Rome hackathoners.
  • The CE 2.0 service test setup (see below) was setup and configured in Iometrix for local operation by Iometrix staff.


Edge Core Networks

Pete Maricle


Lucy Yong


Fengkai Li


Hans Bjurstrom


Isabelle Morency

Michel Ouellette


Yuta Higuchi

Naoki Shiota


Toru Furusawa


Marc De Leenheer

Akaya Koshibe

 Larry Peterson


Corona Wei

Useful Links

OpenLSO Inter-Carrier Service Ordering Scenario

The OpenLSO Service Ordering scenario was developed to exercise the creating, updating, and cancelling of an Access EPL order originating from a Service Provider and received by an Operator. The scenario was developed by the MEF Ethernet Ordering Working Group.


The APIs for the scenario were developed by CableLabs based on TM Forum's SID and introduced to the MEF to help the industry align on a common ordering API interface for Access EPL.  During the Euro16 LSO Hackathon, it was agreed that one group would act as the Service Provider and a different group would act as the Operator. 

Project Goals

  • Exercise the Ordering API at the LSO Sonata Reference Point in order to determine if suitable attributes for describing the business requirements as well as the technical requirements for the Access EPL service can be communicated between the Service Provider and the Operator.
  • Extend the Ordering data model and API to include any new attributes required for ordering an Access EPL service from the Operator by the Service Provider.
  • Expose the Ordering API to other Euro16 LSO Hackathon participants working on the LSO Legato Reference Point, to determine if information from the order would be useful in implementation of a service on the southbound LSO Legato API.
  • Ensure that the Ordering API was not too specific to North America and to determine if the API could handle non-North American addresses for example, and other non-North American business requirements.


  • Successfully initiated an Access EPL order between the Service Provider group (led by AT&T) and Operator group (led by Ciena)
    AT&T held the role of order initiator (Service Provider) for the Access EPL Service and Ciena held the role of the receiving end of the order (Operator).  In this scenario, the Service Provider is not able to establish the end to end service on its own network exclusively, so it initiates an Access EPL order request to the Operator.  Ciena was able to receive and parse the request successfully and send a successful response back to AT&T. 
  • Ciena learned that the information contained in the Order API was not sufficient for them to initiate the implementation of the EPL service through the Legato interface within a single carrier’s network.
    Ciena was looking for granular information such as originating and terminating IP addresses, which are not attributes that would be included in an Order.  They determined that they needed an interface to a Network Inventory system as a result of this discovery.

Lessons Learned

  • Most of the attributes in the Order API for Access EPL were sufficient for AT&T and Ciena to communicate the business requirements and technical requirements of the Access EPL service to be established by the Operator, however there were some recommendations on additional attributes that would facilitate the OpenLSO Service Order scenario.  Those attributes include:
    • S-VLAN ID – Ciena requested that the Service Provider (acting as the Buyer) be able to optionally submit an S-VLAN ID in the order request and that the Operator (acting as the Seller) be able to return the S-VLAN ID used in the response to the order request.
    • Amdocs, CenturyLink, AT&T, and Ciena had a productive discussion on the necessity of S-VLAN IDs in the order after Ciena’s request to add the S-VLAN ID to an order.  Lots of back and forth ensued, with the final decision to add the S-VLAN ID as optional on the initial order request and to expect that it would be provided (or confirmed) by the seller in subsequent response to the order request.
    • AT&T recommended the addition of a reference ID for the Service Address associated with the service location.  This would facilitate not having to pass around a fully qualified service address in other API calls where service address was required.  The reference ID could be used instead.
    • AT&T highlighted the fact that “Locality” was the attribute being used to hold the city value, instead of having a separate attribute “City” to hold the city value.  It was recommended to add a “City” attribute for  addresses.
  • AT&T made comments about the general approach and logistics of the execution of the Euro16 LSO Hackathon that included the following:
    • “Preparation before the hackathon helped the remote teams” – prior to the kickoff of the Euro16 Hackathon, CableLabs engaged with Euro16 LSO Hackathon participants to explain the APIs and answer questions. 
    • “All the documentation was well laid out on Github” – CableLabs posted instructions on how to get started using the CableLabs-defined APIs, the use cases to be used during the Euro16 LSO Hackathon, and other guidance materials that proved helpful to the smooth running of the Euro16 LSO Hackathon.
    • “APIs hosted by MEF (CableLabs) on Heroku were stable and working” – CableLabs had developed, tested, and vetted the APIs with their own Proof of Concept development that utilized the APIs prior to introducting them to the MEF for use during the Euro16 LSO Hackathon.
    • “Better logistics for remote participation” – AT&T was exclusively remote during the execution of the Euro16 LSO Hackathon which posed more challenges than having someone local to the event. 
  • Ericsson recommended that Service Provider (Buyer) Technical Contact information should be required in the order (in addition to the Order Contact)
  • iconectiv recommended inclusion of ITU-T and ATIS into the ordering project.  Here are the comments:
    • “Generally, I think the following attributes might benefit by including optional formats from ITU-T as well as ATIS. I think you’ve heard me talk about accommodating ATIS for domestic use in support of backwards compatibility to the ASR as well as aiding Service Providers transitioning to LSO, but I think the addition of ITU-T could be applied to a number of attributes for international use. Everything below would be optional, of course.
    • UNI ID, ENNI ID, OVC ID, EVC ID – All of these could be identified with an ATIS format, specifically, ATIS-0300097 Serial Number Format
    • OVC ID, ENNI ID – These attributes could be identified with the ITU-T M.1400 format
    • The term “CLLI” should be replaced with its respective function e.g., switching center, POP, etc. And then, that attribute could be populated with the ATIS-0300253 format, or ITU-T M.1400 format
    • Attributes similar to Provider ID, Entity name, or Service Provider Name could use the ATIS-0300251 format, or the ITU-T Carrier Codes format
    • Physical Medium – The ATIS-0300223 format could be used to specify channel and interface specifications
    • UNI Port size, UNI port type – The ITU-T M.1400 format could identify this information

Next Developments

  • The MEF Ethernet Ordering Working Group will review the recommended updates to the order process, specifically the attributes referenced in “Lessons Learned” section above to finalize decisions on the inclusion of new attributes.
  • The CableLabs team will then update the API interfaces and data models to reflect the attribute additions.


Euro16 OpenLSO Ordering


Diagram Components
E-LineThe purpose of the OpenLSO Service Ordering scenario was to ultimately to create an E-Line comprising an E-Access available from within AT&T and a second E-Access ordered from an Operator
Service Provider DomainThe Service Provider domain comprises all the assets and systems within the direct control of the Service Provider - in this case, the Buyer (AT&T)
Operator DomainThe Operator domain comprises all the assess and systems exclusively within the control of the Operator - in this case, the Seller (Ciena)
AT&T Marketplace Business Poller (MPBP)A business application created together with AT&T 'buyer' team solely for the purpose of the Euro16 LSO Hackathon work. It enabled the AT&T systems to interact with the virtual AT&T Marketplace
Rome Marketplace Business Poller (MPBP)A business application created solely for the purpose of enabling the Rome 'seller' team to interact with the AT&T Marketplace during the Euro16 LSO Hackathon work.
AT&T MarketplaceA business application created together with the AT&T 'buyer' team to act as a buffer for placing service descriptions for services that the buyer team wanted to buy from any seller Operator of E-Access services
LSO Sonata Ordering APIAPI developed by the TOC Ordering project
LSO Cantata APIsAPI developed by Ciena for the Euro16 LSO Hackathon
Ciena mobile appMobile app developed by Ciena for demonstrating the Marketplace concept
LSO Legato APIsAPIs developed for the Euro16 LSO Hackathon
Amazon web servicesHosting service for some of the VMs used during hte Euro16 LSO Hackathon
LSOImplemented in this part of the LSO Hackathon using Ciena BluePlanet
LSO Presto APIAPI developed by the TOC LSO Presto NRP API project
SDNSDN controllers developed by Ciena (either closed source or based on ONOS)
LSO Adagio APIsAPIs developed for the Euro16 LSO Hackathon
MEFnetMEF ecosystem for hosting both hardware and VMs required for Open Initiative projects
UNIAs defined by MEF 6.x
Ciena 3916Ciena switching product
NNIInternal network network interface exposed by service decomposition  
CORD PODNetworking segment implemented based on CORD
ENNIAs defined MEF 26.x
E-AccessAs defined by MEF 33 and MEF 51



MEFnet Setup
  • Ciena CE 2.0 switches were setup and configured in Iometrix for remote use by Rome hackathoners.
  • The Blueplanet software was setup and configured on servers in Amazon Web Services by Ciena for remote use by Rome hackathoners.
  • The CE 2.0 service test setup (see below) was setup and configured in Iometrix for local operation by Iometrix staff.

OpenLSO Service Function Chaining Scenario

The OpenLSO Service Function Chaining team led by Shay Naeh at Gigaspaces introduced service function chaining to the MEF's CE 2.0 services for the first time at the Euro16 LSO Hackathon. Their innovative approach - based on extensive LSO Presto NRP API project collaboration with Jack Pugaczewski at CenturyLink and MEFnet support from Michel Ouellette and Isabelle Morency at Iometrix as well as coordination during the Euro16 LSO Hackathon with the OpenCS Packet WAN team - resulted in the demonstration of the injection of a virtual firewall into a live CE 2.0 E-Line service using TOSCA templates. This is the first time that VNFs have been injected into an E-Line 'pipe' to make it a 'smart pipe'. Multiple VNFs can be injected using this methodology and a SFC (service function chain) can be established across the VNFs.

Project Goals

  • Introduce 'bump in the wire' vFW VNF into an E-Line
    The primary objective of the OpenLSO Service Function Chaining team was to demonstrate how a Service Orchestrator like Cloudify can be used to introduce an arbitrary VNF (virtual network function) or alternatively a 'bump in the wire' service into an existing E-Line service - in this case, a virtual firewall service.

  • Demonstrate service function chaining (that multiple VNFs can be injected)
    In addition, the team sought to show that the same method can be applied to any VNF to enable service function chaining (SFC) in any CE 2.0 service.

  • Use TOSCA to define service templates, VNF Nodes and Relationships
    The MEF specifications are agnostic to the approach taken to set up service implementations. In the Euro16 LSO Hackathon, the team had the freedom to show that TOSCA is an effective method for setting up resources based on TOSCA templates.

  • Introduce LSO Legato API
    A stretch goal of the team was to introduce the use of an LSO Legato API. No specifications work in this area has been started so the approach taken was to use existing Cloudify APIs and open source implementation as a starting point that could trigger new LSO Legato API projects in the MEF Technical and Operations Committee.


  • Determination of routing path for service function chaining
    Using the flow shown below, the team created an HTTP POST request (see appendix) using Cloudify RESTful NBI. LSO Legato identifiers (CLLI) were then mapped to LSO Presto identifiers (IP addresses). After identifying the required service chain functions, the appropriate VNFs were launched and the required routing path determined.
  • Delivery of forwarding constructs to OpenCS Packet WAN instance
    The forwarding constructs were created and delivered utilizing API calls from Cloudify to LSO Presto NRP API. The demonstration showed integration with the underlying UNI Manager that implements the LSO Presto NRP Forwarding Construct API. Values were written to the UNI Manager database utilizing the LSO Presto NRP API.
  • Demonstration of Virtual Firewall in an EPL
    The demonstration showed how a firewall could be inserted into the EPL and turned on and off.
  • Testing firewall impact
    Testing was implemented by provisioning a Web client and a Web server on both sides of the E-Line in MEFnet (the remote Iometrix lab). The test showed that when changing the vFW rules on the fly and disallowing HTTP traffic, the WEB client could no longer reach the WEB server (the vFW dropped the packets) and when allowing HTTP traffic in the vFW, the WEB client successfully fetched a WEB page from the WEB server.








Lessons Learned

  • LSO Legato Ordering API
    The team identified missing attributes that should be included in a future LSO Legato Ordering API project.
  • L3 Support
    OpenCS Packet WAN use case and LSO Presto NRP API need to support L3 in order to effectively integrate service function chaining. The team achieved a work around for the Euro16 LSO Hackathon using L2 addressing on the vFW but this is not a good long term solution.
  • Use of TOSCA
    TOSCA meets service description requirements for service function chaining. However, work is required on the LSO Legato APIs and blueprint integration.
  • Testing Tools
    Additional testing tools are required to test higher layer (L3-L7) functionalities.

Next Steps

  • Enhancing LSO Presto NRP API
    New requirements for the LSO Presto NRP API were identified and will be provided to the NRP API project team.
  • L3 Forwarding Construct
    The importance of delivery of L3 Forwarding Constructs for OpenLSO Service Function Chaining was established and will be introduced into the LSO Reference Architecture Phase 2 project in the MEF Technical and Operations Committtee. 


MEFnet Setup
  • Gigaspaces Cloudify orchestration software was setup and configured on servers in Iometrix for remote use by Rome hackathoners.

Testing Setup

All the networking and test equipment was located for the duration of the Euro16 LSO Hackathon at the Iometrix test lab in South San Francisco.

The networking equipment was supplied by Ciena, Cisco and Edge Core Networks as shown in the diagram below:


The following are the highlights of the lessons learned as a result of the work of the participants prior to, and at the Euro16 LSO Hackathon event.

  • The MEF's current LSO Presto NRP model should be less granular and more abstract
  • Versioning of the LSO Presto NRP API will be essential
  • OpenCS inventory and instance data will need to be publishable via LSO Presto NRP API
  • The Information Models and the tools used to generate YANG models are critical to the success of Third Network services
  • Additional data is required to be communicated over the LSO Sonata Ordering API in order to meet the business and technical requirements of the Service Provider and Operator and should be included in the next phase of the LSO Sonata Ordering API project
  • Address qualification during serviceability should be handled separately from serviceability and ordering and the result captured in a unique ID
  • A new LSO Legato Ordering API project should be created
  • L3 Forwarding Constructs are essential for effective OpenLSO Service Function Chaining, even in a native L2 service environment
  • TOSCA should be leveraged more for OpenLSO scenario implementations

Aside from the lessons learned and the recommendations for next steps, the Euro16 LSO Hackathon, and the LSO Hackathon in general, is a very effective way to bring contributors from multiple standards organization and open source projects together to work toward a shared goal, accelerate the development of comprehensive OpenLSO scenarios and OpenCS use cases as part of the MEF's Open Initiative for the benefit of the open source projects and the industry as a whole. The timely feedback on the evolving standards and APIs is extremely valuable to the project teams responsible for formalizing those APIs. The reality check on the appropriateness and use of open source projects and tools in the cloud, SDN, and NFV space helps ensure that the open source software which so many in the various communities work tirelessly to develop can be leveraged successfully by the large number of service providers represented in the MEF.

Equally important to the noteworthy work done in preparation for, during, and after each LSO Hackathon is the community building and cultural exchange that comes from having such a skilled and diverse set of people work closely together as part of a focused effort. The results of the projects and the next steps summarized in this White Waper are just a snapshot of the collaborative realization of reference implementations of the LSO architecture that are being created within the content of MEF's OpenCS and OpenLSO.


TOSCA Blueprint for Firewall VNF

tosca_definitions_version : cloudify_dsl_1_1

  - http://www.getcloudify.org/spec/cloudify/3.3m5/types.yaml
  - http://www.getcloudify.org/spec/openstack-plugin/1.3m5/plugin.yaml



node_types :
derived_from : cloudify.types.Root
cloudify.interfaces.lifecycle :
        create: scripts/firewall/create.sh
        start: scripts/firewall/start.sh

node_templates :
vfw :

    type: firewall

Integration with OpenDaylight UNI Manager Plugin

 " FcRouteList ": {
   " FcRoute ": [{
     "id": "new-route",
     " ForwardingConstruct ": [{
       " uuid ": "an-original-name",
       " layerProtocolName ": "funky-layer-protocol",
       " forwardingDirection ": "BIDIRECTIONAL",
       " FcPort ": [{
         "id": "z-end",
         "_ ltpRefList ": [" host-z:z-end-ltp "]
       }, {
         "id": "a-end",
         "_ ltpRefList ": [" host-a:a-end-ltp "]
       "_ fcSpecRef ": "nonexistent- fcspec "
   }, {
     "id": "left",
     " ForwardingConstruct ": [{
       " uuid ": "left",
       " layerProtocolName ": "a-protocol",
       " forwardingDirection ": "BIDIRECTIONAL",
       " FcPort ": [{
         "id": "z-end",
         "_ ltpRefList": ["asr-101:GigabitEthernet0/0/1/17"]
       }, {
         "id": "a-end",
         "_ltpRefList": ["asr-101:GigabitEthernet0/0/1/19"]
       "_fcSpecRef": "nonexistent-fcspec


Potential EPL and vFW service TOSCA template


tosca_definitions_version : cloudify_dsl_1_2


  - http://www.getcloudify.org/spec/cloudify/3.3/types.yaml




    description: Identifier for network interface at one end of the connection


    description: Identifier for network interface at other end of the connection



    description: Boolean, indicates if firewall should be inserted


node_types :


    description: Point-to-point network connection

    derived_from : cloudify.nodes.Network



        description: First endpoint of the point-to-point connection

        type: string


        description: Second endpoint of the point-to-point connection

        type: string


        description: Indicates if firewall should be inserted

        type: boolean



node_templates :

  ethernetPrivateLine :

    description: MEF Ethernet Private Line service

    type: p2p


      endpoint1: { get_input : endpoint1 }

      endpoint2: { get_input : endpoint2 }

      firewall:  { get_input : firewall  }


      cloudify.interfaces.lifecycle :

        create: deploy_p2p.sh

        delete: uninstall_p2p.sh




  • No labels