Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
...
| Table of Contents | ||
|---|---|---|
|
Contributors
| Name | Organization | Role | |
|---|---|---|---|
| Konstantinos Kanonakis | Huawei Technologies | Developer | konstantinos.kanonakis@huawei.com |
| Francesco Lucrezia | Politecnico di Torino / CREATE-NET | Developer | francesco.lucrezia@gmail.com |
Overview
This page provides a brief description of the Carrier Ethernet application (CE app). The CE app can be used to install and manage MEF-defined Carrier Ethernet services, along with relevant components like UNIs and Bandwidth Profiles (BW profiles). It is noted that the application is still under active development.
Prerequisites
The application is included in the ONOS applications for CORD repository (please follow the instructions from here to be found in onos-app-samples and has a dependency on the metro app from the same repository. clone and build it) and can be activated from the ONOS CLI as follows:
| Code Block |
|---|
onos> app activate org.onosproject.ecord.carrierethernet |
| Warning |
|---|
Note that the |
...
| Code Block |
|---|
| onos> app activate org.onosproject. ecord.metro onos> app activate org.onosproject.ecord.carrierethernet |
Classes
CarrierEthernetManager.java: Performs CE service validation, installation (if possible) and removal. The validation part checks whether there are enough resources to accommodate the UNIs (i.e. their associated BW profiles) comprising the CE service request. The UNIs that cannot be accommodated are omitted from the service request. Then, depending on the CE service type, the service may or may not be validated. For example the validation will fail if the ROOT UNI of a RootROOT_MultipointMULTIPOINT service is omitted. Service installation involves iterating through the service UNIs and establishing packet and optical connectivity via appropriate method calls.
CarrierEthernetServiceCarrierEthernetVirtualConnection.java: Represents a CE service Ethernet Virtual Connection (EVC) including the associated set of UNIs (and BW profiles) and the service type. There are three types of CE servicesEVCs: PointPOINT_ToTO_PointPOINT, MultipointMULTIPOINT_ToTO_MultipointMULTIPOINT and RootROOT_MultipointMULTIPOINT. Currently VLAN-based connectivity across the Carrier Ethernet Network (CEN) is supported, hence each service EVC is associated with a globally unique VLAN ID which is automatically generated by the CE app. A unique service EVC id is also generated by the application upon service creation using a format which indicates the service EVC type, whether is it virtual, as well as the VLAN ID used by it.
...
It should be noted that currently the class can be used to denote either a UNI from the service EVC point of view (in which case only a single BW profile may be present) or a so-called "global" UNI. For the first type of UNIs (which will be referred to as “service“EVC" UNIs), a type attribute (ROOT or LEAF) is used to indicate the role of the UNI within the CE serviceEVC. On the other hand, global UNIs exist independently of service UNIs and may include one or more BW profiles of the same type (with the exception of the INTERFACE type, of which they can have only one). There is an 1-1 mapping between service EVC and global UNIs and the association is achieved by using the UNI id attribute which is globally unique and corresponds to the relevant connect point (“<DeviceId>/<Port>”).
Note that in the current CE app implementation, global UNIs also include information regarding their available and used BW capacity – the latter updated with each BW profile addition or removal.
CarrierEthernetPacketProvisionerCarrierEthernetProvisioner: Manages connectivity across the packet network domain, including the selection of link paths and appropriate method calls from CarrierEthernetPacketNodeManager.java to establish forwarding and apply bandwidth profiles on network nodes.
CarrierEthernetPacketNodeManager.java: Abstract class used to control packet nodes across the CEN according to their control protocol and the type of CEN connectivity. In the current implementation it is extended by the CarrierEthernetOpenFlowPacketNodeManager.java class which assumes OpenFlow switch nodes and VLAN-based forwarding.
CE
...
EVC Examples
The figure below provides an example to clarify the usage of the aforementioned classes:
It is assumed that three CE services EVCs have been established between devices of:0000000000000001 and of:0000000000000002. There is one Ethernet Private Line (EPL) service EVC (EP-Line-1) between UNI of:0000000000000001/1 (i.e. port 1 of device of:0000000000000001) and UNI of:0000000000000002/1 and two EVPL services EVCs (EVP-Line-2 and EVP-Line-3) between between UNI of:0000000000000001/2 and UNI of:0000000000000002/2.
VLAN IDs 1, 2 and 3 respectively are used to accomplish forwarding between of:0000000000000001 and of:0000000000000002 for the three services EVCs across the CEN. In the case of EP-Line-1, untagged frames arriving at of:0000000000000001/1 would have VLAN tag 1 pushed to them and subsequently popped upon their arrival at of:0000000000000002/3. For EVP-Line-2 and EVP-Line-3, tags 2 and 3 respectively would be pushed on top of the existing CE-VLAN tags 100 and 200 included in the customer traffic arriving at of:0000000000000001/2.
As shown in the figure, the services EVCs maintain their own set of service EVC UNIs, each service EVC UNI being associated with exactly one BW profile. However, each of the four global UNIs aggregates information from all individual service EVC UNIs, i.e. points to all BW profiles associated with the relevant connect point. It can also be seen that it is possible for different UNIs belonging to the same service EVC to have different CIR/CBS and EIR/EBS values.
...
A simple Command Line Interface has been implemented to facilitate CE service management. The Some of the commands currently supported are the following:
ce-serviceevc-create: Used to either install a new CE service EVC or update an already installed one. The user needs to provide a configuration id, however the actual (unique) service EVC id is automatically generated by the application as mentioned above and can be obtained using the ce-serviceevc-list command. The type of the CE service EVC also needs to be provided, along with a set of two or more UNIs. For simplicity the command can only receive one bandwidth profile which is subsequently applied to all service EVC UNIs. The –v option, if used, indicates the CE-VLAN ID also to be applied to all service EVC UNIs. If a CE-VLAN ID is present, the service EVC is considered to be a “virtual” one (e.g. EVPL). If the –id option is used with the id of an already installed serviceEVC, the application will keep the existing service EVC id, but will re-install the service EVC using the newly provided parameters.
Using the example above, service EVP-Line-2 could be installed using the CLI as follows:
| Code Block |
|---|
onos> ce ce-serviceevc-create –v-v 100 –c-c 300 –cbs-cbs 2000 evpl1 PointPOINT_ToTO_PointPOINT of:0000000000000001/2 of:0000000000000002/2 |
ce-serviceevc-remove: Used to remove an installed CE service EVC and all the associated resources.
ce-serviceevc-remove-all: Used to remove all installed CE servicesEVCs.
ce-serviceevc-list: Provides a list of all installed CE services EVCs along with detailed information about each of them (i.e. service EVC UNIs and BW profiles).
ce-uni-list: Provides a list of all potential global UNIs in the network. Any connect point (i.e. combination of device and port) is a potential global UNI if (1) it is not used by a device-device link and (2) the associated port is currently active.
...