A VC is a Layer 2 construct with sub-interfaces on each end, defined by VLANs. In the current ECX implementation, the VC is provisioned as part of a larger solution when the provider has specified a Layer 2 service profile—unlike with other components, a user cannot currently define one independently (this will come later). Therefore, any Layer 2 connection to a Layer 2 service profile automatically includes a VC.
Encapsulations supported: 802.1Q (TPID: 0x8100) and 802.1ad (TPID: 0x8100, 0x88a8, 0x9100). The TPID on the frames sent to ECX on the A-side must match the value specified when the port is ordered. In the case of QnQ this value (TPID) is on the outer tag while the inner tag uses 0x8100.
The TPID on the frames sent to ECX on the A-side must match the value specified when the port was ordered. In the case of Q-in-Q this value (TPID) is on the outer tag while the inner tag uses 0x8100, regardless of what was specified.
ECX can “translate” between A and Z sides of a VC so that each side can have whatever VLAN ID and encapsulation each side needs (except where specifically noted below).
Buyers can set up multiple Layer 2 VCs and connectors in a given metro, on a single or multiple ECX ports, at their discretion and the business rules imposed by their administrator.
Although no single VC or connector can exceed the size of the port or port group it resides on, the ECX will allow users to provision multiple VCs and connectors in which the aggregate rate limit is greater than the size of the ports they reside on. While this will not result in dropped traffic by itself, the combined actual and simultaneous usage of all the services could cause drops, and the ECX SLA is only valid up to the capacity of the ports. Customers are responsible for management of their traffic patterns and usage.
Implementation example: User has a single 1G port and has provisioned two services to two separate providers (Blue for 100M, Orange for 500M), and a primary and secondary 500M service to Green that requires redundancy. If the primary and secondary VCs are set to active/active, and all services are sending the maximum amount of traffic, customer may experience random packet drops