EVC Type

Defines the service type:

• Point-to-Point
• Multipoint-to-Multipoint
• Rooted-Multipoint

Note that the UNI attributes determine whether the service is a private service or a virtual private service.

EVC ID

An arbitrary string - unique across the CEN – for the EVC supporting the service instance.

UNI List

The UNI List for an EVC is a list of pairs of the form <UNI Identifier, UNI Type>. One pair per UNI is associated with a particular EVC. UNI Type can be Root or Leaf. For EVC types of Point-to-Point or Multipoint-to-Multipoint, it must be Root.

L2CP Requirements for EVPL

Maximum Number of UNIs

Any integer ≥ 2 is allowed. It must be 2 for Point-to-Point EVC.

EVC Maximum Transmission Unit Size

EVC MTU Size must be less than or equal to the UNI MTU size. It must be at least 1522 bytes in order to support the maximum size of a standard IEEE 802.3 frame with a C-Tag. When an ingress frame larger than the MTU arrives at the EVC, the SLS is not applied. The result of the bandwidth profile is not defined. Note that such a frame may be dropped but could also be delivered to the EVC.

In some cases the subscriber would require a larger MTU in order to support the delivery of specific applications. For example, FCoE (Fiber Channel over Ethernet) provides connectivity between devices that have a Fiber Channel interface. These devices have MTU of 2,000 bytes. With the addition of an Ethernet header, the required MTU is closer to 2,100 bytes.

Another example would be a financial application, where the source and/or destination uses an FDDI interface. FDDI is based on IEEE 802.4 and the maximum frame size is 4,352 bytes. So the MTU for such a service would need to be about 4,400 bytes. It should be noted that in order for the service provider to carry such large frames, its transport network would need to support this large MTU in its switches and routers. Not all networking devices support these frame sizes.

Frame Delivery

The frame delivery rules enable the service provide to specify how different frame types are to be handled. They enable setting specific rules for forwarding, discarding, or conditionally forwarding specific frame types.

For example: Broadcast frames from a LAN could be blocked over the CEN in order to save bandwidth.

Any Data Service Frame (Service frame that is NOT L2CP) is subject to the delivery rule. There are three rules:

1. Unicast Service Delivery
2. Multicast Service Delivery
3. Broadcast Service Delivery

Each Data Service Frame is classified to be Unicast, Multicast or Broadcast based on its MAC DA.

There are three values for Frame Delivery.

1. Discard - Allows for example, the blocking of Broadcast on a given EVC.
2. Deliver Unconditionally – All ingress frames are delivered to the egress UNI(s)
3. Deliver Conditionally – Must specify the exact rule. For example, deliver based on learning bridge.

(Note that some frames are always discarded, for example frames with an invalid FCS, frames that are policed as red, frames that are larger than the MTU, etc.).

A Frame Delivery value is set for each of the three data frame types.

For an EPL, all three types must be set to Deliver Unconditionally.

This is defined in order to provide the high transparency required for this service type.

Preservation

An EVC can be set to preserve the CE-VLAN ID and CE-VLAN CoS from ingress to egress. This is required when the subscriber is using the VLAN header information between its locations.

For example, if the subscriber's LAN uses VLANs in order to separate departments (e.g. VLAN ID 4 denotes engineering while VLAN ID 6 denotes marketing), such VLAN ID values MUST be identical after crossing the CEN in order not to break the Layer 2 applications. In such a scenario, the subscriber would require preservation from the service provider. See the picture at right.

There are two Per EVC Attributes:

• CE-VLAN ID Preservation – Yes, or No
• CE-VLAN CoS Preservation – Yes, or No

A EVC with CE-VLAN ID Preservation = Yes must preserve the CE-VLAN for service frames as follows:

• If All-to-One bundling is Enabled , then preservation applies to all Ingress service frames.
• If All-to-One bundling is Disabled , then preservation applies to tagged Ingress service frames having CE-VLAN ID
  1 through 4094.

In some cases, the service may be set to perform CE-VLAN Translation. In other words, changing the CE-VLAN ID between ingress and egress UNIs. This is easily implemented with routers but could be challenging using switches. Note that translation is always bi-directional. In example at right, ingress frames at UNI A have CE-VLAN ID 37, when the egress at UNI B is assigned CE-VLAN ID 156.

CE-VLAN CoS Preservation means that the PCP bits in the CE-VLAN tag of the egress frame are identical to those of the ingress frame that yielded this egress service frame.

CE-VLAN ID Preservation and CE-VLAN CoS Preservation must be set to Yes for all private services (EPL, EP-LAN and EP-Tree)

CoS ID based on PCP Value

L2CP Handling

EVC L2CP handling per protocol can be set to:

• Discard – Drop the frame
• Peer – Participate in the protocol towards the CE.
• Tunnel – Pass to the egress UNI

Since most of the L2CP protocols are carried using untagged frames, it is a challenge to tunnel these frames when virtual services are supported. For example, with Spanning Tree, tunneling may mean that these frames will not reach all the bridges and thus the service may be affected.

Peering is common for LACP (if the UNI is a link aggregation group) and E-LMI (which is effective on the UNI) and occasionally for LLDP. For virtual private services the Subscriber can also request that the Service Provider peer spanning tree.

The table at right specifies the L2CP processing requirements for EVPL service. The first column identifies the standard protocol, and the second column identifies the MAC DA used to carry that protocol data unit. The third column specifies the required action, and the fourth column specifies the applicability - i.e. whether the action taken must be the same at all UNIs in the EVC, or the action taken can be different on different UNIs in the EVC.

For EPL, the expectation is that L2CP frames are tunneled. (Note that PAUSE is discarded in all cases).

Class of Service ID

The CoS ID (Class of Service Identifier) of a Service Frame defines the service treatment, optionally bandwidth profile and optionally performance objectives.

CoS ID can be derived by one of the following mutually exclusive options:

Per EVC

All frames entering a particular EVC will be set to a given CoS ID. This is the appropriate approach if there is only one class of service on the EVC.

By PCP values

In this case, the map of PCP to CoS ID MUST include all possible values (0 through 7) with no overlap. Untagged frames are mapped to the same CoS ID as Data Service Frames with PCP=0. The example at right shows a Service Multiplexed UNI with two EVCs, EVC_1 and EVC_2, and Class of Service determined for each one by PCP value.

DSCP

 In this case, the Class of Service Identifier for an ingress Data Service Frame containing an IP packet is determined by the EVC and non-overlapping sets of values of the DSCP. The union of the sets of DSCP values must contain all of the possible DSCP values. Data Service Frames not containing an IP packet and mapped to a given EVC shall have the same Class of Service Identifier with a value agreed upon by the Subscriber and the Service Provider.

L2CP

This option is not mutually exclusive with the previous three. Any L2CP protocol that is tunneled through this EVC can be set to a different defined CoS ID. For example, the three-CoS model specified in MEF 23 suggest the following mapping: High – PCP 5 Medium – PCP 2, 3 Low – PCP 0, 1 (note: this includes untagged frames as they are mapped together with priority tagged frames). PCP 6 and 7 can be mapped to another, non-standard CoS ID.