1. LACP Project Proposal

2. Introduction
LACP is the IEEE specification that defines a protocol used to bundle multiple switch links into single logical interface to provide link redundancy and bandwidth aggregation.
LACP protocol plugin is used to discover the ‘redundant connectivity’ between the edge switches outside of controller domain connected to the fabric and switches within the fabric that is managed by the controller.
LACP protocol is implemented as a MD-SAL service and it uses MD-SAL “packet-processing” service to transmit and receive the LACP control packets.
LACP plugin will install a catch-all flow entry whenever a switch is connected to the controller so that switch can redirect the LACP control packets to the controller.
LACP protocol plugin uses MD-SAL ‘flow-node’ service APIs to install flow entries and group entries within the switch.

3. LACP control Packet Flow
LACP plugin will transmit LACP control packets on all the active external ports at regular intervals.
LACP module registers itself as listener for “Packet Received” notification and it will process the LACP BPDU packets received through these notifications.
Each LACP control packet will be processed by LACP port state machines like RX machine, selection logic, MUX state machine.
Selection logic will identify a group member ports for an aggregator and invokes MUX state m/c to update the link aggregator.
MUX state m/c updates the aggregator membership and will use the ‘sal-flow-service’ APIs to add a group table entry to create a port channel within the switch.

4. LACP protocol state machines
Description
Receive Machine
This state machine receives LACPDUs from the Partner, records the information contained, evaluates the incoming information from the Partner to determine whether the Actor and Partner have both agreed upon the protocol information exchanged to the extent that the port can now be safely used, either in an aggregation with other ports or as an individual port; if not, it asserts NTT in order to transmit fresh protocol information to the Partner.
Periodic Transmission machine
This state machine determines whether the Actor and its Partner will exchange LACPDUs periodically in order to maintain an aggregation (periodic LACPDU exchanges occur if either or both are configured for Active LACP).
Selection Logic Machine
The Selection Logic is responsible for selecting the Aggregator to be associated with this port. All the ports within a system that have the same operational LACP Key are aggregated as single aggregator, except for the ports are configured as ‘Individual’ (ports that are configured to be not aggregated).
MUX Machine
This component is responsible for attaching the port to a selected Aggregator, detaching the port from a de- selected Aggregator, and for turning collecting and distributing at the port on or off as required by the current protocol information.
TX Engine
This component the transmission of LACPDUs, both on demand from the other state machines, and on a periodic basis.
LACP Flow Utils
This component provide service to transform Link Aggregation requests to SAL flow service requests.

5. LACP Component Diagram

6. LACP YANG files YANG FILE Description lacp-types.yang
Contains types defined within LACP module like mux-state, RX-state and TX-state etc.
lacp-system.yang
Defines the system-wide variables for LACP module like fast-periodic-time, slow-periodic-time etc.
lacp-node.yang
Defines LACP node specific entities LACP system-id, system-priority etc.
lacp-port.yang
Define LACP port specific properties like port priority, actor/partner admin and operational properties.
lacp-aggregator.yang
Defines LACP aggregator specific properties like MAC address, admin/operational key, receive/transmit states.

7. Open flow plugin dependency
LACP plugin will depend on southbound protocol plugin “open flow” to create the ‘port channel’ in side the switch.
There are two approaches on creating the port channel within the switch.
Use Open flow Group Entry Modify State message to create a group entry of group type “select”.
Use Open flow extension framework (Experimenter message), but this option cannot be standardized across different vendors.
LACP plugin will use ‘Group Modify’ message to create the port channel in lithium release. Port channel creation using open flow extension frame work is not scoped for lithium release
LACP module will be used only to form port channels only on the ‘external ports’. LACP messages received on internal ports will be dropped.
Open flow plugin might be used to do physical port to logical port translation while processing packet-in messages.

8. Logical port translation within Open flow plugin
Upon receiving packet-in message, open flow plugin will translate the ingress port to logical port and updates the ingress port with logical port except for the following packets.
LACP control packets
LLDP control packets
If open flow plugin translates the ingress port, applications just see the logical port as any other node connector.
Applications will install flows with “logical port” as the out put port. When open flow plugin receives a flow modify message, it will modify the action to point to the group ID that corresponds to logical port.
If a new member port is added to an aggregator, flows corresponding to the port are supposed to be flushed. But applications may not get update if open flow plugin flushes the flows.

9. Open flow Switch Behavior
Open flow enable switch will create a port channel upon processing the “Group Modify State” message with group type ‘selection’ and “output port” action.
Open flow switch might optionally represent port channel as a logical port and inform the controller about newly created logical port.
If open flow switch creates a logical port corresponding to port channel, it will have to respond to “Group Query” message with member ports as part of “Group Description Reply” message.
If controller sends a “packet-out” message with a logical port as output port, controller will send the packet through the corresponding port channel.
Open flow plugin after receiving new logical port description, message optionally query the switch with “Group Query” message get the logical port to physical port mapping.

10. Packet Processing Impact
When open flow plugin receives a packet-in message, it will have the physical port as ingress port, even if it is part of a port channel.
Applications which program the flows or track the host to fabric edge port mapping will have to use “logical port” instead of physical port.
There are two approaches on where this translation can happen.
Each application that needs to handle logical ports will do the translation.
With this approach each application supposed to have the logical port to physical port mapping.
When a new member is added to logical port, application will take care of flushing the flows associated with member port.
South-bound protocol plugin (open flow) will do the translation and updates the ingress port within ‘packet-in’ message with logical port.

11. Interaction with other modules
With the approach where in each application translates the physical port to logical port, the following modules need to be updated.

12. Data Packet Flow