Skip to main content

System Requirements Specification (SRS)

Project: Layer 2 Data Center Extender (L2 DCE)

Version: 1.0
Date: 29/04/2025
Author: Mesut Bayrak

1. Introduction

1.1 Purpose

Describe the purpose of the L2 DCE system (e.g., extend VLANs across data centers with low latency).

1.2 Scope

Define what the L2 DCE will and will not do.

1.3 Definitions, Acronyms, and Abbreviations

  • L2 DCE – Layer 2 Data Center Extender
  • VXLAN – Virtual Extensible LAN
  • DC – Data Center
  • BGP EVPN – Border Gateway Protocol Ethernet VPN
  • MAC – Media Access Control

1.4 References

List applicable RFCs, whitepapers, standards.

1.5 Overview

Brief description of document structure.

2. Overall Description

Main purpose of the device is to provide a transparent Layer-2 connectivity between two separate sites.

2.1 Product Perspective

Device can have two distinct operational units to be located in two sites. One central unit (an aggragator), and one (or more) remote site unit(s).

Central unit is intended to be located in a data-center facility with proper power and cooling.

Remote side units are intended to be located inside out-of-reach facilities, via some rental or sale agreement.

Describe how L2 DCE fits into the current system (optional: diagram).

2.2 Product Functions

Function Definition:

    Device will be Ethernet (802.3) based only. Extend Layer 2 VLANs transparently.transparently between two sites which has only IPv4 connectivity in between. SupportThe dynamicdata transfer in between the two sites must be encrypted. Device will have two deterministic functional zones: WAN side (where the connection between sites are) and LAN side (where the VLANs to be carried over will be defined). Device will not learn and/or filter any Ethernet MAC learning.addresses on either side. EnsureDevice will not interfere, or contribute to any loop prevention.prevention algorithms (like spanning tree, SLPP, etc) so that it will not require any extra configuration on any connected devices. Any measures of loop prevention will be handled outside of the device context. ProvideDevice must provide a mechanism for high availability mechanism. HA of ports on each side, HA of particular hardware conponents like power supplies, HA of the device itself will be described further as addendum Device must be able to perform VLAN number translation, at least on the central site. Device will have no OSI Layer-3 interaction with the transferred VLANs (example: Device will have no ip addresses and lowwill latency.not need an IP address on the transferred VLANs). If WAN side has Jumbo frames available, system should allow for higher MTU on LAN side. For regular (1500bytes) MTU on WAN side, LAN side will be restricted with .... bytes MTU size (will be decided based on encap method selected)

    Operational Definition:

      Deivce must have a Lights-Out Management facility in case it loses all configuration, or not able to boot. Configuration of Central unit can be done using a menu based script or GUI Basic connectivity configuration (ip address, subnet mask, defgw, dns server) of remote site unit can be done by a menu based script (startup/and or runnable bash script). Main configuration of remote site will be downloaded from central site once connectivity is established. Remote site device must be able to be altered in configuration, and able to be rebooted from the central side.

      2.3 User Characteristics

      • UsersTwo types of users: System administrators and consumers.
      Sys Admins are network engineers familiar with Layer 2/3 concepts. Consumer has no access to the device, or maybe max read-only

      2.4 Constraints

      • Jumbo frame support required.
      Latency and failover constraints.

      2.5 Assumptions and Dependencies

      • MPLS/IP backbone in place.
      • Network hardware supports VXLAN, EVPN, ECMP.

      3. Specific Requirements

      3.1 Functional Requirements

      ID Requirement Description
      FR-1 VLAN Extension Extend VLANs 1–4094.
      FR-2 MAC Learning Dynamic MAC learning support.
      FR-3 Control Plane Use BGP EVPN or similar.
      FR-4 Failover Failover within 1s.
      FR-5 MTU Handling Minimum MTU 9100 bytes.
      FR-6 Loop Prevention No Layer 2 loops without relying on STP.

      3.2 Non-Functional Requirements

      ID Requirement Description
      NFR-1 Availability 99.99% uptime.
      NFR-2 Scalability Support 10,000+ MAC addresses.
      NFR-3 Performance Latency increase < 2ms one-way.
      NFR-4 Security MAC filtering, ARP inspection.
      NFR-5 Manageability SNMP, Netconf, RESTCONF integration.

      4. Interface Requirements

      4.1 Hardware Interfaces

      • Ethernet interfaces (1G, 10G, 25G, 40G, 100G).
      • VXLAN Tunnel Endpoints (VTEPs).

      4.2 Software Interfaces

      • Standard Linux network stack compatibility.
      • API access (gRPC, REST).

      4.3 Communication Interfaces

      • VXLAN over UDP.
      • MP-BGP EVPN over TCP (Port 179).

      5. Performance Requirements

      • Max bandwidth: [e.g., 40 Gbps per VTEP].
      • Max link utilization: 80%.
      • Failover convergence time: < 1 second.

      6. Security Requirements

      • Optional IPsec/MACsec encryption.
      • Anti-spoofing: Source MAC/IP validation.
      • Role-Based Access Control (RBAC) for management.

      7. Other Requirements

      • Compliance with security standards (e.g., ISO 27001).
      • Appliance power limits (e.g., <300W).

      8. Appendix

      • Network diagrams.
      • Failover flowcharts.
      • Supported hardware/software matrix.
      Back to top