The document summarizes plans for the Falcon and Goldeneye releases of the ONOS project. For the Falcon release in February 2016, goals include reviewing community plans, connecting people with shared interests, planning for dependencies, and providing sprint planning context. Various contributors outline proposed deliverables for their projects focusing on areas like core, northbound, southbound, virtualization, and test infrastructure improvements. The Goldeneye release in May 2016 aims to build upon work from Falcon with additional features, integrations, and enhancements across many areas.

1. Falcon Planning
5 January 2016
Bill Snow, David Boswell, Patrick Liu

2. Logistics
Mute your line
Call will be recorded

3. Goals
● Review community plans for Falcon and
Goldeneye releases
○ Falcon: February 2016
○ Goldeneye: May 2016
● Help people with shared interests connect
● Plan for dependencies
● Understand integration load
● Get everyone on the same page
● Provide context for sprint planning

4. Contributors
● Deployments - Luca Prete
● GUI - Simon Hunt
● Northbound - Brian O’Connor
● Platform/Core - Madan Jampani
● Southbound - Ali Al-Shabibi
● Virtualization - Thomas Vachuska
● Test infrastructure - Suibin Zhang
● RCORD - Ali Al-Shabibi
● ECORD - Marc De Leenheer
● MCORD - Mingeun Yoon
● ACORD - Srikanth Vavilapalli
● ONOSFW - Patrick Liu
● SFC - Suresh BR
● Wiki enhancements - Ayaka
● SDN-IP - Pingping Lin
● Multicast - Rusty Eddy
● SONA - Sangho Shin
● NETCONF - Andrea Campanella
● Adaptable Flow Statistics - Taesang
Choi
● Alarm and Fault Management -
Damian O’Neill
● Security Mode ONOS -
Changhoon Yoon / Heedo Kang
● BGP-LS - Satish Karunanithi
● ONOS Federation - Matteo Gerola
● Control Plane Monitor - Jian Li
● Debug tools - Jiao Zhang
● Yangforge - Peter Lee
● Yang model - Gaurav/Vinod
● PCE, PCECC - Satish Karunanithi

5. Sprint Schedule
Falcon sprints
Jan 5 - Jan 22
Jan 25 - Feb 12
Feb 12 feature/integration complete
Feb 15 - Feb 26
Start RC build process
Feb 26 Falcon branch
ONS extension Feb 29 - Mar 11
RC builds/Bugfix/ONS needs

6. Deployments
To be finalized
• ONOS/SDN-IP in KREONET
• Link between GEANT and and AMLight
• AMLight production slice
New
• ONOS/SDN-IP in KREONET
• Connection between the Global Testbed and AMLight
• VPLS app on AMLight
• GEANT and PO: CORSA and Infinera
Open/Blocking
• Intent framework – FlowObjectives (i.e. preventing depl.GEANT/ESNet)
• Internet2?
• New apps?
• Integration of multiple applications

7. Deployments (collateral - at least 50%)
• Proposal/talk @ ONS
• Preparation of racks/IT for ONS for all projects
• New server room
• …Infrastructure tasks...

8. Core
Madan Jampani
● Falcon deliverables
○ ONOS cluster scaling via ability to add/remove
nodes
○ Revamped distributed primitives with strict
linearizable semantics: provide better guarantees for
distributed lock ownership and distributed state
change notifications
● Proposed Goldeneye deliverables
○ Distributed Systems Platform
○ Distributed Message Bus
● Community help
○ Jira issues under Core epic labeled “starter”

9. Northbound
Intent subsystem & Intent Domains (Brian & Thomas)
Proposed Falcon Deliverables
● Validate single-domain APIs & provider interactions
● Reference intent domain provider for segment routing
Proposed Goldeneye release Deliverables
● Resurrect multi-domain APIs & implementations
● Provider for optical intent domain
Community help?
● Migrate intent framework to flow objectives
○ ONOS-2227 & https://gerrit.onosproject.org/#/c/6186

10. Northbound
Contact: Sho Shimizu
● Resource API improvements (for Falcon)
● Consolidate resource reservations into Intent Framework
for better resource tracking
○ for long term, but start initial works in Falcon
Proposed Falcon Deliverables
● Continuous type resource (like bandwidth) support
● Tx/Rx port resource distinction
● Optimization for large number of resources
Proposed Goldeneye release Deliverables
● Improved Intent Framework with better resource tracking

11. Southbound
Ali Al-Shabibi
Proposed Falcon Deliverables
● yang parser and generator to Java (JSON or JSON
schema IR)
● refactored and redesigned OF subsystem
Proposed Goldeneye release Deliverables
● General SB API made available through thrift/gRPC
Areas where you would like community help
● yang to JSON converter
● help refactoring and cleaning SB code.

12. Virtualization
Hypervisor-style network virtualization
Proposed Falcon Deliverables
● none
Proposed Goldeneye release Deliverables
● Initial implementation of a virtual network provider

13. DC Network Virtualization(1/2)
Project Name: SONA
Contact Sangho Shin
Proposed Falcon Deliverables
● OpenstackSwitching
○ Neutron security group support
● OpenstackRouting
○ Neutron L3 service plugin implementation
● OpenstackNode
○ Compute node bootstrap

14. DC Network Virtualization(2/2)
Proposed Goldeneye Deliverables
● Scalable Gateway
○ Multiple gateway servers
○ Multiple paths to gateway

15. QA: New Feature Coverage
● Feature Testsuites
○ Basic Netconf Testsuite Falcon
○ Sec-mode Performance Falcon
○ Basic OVS TTPs Testsuite GoldenEye
○ BGP-LS (Huawei) GoldenEye
○ VTN-L2&L3 Network (Huawei-China) Falcon
○ IPv6 Testsuite (Criterion - WIP) Falcon
● Existing High-Severity Bugs
○ ONOS-3183 Pingall on large topo (e.g. 20x20 torus) cause topology disband Falcon
○ ONOS-3564 Cannot ping IPv6 hosts using the fwd app Falcon
○ ONOS-3088 starting mininet with traffic before onos cluster causes onos to not discover
topology (Ciena) Falcon
○ ONOS-489 LINC-OE occasionally hangs when creating big topology GoldenEye

16. QA: Strengthen CHO, HA & Perf
● CHO
○ Fix current CHO on Spine-Leaf case failures Falcon
○ Implement “Chaos Monkey” - style test GoldenEye
■ allow scalability and flexibility to inject operational, failure events
■ ensure reproducibility and debuggability
● HA
○ Improve Robustness Falcon
○ New HA scenarios, e.g. network split brain scenarios,
dynamic clustering GoldenEye
● Perf & Scale
○ Add host discovery latency test Falcon
○ Fix intent scale test GoldenEye
● SDNIP
○ Take over/Sustain SDNIP/FSFW Tests Falcon

17. QA: Test Infra/Comm. Engagement
● Community Engagement
○ Refactor Sample script Falcon
■ Wrap onos startup config in json string in .params file
■ Scale up/down case with driver
○ Investigate Docker image as test env Falcon
■ Test dependencies can be reviewed, built, in Docker file
■ Docker image generated dynamically for test harness
○ Collaboration model with Huawei, Criterion, Calsoft
et. al. GoldenEye
● Prod. Testbed Improvement
○ Qualify new Karaf and maven versions for onos
Falcon
○ 2nd testbed to share load for non-perf tests Falcon
○ YAML Jenkins job review process GoldenEye
○ Separate test execution network from controller
network GoldenEye

18. Selective DPI
Project Name: OPEN-TAM
Proposed Falcon Deliverables
● Selective DPI - Off-Platform version
- DPI for the selected traffic flow by ONOS off-platform DPI module
Proposed G Deliverables
● Selective DPI - On-platform version
○ mainly targeted for control traffic diagnostics
● Selective DPI - On-/Off-Platform integrated version

19. ONOS Federation (Matteo - Bill)
Project Name: ONOS Multi-Clusters Peering
Provider (tentative…)
https://wiki.onosproject.org/display/ONOS/ONOS+Multi-
Clusters+Peering+Provider
Description:
● enable multiple ONOS clusters (multi administrative
domains) to share information about their networks,
using an East-West interface, based on a peer-to-peer
policy-based approach
● an application, running on top of a specific cluster, will
be able to configure, via the standard ONOS APIs,
routes crossing different domains

20. ONOS Federation (2/3)
Proposed Falcon Deliverables:
● Low-level design documentation
● Provider Implementation
● Provider Configuration (static file)
● Initial East-West interface
Areas where you would like community help
● We need to agree on the communication channel
between clusters with the ONOS core team
(multicast/broadcast/unicast, event-based/polling)

21. ONOS Federation (3/3)
Proposed Goldeneye release Deliverables:
● Provider Configuration (runtime)
● ONOS Shell extension
● East-West interface
● Basic policies
○ peering clusters allowed to access the local information
○ the maximum number of intents settable by each remote cluster
○ the weight of each interlink (the link between the local and
remote cluster)
● Advanced policies (TBD)

22. ONOSFW in OPNFV
Proposed Falcon Release Deliverables:
● Focus on OPNFV “B” Release (Feature/API freezed.
potential bug fixing)
● OPNFV “C” Release Planning (started on Jan 12)
● SFC enhancement (See SFC section for details)
Proposed Goldeneye Release Deliverables:
● To Be Updated. Contributions will be based on OPNFV
“C” Release Planning.

23. SFC (OPNFV)
Project Name: Service Function Chain
Updated by: SureshBR (Huawei)
https://wiki.onosproject.org/pages/viewpage.action?pageId=4163192
Proposed Falcon delivery
SFC extensions
Strengthen interfaces with classifier, SFF
Interface with SFC proxy
Load balancing among SFs within a SFC group
Tie-break conditions when more than one classifier rules are matched for an incoming packet
Proposed G release delivery (Tentative list)
Maintain global view of instantiated rules in classifiers. SFC monitoring and various counters
Devise robust fail-safe mechanism to restore SFC/SFP states in failure cases
Vailidity (life times) for SFC flow rules, Aggregate the classification rules to boost performance
Support withdraw of SFs when a SF is decommissioned. Take action on existing SFPs
Dynamically detect and take action for SF liveness/out of order scenarios
Support SFs reporting information back to ONOS. Aggregate classifier rules to boost the performance

24. OSPF as SBI
Project Name: OSPF
Updated by: Dhruv (Huawei)
https://wiki.onosproject.org/display/ONOS/OSPF+as+SBI
https://jira.onosproject.org/browse/ONOS-2737
Similar to BGP-LS, OSPF is another protocol suitable for learning L3 topology with TE data. It is suited
for network deployment that continue to use OSPF as the routing protocol. All changes in SBI only.
Proposed Falcon delivery
- Support for configuration and display
o OSPF router id
o OSPF enabled on interfaces / network with area information
o Suitable display information
- Support for following network types
o P2P, Broadcast
- Formation of OSPF peer
o OSPF FSM
o DB Synchronization
o DR election
o Packet processing
o Interface Handling
Proposed GoldenEye release delivery
none as of now
- Formation of OSPF peer
o Neighbor Handling
o Flooding
o Aging
- Self Generation of router and network LSA
- Learning all LSA and Maintain Link State DB
(LSDB)
- Support multiple area
- Support for Opaque LSA
o TE population

25. IS-IS as SBI
Project Name: IS-IS
Updated by: Dhruv (Huawei)
https://wiki.onosproject.org/display/ONOS/ISIS+as+SBI
Similar to BGP-LS, IS-IS is another protocol suitable for learning L3 topology with TE data. It is suited
for network deployment that continue to use IS-IS as the routing protocol. All changes in SBI only.
Proposed Falcon delivery
The framework and the API would be committed
Proposed GoldenEye release delivery
The full feature including -
- Support for configuration and display
- Support for following network types
- Formation of IS-IS peer
o IS-IS FSM
o LSDB Synchronization
o Designated Intermediate System (DIS) Handling
o Packet processing
o Interface Handling
o Neighbor Handling
o Flooding
o Aging
- Self Generation of LSP
- Learning all LSP and Maintain Link State DB
(LSDB)
- Support multiple area/level
- Support for extended IS and IP reachability
o TE population
- Support for three way handshake for P2P as
per RFC5303
- ISIS should be as per ISO-10589

26. L3 Topology Management
Project Name: L3 Topology Management
Updated by: Satish (Huawei)
Contributors: Satish
Background:
BGP-LS/OSPF SB protocols learn L3 network topology informations along with Traffic Engineering
parameters. These L3 network topology information must be managed in ONOS controller to facilitate
Path computation Element of ONOS to compute optimal E2E paths for MPLS TE tunnels.
This topology will be the base for the future G release PCE and PCECC solutions mentioned in next
slides.
Proposed Falcon release delivery
The full feature including -
- Learn L3 Topology using OSPF/BGP-LS
- Manage the L3 Device and L3 Links along with TE data of the network
- Provide data consistency and data persistence in distributed architecture

27. PCE and PCECC
Project Name: PCE & PCECC (PCE as a Central Controller)
Updated by: Satish (Huawei)
Contributors: Satish/Mahesh/UdayaShree/Janani/HariKrushna
Overview(PCE):
PCE (Path Computation Element) computes optimal E2E paths for MPLS TE tunnels within a PCE domain based on
network topology information and computational constraints.
Background(PCE):
On an MPLS TE network, the ingress of a tunnel uses the constrained shortest path first(CSPF) algorithm to
calculate tunnel paths based on information if TE database. Each ingress computes tunnel paths independently without
taking into account of network-wide resource usage.
As a result network-wide resource utilization efficiency is low. To address these limitations, we have PCE solution where
in PCE will reside in controller and can have the global view of the network and can compute the path better and
efficiently.
What is currently existing in ONOS is the “PCEP SBI”.
Proposed GoldenEye release delivery (PCE)
The full feature including -
- PCEP protocol enhancement to support PCECC/stateful
PCE/PCE Initiated LSP.
- Extending driver framework in order to setup MPLS
tunnel through PCEP protocol.
- CSPF path computation Algorithm in ONOS PCE
- PCE Global path optimization and backup path support
- WebUI enhancement for managing PCE tunnels

28. PCE and PCECC
Project Name: PCE & PCECC
Updated by: Satish (Huawei)
Contributors: Satish/Mahesh/UdayaShree/Janani/HariKrushna
Overview(PCECC):
PCECC is an extension to PCE to act as a centralized controller (PCECC) where in
the PCECC of controller takes care of label distribution and thus avoid signalling
protocols like RSVP-TE, LDP etc… An evolutionary approach towards SDN to reuse
PCEP protocol for label download to each node along the path (similar to OF).
PCECC-Basic
PCECC-SR (segment Routing) - extend existing SR to also support PCEP as the SBI
Proposed GoldenEye release delivery (PCE)
The full feature including -
- Support PCECC-Basic using PCEP protocol
- Support PCECC-SR (Segment Routing) using PCEP protocol.
- Label management for PCECC (PCE as Centralized Controller) will use the existing label management module of ONOS.

29. BGP FlowSpec SB Protocol
Project Name: BGP FlowSpec
Updated by: Satish (Huawei)
Contributors: Shashi & Thejaswi
Overview:
This is extension to the BGP LS project extending BGP to support FlowSpec. This aims to extend BGP protocol and add BGP flow
provider in ONOS to push flow rules to the network devices. For example, rule to drop all the packets from/to IP x.x.x.x upon DDOS
attack.
Background:
Distribute traffic flow specifications to the network devices using BGP. The use case include automated inter-domain coordination of
traffic filtering, such as what is required in order to mitigate DDoS attacks, and provide traffic filtering for VPN service.
Proposed Falcon release delivery
The full feature including -
- Extending BGP-LS to support BGP FlowSpec
- Add BGP Flow Provider
- Extend Driver/Behavior to support BGP flow spec.

30. YANG in ONOS (1/6)
Project Name: YANG based NBI Framework
Contact: gaurav.agrawal@huawei.com / vinods.kumar@huawei.com
Proposed Falcon Deliverables:
Basic YANG To JAVA Translator supporting:
- Basic Built-In Data Type
- Individual YANG File Support
L3VPN Application
Proposed G Release Deliverables:
Advanced YANG to JAVA Translator supporting:
- Derived Data Types
- Augmentation/Grouping/Union Support
- Module/Sub-module Support
- Import/Include Support
NBI Rest Framework Automation including:
- Automated APP URI Registration
- Automated JSON CODEC Implementation.

31. YANG in ONOS (2/6)
Current REST Mechanism

32. YANG in ONOS (3/6)
Proposed YANGtoJAVA Translator

33. YANG in ONOS (4/6)
Proposed YANG based REST Mechanism

34. YANG in ONOS (5/6)
SBI Current Mechanism & Proposal

35. YANG in ONOS (6/6)
Remarks and Advantages
- Augments the existing NBI Framework.
- No Changes in the Core.
- Provides Faster APP Development.
- Better Quality due to Automation.
- YANG based Standard Interface
Representation.

36. Fault Management and SNMP Provider
Project Name: Support Fault Management
Updated By: BTI Systems
JIRA details: https://jira.onosproject.org/browse/ONOS-3203
Summary: Add Fault Management of Network Elements (NEs) to ONOS. When
there is a fault, a NE will typically send a notification to the network operator via
SNMP. An alarm is a persistent indication of a fault that clears only when the
triggering condition has been resolved.
Work Activity:
● SNMP Provider
○ SNMP Config and API
○ MIB to Java Model
● Fault Management Application
○ Alarm Abstract Model
○ Interfaces
■ REST API
■ CLI
■ GUI Updates (Existing)
■ Alarms View (New)

37. Control Plane Monitor
Project name: control plane monitor
Updated by: Jian Li (ON.Lab)
JIRA details: https://jira.onosproject.org/browse/ONOS-3504
● Summary
○ The goal of this project is to efficiently collect, normalize and transform
the metrics produced in control plane
■ E.g., CPU load, memory usage, disk and network I/O,
OpenFlow message stats
● Work activity
○ Collect performance metrics in control plane
○ Aggregate performance metrics and store in backend storage
○ Distribute the metrics to other instances in on-demand manner
○ Implement new interfaces and improve existing web GUI
■ CLI, REST API
■ Web GUI to visualize the metrics
■ Improved instance panel

38. NETCONF SB protocol
Project Name: NETCONF Southbound protocol
Updated By: Andrea Campanella (ON.Lab)
JIRA details: https://jira.onosproject.org/browse/ONOS-1093
Wiki Page: https://wiki.onosproject.org/display/ONOS/NETCONF
Falcon proposals:
● Device updates and notifications
● ONOS-NETCONF device integration
○ status updates
○ automatic driver-deviceID
○ auto-discovery
● ECORD behaviors and device drivers.
● Basic JUNIT Test Suite (with HappiestMinds contribution)
● Abstraction of Messages as Objects
● Basic YANG integration
Goldeneye proposals:
● Full YANG integration
● Full JUNIT Test Suite
● RESTCONF implementation

39. Packet/Optical
Title: Converged Packet / Optical
Lead: Marc De Leenheer
Proposed Falcon Deliverables
● MEF services: E-Line & E-LAN
● Disaggregated ROADM drivers
Proposed G release Deliverables
● First deployment (GEANT - Infinera)
Areas where you would like community help
● UI extensions
● Intent domain plan

40. SDN-IP
Project Name: SDN-IP
Updated by: Pingping Lin
wiki: https://wiki.onosproject.org/display/ONOS/SDN-IP
Proposed Falcon release delivery:
Let reactive routing use new config subsystem
Nightly automatic tests on onos-1.4
Proposed Goldeneye release delivery
Nightly automatic tests on onos-1.5
listen also on standard BGP port 179
Update installed intents if MAC address of next hop changes
disable link discovery on external-facing switch ports
Areas where you would like community help
ONOS-3400: write one function test case in TestOn for reactive routing

41. M-CORD
Project Name: M-CORD
Updated by: Mingeun Yoon, Pingping Lin
wiki: https://wiki.onosproject.org/display/ONOS/M-CORD%3A+Mobile+Cord
Proposed Falcon release delivery(POC for ONS):
PGW-Control plane need to have an interface to ONOS NB for sending OF messages
to PGW-Data plane (currently Radisys team is working on it)

42. M-CORD
Project Name: M-CORD
Updated by: Mingeun Yoon, Pingping Lin
wiki: https://wiki.onosproject.org/display/ONOS/M-CORD%3A+Mobile+Cord
Proposed Falcon release delivery(POC for ONS):
Investigation whether VTN can provide all the paths for M-CORD connectivity
If not, add new functions.

43. ACORD (Analytics for CORD)
● Proposed “G” release Deliverables:
○ Dynamic TE with sFlow to reroute elephant flows in CORD fabric
■ sFlow support in fabric switches + ONOS Segment Routing Application
○ Packet Mirroring functionality in ONOS
■ To support (DPI based) dynamic probes in network
○ Integration with ONOS measurements
■ Control plane measurements in addition to OpenFlow statistics
■ “Push” mechanism instead of existing “Pull” mechanism

44. Security (1/2)
Project name: Security-Mode ONOS
Contact: Changhoon Yoon (chyoon87@kaist.ac.kr)
Contributors:
Changhoon, Heedo, Seungwon (KAIST)
Phil, Martin, Vinod (SRI)
Wiki: https://wiki.onosproject.org/display/ONOS/Security-Mode+ONOS
Proposed Falcon Deliverables
● Automatic application security policy extraction tool
● Static analysis
● Dynamic analysis, if needed
● More API permissions for new ONOS APIs

45. Security(2/2)
● Security policy enforcement on boot
○ auto-activated apps
■ enforce policy and activate, ONLY if
● the policy has been previously reviewed
● policy/artifact has not been changed
■ refuse to activate and notify, if
● policy has not been reviewed and accepted
● policy/artifact has been
updated/changed/compromised
● Proposed Goldeneye release deliverables
○ user-specified security policy
e.g. Virtual network access control

46. ONOS Application Load-balancing [1/2]
Project Name: ONOS Application Load-balancing
Contact: soumiya.toshio@jp.fujitsu.com / hikichi.kenji@jp.
fujitsu.com / akikoo@jp.fujitsu.com
Summary: Dynamic apps load-balancing by changing the
policy of external load balancer and network event queue
based on the load of apps and instances.
Falcon Proposals:
(1)Apps and instances load collector
(2)Notification mechanism to external load balancer
(3)Utility for network event queue

47. ONOS Application Load-balancing [2/2]

48. Instructions to the contributor
1. Add your name and topic onto one of the agenda slides
(the one for presentations if you plan to present, or the
one for info if you do not)
2. Add at least one slide to the deck - the template slide -
feel free to add other slides or provide links to more
information in Jira, Wiki, etc
3. If you are not able to attend and you have material, it
would be nice for you to create a short video
presentation of your slides that people can watch - just
put the link into this presentation.

49. Template Slide
Project name and main contact
Proposed Falcon Deliverables
● deliverable 1
● deliverable 2...
Proposed Goldeneye release Deliverables
● deliverable 1
● deliverable 2…
Areas where you would like community help
List of Jira tickets or a description