Highly transparent E-Line CPE – S5700

Having worked with carriers for many years, we have been tasked with evaluating and engineering CPEs for different service types. Services according to Metro Ethernet Forum (MEF) and the like are still very popular, for many customers they appear to be a very simple and easy-to-use solution. I am not starting a discussion here why it might be a bad idea to simply stretch LAN’s across locations. As customers tend to insist on MEF services however, we do our best to enable our customer to offer competitive and service-rich services to their customers.

Let’s focus here on a E-Line service. As per definition, this is a point-to-point topology. On top of an existing MPLS network, it is very simple to provision that kind of services. Many people expect E-Line services to be something very comparable with an optical Ethernet service, meaning it simply accepts every frame and sends it to the other side of the circuit. This might be the case for most of the traffic, however, there are exceptions.

This transparency is possible to a very high grade from the perspective of the attachment circuits of the MPLS Provider Edge routers. To provide a well-defined service access point on the customer location, many carriers put some Layer 2 CPE to the customers site. This means by default that those devices would start doing MAC learning as well as processing Layer 2 control protocols (L2CP). From a carriers perspective, L2CP frames from the customer must not be processed on the CPE. That kind of frames are sent to the (usually pretty powerless) CPU. In addition, the customers expect L2CP frames to be transmitted across the entire service.

L2CP are sent to specific multicast mac addresses, which would be received the peer device in a point-to-point topology. Vendors often offer some flexibility regarding L2CP. In many implementation one can choose whether to process such frames, drop or forward them, or even tunnel them with a different destination MAC address. The variety of L2CP is often limited to a specific and limited set of protocols. In our engineering work over the past few years, we verified the behaviour of many different switches in this function. For those tests, we usually used packeth as a very powerful packet generator. Whereas some devices just match protocols by destination address, there are others that also match on ethertype or dsap/ssap. Some even inspect the payload of such a frame and try to validate whether it is really a valid protocol frame.

We had consistent customers‘ requirements for protocols like STP or any of its brothers, LACP, CTP/LLDP, UDLD and others. Recently, a rising requirement is MACSEC. This protocol enables the customer to encrypt the traffic across the service. MACSEC relies on EAPOL, which is also considered an L2CP. There are many CPEs which do not provide the possibility to forward or encapsulate the required frames for MACSEC. From a carriers perspective, it is important to have devices which can adapt quickly to new protocols.

Huawei went this way with their S5700 Series. There is already a large set of predefined protocols which can simply be activated. However, there is a possibility to add custom protocols. They are matched in their configuration with the destination MAC address and the ethertype or dsap/ssap for 802.3 and Ethernet II respectively. By default, the frames destination will be rewritten to the well-known Cisco Multicast MAC Address 0100-0ccd-cdd0, however, even this transport address can be specified.

Even the smallest device of S5700 Series, the fan-less S5700-10P-LI-AC, offers this functionality, among with common features like dot1q-tunnel and the like.

Having two SFP slots and eight 10/100/1000Mbps ports, this device is very competitive priced and a very efficient fit as a Layer 2 CPE. We had cases where the CAPEX of this box was 10% of its precursor (really meaning a reduction of 90%), even with additional offered flexibility. If you wish more information or a specific offer, do not hesitate and contact us.