Have questions? Stuck? Please check our FAQ for some common questions and answers.

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Table of Contents

Contributors

NameOrganizationRoleEmail
Konstantinos KanonakisHuawei TechnologiesDeveloperkonstantinos.kanonakis@huawei.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 to be found in onos-app-samples and has a dependency on the newoptical app from the ONOS repository. Note that the fwd app and/or any other apps which involve switch forwarding should be deactivated, since they may interfere with the operation of the CE app. The app can be activated from the ONOS CLI as follows:

onos> app activate org.onosproject.newoptical
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 ROOT_MULTIPOINT service is omitted. Service installation involves iterating through the service UNIs and establishing packet and optical connectivity via appropriate method calls.

CarrierEthernetService.java: Represents a CE service including the associated set of UNIs (and BW profiles) and the service type. There are three types of CE services: POINT_TO_POINT, MULTIPOINT_TO_MULTIPOINT and ROOT_MULTIPOINT. Currently VLAN-based connectivity across the Carrier Ethernet Network (CEN) is supported, hence each service is associated with a globally unique VLAN ID which is automatically generated by the CE app. A unique service id is also generated by the application upon service creation using a format which indicates the service type, whether is it virtual, as well as the VLAN ID used by it.

CarrierEthernetBandwidthProfile.java: Represents an ingress UNI BW profile and includes relevant attributes like Committed Information Rate (CIR), Committed Burst Size (CBS), Excess Information Rate (EIR) and Excess Burst Size (EBS). There are three possible types of BW profiles: INTERFACE, EVC, COS.

A BW profile is always associated with a UNI and it is noted that the BW profile id needs to be unique only in the context of a single UNI. For example, the EVC BW profiles at each UNI of an Ethernet Virtual Private Line (EVPL) both use the EVPL’s id as an identifier for themselves, although they may have different attributes.

CarrierEthernetUni.java: Represents a UNI and includes relevant attributes like the associated BW profiles and CE-VLAN IDs.

It should be noted that currently the class can be used to denote either a UNI from the service 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" UNIs), a type attribute (ROOT or LEAF) is used to indicate the role of the UNI within the CE service. 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 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. 

CarrierEthernetPacketProvisioner: 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 Service Examples

The figure below provides an example to clarify the usage of the aforementioned classes:

 

 

It is assumed that three CE services have been established between devices of:0000000000000001 and of:0000000000000002. There is one Ethernet Private Line (EPL) service (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 (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 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 maintain their own set of service UNIs, each service UNI being associated with exactly one BW profile. However, each of the four global UNIs aggregates information from all individual service 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 to have different CIR/CBS and EIR/EBS values.  

Using the CLI

A simple Command Line Interface has been implemented to facilitate CE service management. The commands currently supported are the following:

ce-service-create: Used to either install a new CE service or update an already installed one. The user needs to provide a configuration id, however the actual (unique) service id is automatically generated by the application as mentioned above and can be obtained using the ce-service-list command. The type of the CE service 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 UNIs. The –v option, if used, indicates the CE-VLAN ID also to be applied to all service UNIs. If a CE-VLAN ID is present, the service is considered to be a “virtual” one (e.g. EVPL).  If the –id option is used with the id of an already installed service, the application will keep the existing service id, but will re-install the service using the newly provided parameters.

Using the example above, service EVP-Line-2 could be installed using the CLI as follows:

 ce-service-create -v 100 -c 300 -cbs 2000 evpl1 Point_To_Point of:0000000000000001/2 of:0000000000000002/2

ce-service-remove: Used to remove an installed CE service and all the associated resources.

ce-service-remove-all: Used to remove all installed CE services.

ce-service-list: Provides a list of all installed CE services along with detailed information about each of them (i.e. service 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.  

It is noted that the –-help option can be used with any of the aforementioned commands in order to obtain more information regarding their usage.

Contact

For further information, clarifications or comments please feel free to contact the developer.

  • No labels