This driver allows connection to the Microsemi Edge Assure 1000 SFP-NID EdgeAssure 1000 Product Page
The User Guide for this product is available on request from Microsemi, and gives a full explanation of the theory of operation, functionality and how all functions can be accessed through the NETCONF interface only.
Currently only a subset of it's functionality is supported through ONOS, but this will expand to full functionality in future releases.
Currently this driver is built using BUCK and uses version 2.1 of onos-yang-tools
All that is required to activate the driver is to run the following at the ONOS CLI
onos:app activate org.onosproject.drivers.microsemi
This will load any dependent apps also. To verify the driver has been loaded run the command
onos:apps -a -s
Connection timeouts need to be increased from default values when using EA1000. At ONOS command line run
onos:cfg set org.onosproject.netconf.ctl.impl.NetconfControllerImpl netconfConnectTimeout 50 onos:cfg set org.onosproject.netconf.ctl.impl.NetconfControllerImpl netconfReplyTimeout 50
EA1000 Devices will not be automatically discovered at present in ONOS. They have to be created through the network/configuration REST interface in ONOS.
{ "devices": { "netconf:192.168.56.10:830": { "netconf": { "username": "admin", "password": "admin", "ip": "192.168.56.10", "port": 830, "connect-timeout": 50, "reply-timeout": 50, "idle-timeout": 40 }, "basic": { "driver": "microsemi-netconf", "type": "SWITCH", "manufacturer": "Microsemi", "hwVersion": "EA1000" } } } }
When the EA1000 is configured and connected is should be visible in ONOS through the devices command.
onos> devices id=netconf:192.168.56.10:830, available=true, local-status=connected 33s ago, role=MASTER, type=SWITCH, mfr=Microsemi, hw=EA1000, sw=4.4.0-53-generic, serial=Eagle Simulator., driver=microsemi-netconf, ipaddress=192.168.56.10, latitude=51.8865467, locType=geo, longitude=-8.4040440, name=netconf:192.168.56.10:830, port=830, protocol=NETCONF
Note how the
In addition the time on the device is checked at this stage, and if it wrong by more than 1 day (it defaults to 1-1-1970 on startup if no NTP server is configured), then the current time is written to it at this stage. This will persist on the device until next reboot.
Also the ports of the device will be visible after connection. There are 2 ports
onos> ports
id=netconf:192.168.56.10:830, available=true, local-status=connected 15s ago, role=MASTER, type=SWITCH, mfr=Microsemi, hw=EA1000, sw=4.4.0-53-generic, serial=Eagle Simulator., driver=microsemi-netconf, ipaddress=192.168.56.10, latitude=51.8865467, locType=geo, longitude=-8.4040440, name=netconf:192.168.56.10:830, port=830, protocol=NETCONF
port=0, state=enabled, type=fiber, speed=1000, portName=Optics
port=1, state=enabled, type=copper, speed=1000, portName=Host
Currently the EA1000 supports only a limited set of OpenFlow rules through the Flows REST API and the Flow Objective API.
A feature of the EA1000 that may be configured through Flow Rules is IP Source Address Filtering. This can only be activated on Port 0 (the optics Port). An example of this kind of flow is
POST /onos/v1/flows/ HTTP/1.1
{ "flows": [ { "priority": 50000, "timeout": 0, "isPermanent": true, "deviceId": "netconf:192.168.56.10:830", "tableId": 8, "treatment": { "instructions": [ {"type": "NOACTION"} ], "deferred": [] }, "selector": { "criteria": [ {"type": "IPV4_SRC", "ip": "192.168.8.0/24"}, {"type": "IN_PORT", "port": "0"} ] } } ] }
Note: Before Vlan Tag manipulation can be done the mode of the interface on the EA1000 has to be changed to be compatible with the type of tags that are being received. If this is not done, once an EVC is created the packets that have the Vlan tagged on will be treated as untagged by EA1000, and dropped if there is no EVC present corresponding to the interface PVID. See the section below on the "Setting EA1000 Interface Tagging Mode"
Flows that Push, Pop or Overwrite VLAN tags are implemented in EA1000 and are treated as MEF Carrier Ethernet EVCs. Both CTags and STags can be pushed on to matching Ethernet packets at network Layer 2.
POST /onos/v1/flows/ HTTP/1.1
{ "flows": [ { "priority": 50000, "timeout": 0, "isPermanent": true, "tableId": 6, // This sets the EVC id - this first flow is configuring the customer side - UNI-C "deviceId": "netconf:192.168.56.10:830", "treatment": { "instructions": [ { "type": "L2MODIFICATION", "subtype": "VLAN_PUSH", // This pushes a VLAN on "ethernetType": "0x88a8" // The pushed VLAN type is QinQ }, { "type": "L2MODIFICATION", "subtype": "VLAN_ID", "vlanId": "200" // The pushed VLAN id is 200 }], "deferred": [] }, "selector": { "criteria": [ { "type": "VLAN_VID", "vlanId": "100" // Applies only to packets already tagged with VLAN 100.. }, { "type": "IN_PORT", "port": "1" // ...that are coming in on the Host port }] } }, { "priority": 50000, "timeout": 0, "isPermanent": true, "tableId": 6, // The same EVC, but now we are configuring another VLAN "deviceId": "netconf:192.168.56.10:830", "treatment": { "instructions": [ { "type": "L2MODIFICATION", "subtype": "VLAN_PUSH", // Push again "ethernetType": "0x88a8" // QinQ again }, { "type": "L2MODIFICATION", "subtype": "VLAN_ID", "vlanId": "200" // VLAN 200 again }], "deferred": [] }, "selector": { "criteria": [ { "type": "VLAN_VID", "vlanId": "101" // Applies only to packets already tagged with VLAN 101.. }, { "type": "IN_PORT", "port": "1" // ... that are coming in on the Host port }] } }, { "priority": 50000, "timeout": 0, "isPermanent": true, "tableId": 6, // The same EVC, but now we are configuring the opposite side "deviceId": "netconf:192.168.56.10:830", "treatment": { "instructions": [ { "type": "L2MODIFICATION", "subtype": "VLAN_POP" // Here we are popping the top level tag }], "deferred": [] }, "selector": { "criteria": [ { "type": "VLAN_VID", // Applies only to packets tagged with VLAN 200 "vlanId": "200" }, { "type": "IN_PORT", "port": "0" // That are coming in on the Optics Port }] } } ] }
The Interface of the EA1000 has an attribute frame_format that must be set to either:
For instance if Port 0 of an EA1000 is to receive and process S-Tags, the the frame-format of the interface eth0 should be set to stag in advance.
This should be made a permanent setting in the NETCONF startup datastore, so that it will be active if the device reboots.
Likewise the opposite port should be set to ctag.
This changes are not made done through the ONOS Driver, and currently only possible to make this change through a NETCONF CLI client such as yangcli-pro or netopeer-cli;
See the EA1000 User Guide for details on how to use yangcli-pro to access the EA1000.
On an EA1000 accessed through yangcli-pro the following commands can be used to make these changes:
admin@192.168.2.234> discard-changes admin@192.168.2.234> copy-config source=startup target=candidate admin@192.168.2.234> merge /interfaces/interface[name='eth0']/frame-format --value='stag' admin@192.168.2.234> merge /interfaces/interface[name='eth1']/frame-format --value='ctag' admin@192.168.2.234> commit admin@192.168.2.234> copy-config source=running target=startup
The ONOS Carrier Ethernet application allows EVCs to be created between UNIs that are linked together in ONOS. This is translated down to OpenFlow switches by converting the ce-evc-create commands in to Flow Rules similar to those shown above.
While EA1000 is not an OpenFlow switch, it's driver can convert these flows in to NETCONF which can be used to configure EVCs on the EA1000. Because EA1000 is just a 2 port device it represents only 1 UNI (conventionally on switches each port represnts a UNI).
When an EA1000 device is configured in ONOS the Carrier Ethernet Application considers both of its ports to be UNIs, as can be seen in the listing below:
onos> ce-uni-list
CarrierEthernetUni{id=netconf:192.168.56.10:830/0, cfgId=netconf:192.168.56.10:830/0, role=null, refCount=0, ceVlanIds=[], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[]}
CarrierEthernetUni{id=netconf:192.168.56.10:830/1, cfgId=netconf:192.168.56.10:830/1, role=null, refCount=0, ceVlanIds=[], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[]}
This mismatch is handled in the driver - both side appear to be separate here but they will apply to the same single UNI on the EA1000 in opposite directions.
For an EVC to be created there has to an ONOS 'link' between 2 UNIs for a POINT-TO-POINT connection - an Ethernet Virtual Private Line (EVPL). There has to be more than 2 UNIs to create a MULTIPOINT-TO-MULTIPOINT link - an E-Lan.
In a simple scenario that has 2 EA1000s (netconf:192.168.56.10:830 and netconf:192.168.56.20:830) configured in ONOS, the two might be linked together through their optics ports (port 0). The following result is expected for a bi-directional link:
onos> links src=netconf:192.168.56.10:830/0, dst=netconf:192.168.56.20:830/0, type=DIRECT, state=ACTIVE, expected=false src=netconf:192.168.56.20:830/0, dst=netconf:192.168.56.10:830/0, type=DIRECT, state=ACTIVE, expected=false
This will not exist by default since Link Discovery is not yet a feature of the EA1000 driver. These have to be created manually - through the network/configuration REST API.
POST /onos/v1/network/configuration/ HTTP/1.1
{ "links": { "netconf:192.168.56.10:830/0-netconf:192.168.56.20:830/0": { // 10 to 20 "basic" : { "type" : "DIRECT" } }, "netconf:192.168.56.20:830/0-netconf:192.168.56.10:830/0" : { // and reverse "basic" : { "type" : "DIRECT" } } } }
To create a simple EVPL the following command can be used at the ONOS CLI:
onos>ce-evc-create --cevlan 101 evpl1 POINT_TO_POINT netconf:192.168.57.10:830/0 netconf:192.168.57.20:830/0
This returns without any message. Tailing through the ONOS logs will reveal any error that might have occurred.
This EVC can be viewed only through the command line:
onos> ce-evc-list
CarrierEthernetVirtualConnection{id=EP-Line-1, cfgId=evpl1, type=POINT_TO_POINT, state=ACTIVE,
UNIs=[
CarrierEthernetUni{id=netconf:192.168.56.10:830/0, cfgId=netconf:192.168.56.10:830/0, role=Root, refCount=0, ceVlanIds=[101], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[CarrierEthernetBandwidthProfile{id=FC-1, type=EVC, cir=0.0, cbs=0, eir=0.0, ebs=0}]},
CarrierEthernetUni{id=netconf:192.168.56.20:830/0, cfgId=netconf:192.168.56.20:830/0, role=Root, refCount=0, ceVlanIds=[101], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[CarrierEthernetBandwidthProfile{id=FC-1, type=EVC, cir=0.0, cbs=0, eir=0.0, ebs=0}]}],
FCs=[CarrierEthernetForwardingConstruct{id=FC-1, cfgId=null, type=POINT_TO_POINT, vlanId=1, metroConnectId=null, refCount=1,
LTPs=[
CarrierEthernetLogicalTerminationPoint{id=netconf:192.168.56.10:830/0, cfgId=netconf:192.168.56.10:830/0, role=Root, ni=CarrierEthernetUni{id=netconf:192.168.56.10:830/0, cfgId=netconf:192.168.56.10:830/0, role=Root, refCount=0, ceVlanIds=[101], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[CarrierEthernetBandwidthProfile{id=FC-1, type=EVC, cir=0.0, cbs=0, eir=0.0, ebs=0}]}}, CarrierEthernetLogicalTerminationPoint{id=netconf:192.168.56.20:830/0, cfgId=netconf:192.168.56.20:830/0, role=Root, ni=CarrierEthernetUni{id=netconf:192.168.56.20:830/0, cfgId=netconf:192.168.56.20:830/0, role=Root, refCount=0, ceVlanIds=[101], capacity=1000000000, usedCapacity=0.0, bandwidthProfiles=[CarrierEthernetBandwidthProfile{id=FC-1, type=EVC, cir=0.0, cbs=0, eir=0.0, ebs=0}]}}]}]}
This creates a set of flows in ONOS that are pushed down to the two EA1000s through NETCONF to configure the EVCs
onos> flows
deviceId=netconf:192.168.56.10:830, flowRuleCount=2
id=71000050d21dd5, state=ADDED, bytes=0, packets=0, duration=0, liveType=UNKNOWN, priority=50000, tableId=1, appId=org.onosproject.ecord.carrierethernet, payLoad=null, selector=[IN_PORT:0, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[VLAN_POP], deferred=[], transition=None, meter=None, cleared=false, metadata=null} # This represents ingress on the Optics port 0 on device A and POPs off the S-Tag
id=710000b5c1f057, state=ADDED, bytes=0, packets=0, duration=0, liveType=UNKNOWN, priority=50000, tableId=1, appId=org.onosproject.ecord.carrierethernet, payLoad=null, selector=[IN_PORT:1, VLAN_VID:101], treatment=DefaultTrafficTreatment{immediate=[VLAN_PUSH:qinq, VLAN_ID:1], deferred=[], transition=TABLE:0, meter=None, cleared=false, metadata=null} # This represents ingress on the Host port 1 on device A and pushes on the S-Tag 1
deviceId=netconf:192.168.56.20:830, flowRuleCount=2
id=710000613c8252, state=ADDED, bytes=0, packets=0, duration=0, liveType=UNKNOWN, priority=50000, tableId=1, appId=org.onosproject.ecord.carrierethernet, payLoad=null, selector=[IN_PORT:0, VLAN_VID:1], treatment=DefaultTrafficTreatment{immediate=[VLAN_POP], deferred=[], transition=None, meter=None, cleared=false, metadata=null} # This represents ingress on the Optics port 0 on device B and POPs off the S-Tag 1
id=7100006ca2573f, state=ADDED, bytes=0, packets=0, duration=0, liveType=UNKNOWN, priority=50000, tableId=1, appId=org.onosproject.ecord.carrierethernet, payLoad=null, selector=[IN_PORT:1, VLAN_VID:101], treatment=DefaultTrafficTreatment{immediate=[VLAN_PUSH:qinq, VLAN_ID:1], deferred=[], transition=TABLE:0, meter=None, cleared=false, metadata=null} # This represents ingress on the Host port 1 on device B and pushes on the S-Tag 1
Through these flows it's clear that the CE-VLAN on the UNI-C side is 101 and that the S-Tag that is being pushed on is VLAN 1. Packets coming back in on the UNI-N on port 0 have their S-Tag popped off. In this scenario this will create evc-1 on both of the EA1000s.
On the actual EA1000 itself using a NETCONF CLI Client like yangcli-pro, the result is:
admin@192.168.56.10> sget-config /mef-services/uni source=running
rpc-reply {
data {
mef-services {
uni { # There is only one UNI on the EA1000
name Uni-on-192.168.56.10:830 # Automatically assigned
evc 1 { # From the VLAN 1 from CE app
evc-index 1
name EVC-1 # Automatically assigned
evc-per-uni {
evc-per-uni-c { # The UNI-C side
ce-vlan-map 101 # Could be a range of values
flow-mapping {
ce-vlan-id 101
flow-id 31243725464268887 # For tracking with ONOS
}
ingress-bwp-group-index 0 # No meters
tag-push { # Push on an a VLAN
push-tag-type pushStag # Push type is S-TAG
outer-tag-vlan 1 # Push value is 1
}
}
evc-per-uni-n { # For the UNI-N side
ce-vlan-map 1 # The VLAN to match for egress on this side
flow-mapping {
ce-vlan-id 1
flow-id 31243723770830293
}
ingress-bwp-group-index 0
tag-pop { # Pop off the S-TAG
}
}
}
}
}
}
}
}
admin@192.168.56.10>
** Note: The meters created by Carrier Ethernet are not compatible with Open vSwitch at present.They will disrupt the configuration of the EA1000 if there are Open VSwitch based OpenFlow switches between the UNIs **
To create limits on how the EVPL can transport data the CIR, EIR and CBS and EBS values can be specified:
onos> ce-evc-create --cevlan 102 -c 400 -e 200 -cbs 3000 -ebs 2000 evpl2 POINT_TO_POINT netconf:192.168.56.10:830/0 netconf:192.168.56.20:830/0
These will be created as meters in Open Flow.
onos> meters
DefaultMeter{device=netconf:192.168.56.20:830, id=1, appId=org.onosproject.ecord.carrierethernet, unit=KB_PER_SEC, isBurst=true, state=PENDING_ADD, bands=[DefaultBand{rate=50000, burst-size=3000, type=REMARK, drop-precedence=0}, DefaultBand{rate=75000, burst-size=5000, type=DROP, drop-precedence=null}]}
DefaultMeter{device=netconf:192.168.56.10:830, id=1, appId=org.onosproject.ecord.carrierethernet, unit=KB_PER_SEC, isBurst=true, state=PENDING_ADD, bands=[DefaultBand{rate=75000, burst-size=5000, type=DROP, drop-precedence=null}, DefaultBand{rate=50000, burst-size=3000, type=REMARK, drop-precedence=0}]}
EVCs can be deleted individually with ce-evc-remove or all together with ce-evc-remove-all.
EA1000 supports both Connectivity Fault Management (CFM) and MEF Services OAM. This is achieved through the EA1000 driver supporting the ONOS behaviors CfmMepProgrammable and SoamDmProgrammable described in Layer 2 Monitoring with CFM and Services OAM.
With EA1000 the CFM entities (Maintenance Association Endpoints or MEPs) are created in parallel with the EVC services that they are designed to test, and related loosely to each other only through VLAN ID. For instance an EVC might be created with a VLAN of 101, and separately a Maintenance Association would be created with the same VLAN ID, and MEPs created under this for monitoring that VLAN (and by inference that EVC).
The CFM interface to ONOS is exposed through a REST API at /onos/cfm In ONOS Maintenance Domains and Maintenance Associations beneath them are created and persisted in a distributed datastore. These are logical entities that can span across an ONOS cluster and are not directly related to devices.
The Maintenance Association Endpoint - MEP (the child of the Maintenance Association, and grandchild of the Maintenance Domain) is also a logical entity but has a hard many:1 association to a device that supports the CfmMepProgrammable behaviour. EA1000 is one such device, and so one to many MEPs can be associated with an EA1000 device.
For example to create an Maintenance Domain in ONOS the following might be POSTed to POST http://localhost:8181/onos/cfm/md HTTP/1.1
{"md": { "mdName": "Microsemi", "mdNameType": "CHARACTERSTRING", "mdLevel": "LEVEL3", "mdNumericId": 1 } }
To create a Maintenance Association under this POST http://localhost:8181/onos/cfm/md/Microsemi/ma HTTP/1.1
{ "ma": { "maName": "ma-vlan-1", "maNameType": "CHARACTERSTRING", "maNumericId": 1, "ccm-interval": "INTERVAL_1S", "component-list": [ { "component": { "component-id":"1", "tag-type": "VLAN_STAG", "vid-list": [ {"vid":1} ] } } ], "rmep-list": [ { "rmep":10 }, { "rmep":20 }, { "rmep":30 } ] } }
To create a MEP under this: POST http://localhost:8181/onos/cfm/md/Microsemi/ma/ma-vlan-1/mep HTTP/1.1
{ "mep": { "mepId": 10, "deviceId": "netconf:10.205.86.26:830", "port": 0, "direction": "DOWN_MEP", "primary-vid": 1, "administrative-state": true, "ccm-ltm-priority": 4, "cci-enabled" :true } }
When the MEP is created a configuration is written down to the EA1000 device at 10.205.86.26 through NETCONF roughly in the format:
<maintenance-domain> <id>1</id> <name>Microsemi</name> <name-type>CHARACTER_STRING</name-type> <md-level>3</md-level> <maintenance-association> <id>1</id> <name>ma-vlan-1</name> <name-type>CHARACTER_STRING</name-type> <component-list> <tag-type>vlan-stag</tag-type> <vid>1</vid> </component-list> <remote-mep>10</remote-mep> <remote-mep>20</remote-mep> <remote-mep>30</remote-mep> <maintenance-association-endpoint> <mep-identifier>10</mep-identifier> ... </maintenance-association-endpoint> </maintenance-association> </maintenance-domain>
There are a few things to note here: