mbox series

[net-next,v3,0/9] net: bridge: cfm: Add support for Connectivity Fault Management(CFM)

Message ID 20201006145338.1956886-1-henrik.bjoernlund@microchip.com
Headers show
Series net: bridge: cfm: Add support for Connectivity Fault Management(CFM) | expand

Message

Henrik Bjoernlund Oct. 6, 2020, 2:53 p.m. UTC
Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.

Connectivity Fault Management (CFM) comprises capabilities for detecting, verifying,
and isolating connectivity failures in Virtual Bridged Networks.
These capabilities can be used in networks operated by multiple independent organizations,
each with restricted management access to each other’s equipment.

CFM functions are partitioned as follows:
    — Path discovery
    — Fault detection
    — Fault verification and isolation
    — Fault notification
    — Fault recovery

The primary CFM protocol shims are called Maintenance Points (MPs).
A MP can be either a MEP or a MHF.
The MEP:
    -It is the Maintenance association End Point
     described in 802.1Q section 19.2.
    -It is created on a specific level (1-7) and is assuring
     that no CFM frames are passing through this MEP on lower levels.
    -It initiates and terminates/validates CFM frames on its level.
    -It can only exist on a port that is related to a bridge.
The MHF:
    -It is the Maintenance Domain Intermediate Point
     (MIP) Half Function (MHF) described in 802.1Q section 19.3.
    -It is created on a specific level (1-7).
    -It is extracting/injecting certain CFM frame on this level.
    -It can only exist on a port that is related to a bridge.
    -Currently not supported.

There are defined the following CFM protocol functions:
    -Continuity Check
    -Loopback. Currently not supported.
    -Linktrace. Currently not supported.

This CFM component supports create/delete of MEP instances and configuration of
the different CFM protocols. Also status information can be fetched and delivered
through notification due to defect status change.

The user interacts with CFM using the 'cfm' user space client program,
the client talks with the kernel using netlink.

Any notification emitted by CFM from the kernel can be monitored in user space
by starting 'cfm_server' program.

Currently this 'cfm' and 'cfm_server' programs are standalone placed in a cfm
repository https://github.com/microchip-ung/cfm but it is considered to integrate
this into 'iproute2'.

v2 -> v3
    The switchdev definition and utilization has been removed as there was no
    switchdev implementation.
    Some compiling issues are fixed as Reported-by: kernel test robot <lkp@intel.com>.

Henrik Bjoernlund (9):
  net: bridge: extend the process of special frames
  bridge: cfm: Add BRIDGE_CFM to Kconfig.
  bridge: uapi: cfm: Added EtherType used by the CFM protocol.
  bridge: cfm: Kernel space implementation of CFM.
  bridge: cfm: Kernel space implementation of CFM.
  bridge: cfm: Kernel space implementation of CFM.
  bridge: cfm: Netlink Interface.
  bridge: cfm: Netlink Notifications.
  bridge: cfm: Bridge port remove.

 include/uapi/linux/cfm_bridge.h |  70 +++
 include/uapi/linux/if_bridge.h  | 125 +++++
 include/uapi/linux/if_ether.h   |   1 +
 include/uapi/linux/rtnetlink.h  |   2 +
 net/bridge/Kconfig              |  11 +
 net/bridge/Makefile             |   2 +
 net/bridge/br_cfm.c             | 882 ++++++++++++++++++++++++++++++++
 net/bridge/br_cfm_netlink.c     | 731 ++++++++++++++++++++++++++
 net/bridge/br_device.c          |   4 +
 net/bridge/br_if.c              |   1 +
 net/bridge/br_input.c           |  31 +-
 net/bridge/br_mrp.c             |  19 +-
 net/bridge/br_netlink.c         | 138 ++++-
 net/bridge/br_private.h         |  76 ++-
 net/bridge/br_private_cfm.h     | 147 ++++++
 15 files changed, 2205 insertions(+), 35 deletions(-)
 create mode 100644 include/uapi/linux/cfm_bridge.h
 create mode 100644 net/bridge/br_cfm.c
 create mode 100644 net/bridge/br_cfm_netlink.c
 create mode 100644 net/bridge/br_private_cfm.h

Comments

Nikolay Aleksandrov Oct. 6, 2020, 3 p.m. UTC | #1
On Tue, 2020-10-06 at 14:53 +0000, Henrik Bjoernlund wrote:
> Connectivity Fault Management (CFM) is defined in 802.1Q section 12.14.

> 

> Connectivity Fault Management (CFM) comprises capabilities for detecting, verifying,

> and isolating connectivity failures in Virtual Bridged Networks.

> These capabilities can be used in networks operated by multiple independent organizations,

> each with restricted management access to each other’s equipment.

> 

> CFM functions are partitioned as follows:

>     — Path discovery

>     — Fault detection

>     — Fault verification and isolation

>     — Fault notification

>     — Fault recovery

> 

> The primary CFM protocol shims are called Maintenance Points (MPs).

> A MP can be either a MEP or a MHF.

> The MEP:

>     -It is the Maintenance association End Point

>      described in 802.1Q section 19.2.

>     -It is created on a specific level (1-7) and is assuring

>      that no CFM frames are passing through this MEP on lower levels.

>     -It initiates and terminates/validates CFM frames on its level.

>     -It can only exist on a port that is related to a bridge.

> The MHF:

>     -It is the Maintenance Domain Intermediate Point

>      (MIP) Half Function (MHF) described in 802.1Q section 19.3.

>     -It is created on a specific level (1-7).

>     -It is extracting/injecting certain CFM frame on this level.

>     -It can only exist on a port that is related to a bridge.

>     -Currently not supported.

> 

> There are defined the following CFM protocol functions:

>     -Continuity Check

>     -Loopback. Currently not supported.

>     -Linktrace. Currently not supported.

> 

> This CFM component supports create/delete of MEP instances and configuration of

> the different CFM protocols. Also status information can be fetched and delivered

> through notification due to defect status change.

> 

> The user interacts with CFM using the 'cfm' user space client program,

> the client talks with the kernel using netlink.

> 

> Any notification emitted by CFM from the kernel can be monitored in user space

> by starting 'cfm_server' program.

> 

> Currently this 'cfm' and 'cfm_server' programs are standalone placed in a cfm

> repository https://github.com/microchip-ung/cfm but it is considered to integrate

> this into 'iproute2'.

> 

> v2 -> v3

>     The switchdev definition and utilization has been removed as there was no

>     switchdev implementation.

>     Some compiling issues are fixed as Reported-by: kernel test robot <lkp@intel.com>.

> 


Well, funny timing. :) I just finished reviewing v2 half an hour ago. All of my
comments for v2 apply for this v3 set, sorry but you'll have to fix a few more
issues.

Thanks,
 Nik