More explict handling of versatile forwarding flows in corsa driver.
Moving TunnelConnectivityManager to use flowObjectives instead of flowRules.
Change-Id: If43023f30a6e7a028dfdefbe1ffbcc710a1c7be3
1.merge private flow into regular flowrule subsystem.no mirror code any
more.no change flowrule api.
2.define a rich-data-type to carry private flow.
3.modify OpenFlowRuleProvider.class to support for 3rd party private
flow.i don't know whether is suitable.because this class name is
relative with open flow protocal.
4.fix some junit test bug caused by modification of FlowRule interface.
Change-Id: I6c54d1e97f231a75bd1b416f0893e0379613d7ce
Provides an abstraction which isolates the application from any pipeline
knowledge. By using the provided objectives applications can express
their forwarding desires in a pipeline agnostic way. The objectives
are then consumed by a driver for the specific device who converts them
into the appropriate pipeline coherent flows.
Change-Id: I74a68b4971c367c0cd5b7de9d877abdd117afa98
- Any files created in 2014 and modified in 2015 got a copyright of
2014-2015
- Used canonical form of 2014-2015 to be inclusive of extra years.
Some files had 2014,2015
Change-Id: If9a133618873e4000b8f10299bde7c870eb1fbd5
There is no physical gateway in SDN network.
However a host needs a gateway when it tries to communicate with a remote host.
So we designed a virtual gateway for SDN network.
The virtual gateway can have multiple IP addresses.
Each IP address is used as the default gateway address of an IP prefix.
We only configure one MAC address to the virtual gateway.
You can choose any MAC address from the BGP speakers as the virtual gateway MAC address.
We configure this MAC address staticly in the sdnip.json configuration file.
Change-Id: I2a72bef797fc55d25bb5473e8fca624ad659e1d1
- ICMP/ARP/IP handlers are implemented as a part of the application for now
- Default routing and link add/failure/recovery are also supprted
- Temporary NetworkConfigHandler, which is hardcoded to support only 6 router FISH topology, is used for test
- Some fixes on GroupHanlder app to support transit routers
- Supports multi-instance (tested with two instances)
Change-Id: Idfa67903e59e1c4cac4da430f89cd4c50e821420
This module can handle 3 cases:
(1) one host wants to talk to another host, both two hosts are in SDN network.
(2) one host in SDN network wants to talk to another host in Internet.
(3) one host from Internet wants to talk to another host in SDN network.
In all cases, we use MultiPointToSinglePointIntent.
Change-Id: I80dd954bd608e52b45b993f3c27e67636a7105d9
apps now support -a|--active option to show only activated apps.
app command now takes a list of app ids to allow single command to activate/deactivate/uninstall multiple apps
Deprecated old CLI commands which were already not included in the run-time config.
Consolidated intent & topology metrics to use the same app id since they are bundled into the same app.
Added 'reinstall' and 'reinstall!' option to onos-app tool.
Change-Id: I1406843bf608acf8e7d969a547b929d056e77067
Requires restart of any dev shell sessions that may have KARAF_VERSION=3.0.2 already set.
Developers that have their own local Karaf will have to run 'onos-setup-karaf <ip-address>' command
Change-Id: Iba234b3cd5af89de6dd249c97cac97525364cc34
- Each connectivity intent now has only one constructor
- Intent constructors are now private for leaf classes and
protected for classes that can be derived from
- Each intent class has a Builder class that accumulates
parameters for intent creation
- Each intent class has a public static builder() method
to create a builder
- Each Builder class has a build() method to create the
intent from the accumulated parameters
- Added keys to a few intent types that were missing them
- Tightened up usage of checkNotNull(), taking advantage of
the return value to save some lines of code
- Modified callers to use the builders instead of directly
calling the constructors
Change-Id: I713185d5ecbadbf51f87ef7f68fec41102106c78
Added another metric to the onos-app-metrics-topology application
to collect and display the number and rate of the Reasons for the
Topology Events.
Example:
onos> topology-events-metrics
...
Topology Graph Event Timestamp (ms from epoch)=1426699861509
Topology Graph Events count=6 rate(events/sec) mean=0.002315 m1=0.000000 m5=0.000004 m15=0.000378
Topology Graph Reasons Event Timestamp (ms from epoch)=1426699861509
Topology Graph Reasons Events count=9 rate(events/sec) mean=0.003472 m1=0.000000 m5=0.000005 m15=0.000567
The corresponding object names in the JSON output are:
topologyGraphReasonsEventRate
topologyGraphReasonsEventTimestamp
Change-Id: Ib1aeb83c38b3b72d0ae8a4f49bc1e14badc0199d
