The current implementation of BngProgrammable for fabric.p4 uses
attachment IDs as line IDs, thus forcing apps such as bngc to be aware
of such implementation detail and to manage the allocation of such IDs.
Unfortunately, allocation of IDs is dependent on the device (P4 program)
implementation (e.g., line counter size), and so it should not be left
to apps.
This patch removes the need for attachment IDs at all and instead relies
on a driver-level service to dynamically allocate line IDs based on the
attachment attributes (currently s-tag, c-tag, mac address).
The current implementation of the allocation logic is a trivial one,
i.e. non-distributed and non-optimized.
Change-Id: Ie960936ee750cf565b8de41370085ecf9d49e931
(cherry picked from commit 6aa2a6ea743e8104ee3c62acb7d26acbd1452614)
For Arista switch, the following code is required
because the port to be used as OpenFlow bridge should be added.
Change-Id: Id73560b9c9592838ba91329ef652742fb1beb65b
Setup of an attachment won't trigger counters clean up
Change-Id: I6be72bdedb71bbc6152e8192ec4614a2f812b014
(cherry picked from commit e12d0ea7f3a7590a30c282294e83f7978bda914b)
- BngProgrammable interface moved to ONOS core
- BngProgrammable implementation in fabric pipeliner
Change-Id: Ia020d19f305d8819eef7f70453b14cb00fd31af8
(cherry picked from commit 8fd75e7352d12c9ad90b8461a9550d8f7e1b263d)
criteria to EAPOL trap flows.
* Adding purgeOnDisconnect property to MeterManager
* DeviceListener implementation on MeterManager
* Adding purgeMeter(DeviceId deviceId) method to MeterStore
* Calling the above method when DEVICE_AVAILABILITY_CHANGE is received
* Adding vlanId match criteria to EAPOL trap flows (OltPipeline change)
Change-Id: Ibb254302efe94edf1fd596f74a6eef6587410475
(cherry picked from commit 91b38543d822a0d9d092f9b3ff7760b1a206226a)
ApplicationService is not available. For example, when using the ONOS CLI:
onos> apps -s -a
Service org.onosproject.app.ApplicationService not found
The issue seems to be a circular dependency, as ApplicationManager depends on CoreService, but CoreManager depends on ApplicationService.
Reverting for now.
This reverts commit 35ef3d3000f8b19608531dfd06f8e78482c45b32.
Change-Id: I298c3c7844df7f2395e092fbb89a8e9264883094
This patch is based on patch#21952, which shows optical details in ONOS GUI.
The emulator could be pulled via "docker pull onosproject/oc-cassini:latest".
Currently, there are still some questions unresolved:
1. The power values defined in PowerConfig.java are long, but the values defined in yang should be float.
2. In PowerConfig.java, I need to rename method **currentPower** to **currentOutputPower**.
3. In PowerConfig.java, the **default** in method definition is used to avoid the effect on all implemented class.
This condition should be changed finally.
Change-Id: If5a3ec77d9a906718b80531afa67bc67388bca4f
Added support for flowrules coming from the compilation of an OpticalConnectivityIntent.
FlowRules coming from ROADM app are still supported.
Minor updates to DeviceDiscovery and PowerConfig.
Patch 2: Driver and OpticalPathIntent support for partner-ports.
Now bidirectional intents can be configured also in presence of unidirectional links.
ROADM app visualizes devices of type TERMINAL_DEVICE and partner port details.
Checkstyle.
Patch 3: [ONOS-7974] [ONOS-79076] partner-port renamed to reverse-port. Bug fix.
Addressed comments by Ramon Casellas and Andrea Campanella. Checkstyles.
Patch 4: documentation.
Patch 5: addressed comments by Andrea Campanella.
Patch 6: checkstyle.
Change-Id: Ie5ca41eee6cb6f8f87f076f2af19c99cadd6d851
Without waiting for the next pipeconf watchdog periodic probe.
To support this, this patch extends the PiPipeconfService to advertise
pipeconf registration events.
Change-Id: Ib44f1813bd37083c666a5e7980de320ce469c2d2
Such as mapping from PiMatchFieldId to Criterion.Type. This should not
be required since the only translation happening is from north
(Criterion.Type) to south (PiMatchFieldId).
Change-Id: I204e0bd66b3996fd60bc11d4241e8a0408e11582
Clone sessions can now be created by defining groups with new type CLONE
The PI framework has been refactored to abstract commonality between
multicast groups and clone sessions as both are managed as part of the
P4Runtime packet replication engine (PRE).
Change-Id: I2f23c629b7de1931d5cab96ec76aef26130ce418
This change introduces a refactoring of the gRPC protocol subsystem that
allows the creation of a gRPC chanel independently of the client, while
allowing multiple clients to share the same channel (e.g. as in Stratum
where we use 3 clients).
Moreover, we refactor the P4RuntimeClient API to support multiple
P4Runtime-internal device ID using the same client. While before the
client was associated to one of such ID.
Finally, we provide an abstract implementation for gRPC-based driver
behaviors, reducing code duplication in P4Runtime, gNMI and gNOI drivers.
Change-Id: I1a46352bbbef1e0d24042f169ae8ba580202944f
1. Handled the case when InternalNetworkConfigListener in DeviceManager recieves an event associated with PortAnotationConfig class.
2. Added CONFIG_REMOVED event type in InternalNetworkConfigListener in DeviceManager.
3. Changed comine function in PortAnnotationOperator to take care of removing old annotations from PortDescription which are not in current
PortAnnotationConfig.
Tested using 'annotate-ports' command and 'ports' command
Change-Id: Ie4d2b529c2f559a40a296d916193318e0ccc7b93
- Workaround for PI bug that ignores max_group_size
- Use max_group_size and not buckets size when translating groups
Change-Id: Id12a12311b20ca8fb4e785e1c5a4f0f4215d1bbf
This is achieved by optimistically updating the P4Runtime mirror using
the write request (instead of waiting for a response) and by serializing
building write requests for the same device.
This change requires updating the P4Runtime protocol classes to expose
the content of the write request.
It also includes:
- force member weight to 1 when reading groups (some server
implementation still fails to be compliant to the spec)
- remove unused operation timeout handling in GDP (now all RPCz have a
timeout)
Change-Id: Ib4f99a6085c1283f46a2797e0c883d96954e02e9
This (big) change aims at solving the issue observed with mastership flapping
and device connection/disconnection with P4Runtime.
Channel handling is now based on the underlying gRPC channel state. Before,
channel events (open/close/error) were generated as a consequence of P4Runtime
StreamChannel events, making device availability dependent on mastership. Now
Stream Channel events only affect mastership (MASTER/STANDBY or NONE when the
SteamChannel RPC is not active).
Mastership handling has been refactored to generate P4Runtime election IDs that
are compatible with the mastership preference decided by the MastershipService.
GeneralDeviceProvider has been re-implemented to support in-order
device event processing and to reduce implementation complexity. Stats polling
has been moved to a separate component, and netcfg handling updated to only
depend on BasicDeviceConfig, augmented with a pipeconf field, and re-using the
managementAddress field to set the gRPC server endpoints (e.g.
grpc://myswitch.local:50051). Before it was depending on 3 different config
classes, making hard to detect changes.
Finally, this change affects some core interfaces:
- Adds a method to DeviceProvider and DeviceHandshaker to check for device
availability, making the meaning of availability device-specific. This is needed
in cases where the device manager needs to change the availability state of a
device (as in change #20842)
- Support device providers not capable of reconciling mastership role responses
with requests (like P4Runtime).
- Clarify the meaning of "connection" in the DeviceConnect behavior.
- Allows driver-based providers to check devices for reachability and
availability without probing the device via the network.
Change-Id: I7ff30d29f5d02ad938e3171536e54ae2916629a2
Allows to provide a different input port to be considered when emitting
the packet. It is useful on OpenFlow devices so one can use ALL or FLOOD
actions as output and not have the packet sent back on the input port.
Default is controller port, as it was before.
The required changes were also implemented in OpenFlowPacketProvider
Change-Id: I0a050b983b5de9935254599e8093dc59ad7a4ccf
- OchSignal constructor
- unfiltered connect point methods in single point to multi point intents
- useBackup() method from disjoint paths
- ChannelAdapter class
- getLastUpdatedInstant() method from cluster store
- switchWorkingPath() method from protection config behaviour
- getVersion() method from partition
- getFlowRulesById() method from flow rule service
Change-Id: I5c6c2f31725f7e7e44ac2abb18ce3fb96b09d93e
