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
Addressed a few issues found while using the flow objectives across a cluster:
* Flow objectives should be installable from any node, not just the master.
Therefore we need to ensure all nodes initialize a driver for each switch.
* We no longer store a list of objectives that are waiting for the switch
to arrive. If the we don't know about the switch yet we'll try a few times
over a few seconds to find it, but after that we'll give up and report an
error to the client.
* Default drivers need to be available when the FlowObjectiveManager starts
up, otherwise it is common to get flow objective requests before any
drivers have been loaded.
Change-Id: I1c2ea6a223232402c31e8139729e4b6251ab8b0f
1)Initial Work for ONOS-676: OTN/ROADM (L1/L0 NE) support in ONOS by extending the device/port modeling;
- extending device type to include L1 OTN NEs;
- extending port type to include ODUCLT port(T-port), OCH-port(L-port), OMS-port (WDM-port);
- more standard annotations related to OTN/ROADMs support will come from PCEP provider as well as TL1 providers;
2)Intial Work for ONOS-1276: generic Tunnel subsystem in ONOS for both packet (L3/L2) networks and optical (L1/L0) networks
- supporting PCEP framework, which is capable of interacting with the PCEP provider;
- supporting any other kind of tunnel provider;
- each Tunnel is associated with at least two Labels (abstracted logical entity/Id for virtualization of physical port);
- same type of Tunnels can be formed as a reachablity graph for other services and NB applications use;
Change-Id: I29af495f90e179e2c5d8753b76e02889a3b4355b
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
- Avoid NPE when a component has no configurable property or doesn't exist
- Specificly use a numeric value for SharedExecutors.DEFAULT_POOL_SIZE so
the value appears in cfg command
- Also use print instead of system.err since it is being redirected
away from the console
Change-Id: Ib73016b1a9282493f0c5c8c217dd33292eac4ba4
Change-Id: Ib2abb483456538e3e08e9790c4b4b0d50db8b384
implemented a distributed default flow registration mechanism to avoid
duplicate requests from other onos instances
Change-Id: I620cc51ac29cddaffa73cdbb20e9a9acbdd9ea69
- add test to be sure that all flows are removed when intents
are withdrawn
- add test to be sure that all flows are removed when an intent
installation fails. Currently disabled, intent cleanup is
not implemented
- enable installation time out test
Change-Id: I8c7a75292a97404ef89856647c67ef2f70ffcf6f
However, there is a race that can temporarily break data plane connectivity.
The problem is described in ONOS-1404
Change-Id: I3df1948180b42fc7f4c2d072bd8c2b452dd07e61
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
It resolves naming mismatch in naming of IntentProcessPhases and states
handled in the phases. It is described in ONOS-1064.
- Define FlowRuleIntent that enables flow rule level operation
as an intent.
- Remove IntentInstaller interface
- Existing installable intents such as PathIntent, LinkCollectionIntent,
OpticalPathIntent and MplsPathIntent now become non installable intents.
Only FlowRuleIntent is categorized as installable intent now.
- Implement intent compilers for PathIntent, LinkCollectionIntent,
OpticalPathIntent and MplsPathIntent. They generates FlowRuleIntents.
- Write unit tests for the newly created intent compilers according to
the intent installers' unit tests
- Remove all intent installers and their unit tests
Change-Id: I22d6c7acb65a4c066145de0018bd0727f44bd54a
- 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
This problem needs to be fixed in a better way.
This reverts commit 8317ad56e8c5dc6b8c5fadf3d87a51f885c8dfa2.
Change-Id: Icbc4492016a0858221a3e79121db36cbb87b3b2b
