article continued from page 1

The provisioning steps are the same as those required for configuring a regular Ethernet interface on a VPLS instance. Let us assume that a VPLS instance is already configured in the gateway PE – PE 1 – with at least a network IP/MPLS tunnel and one Ethernet interface as a service interface. Next, the user specifies an ATM VC as a second ingress VPLS service interface and configures the slot/port/VPI/VCI identifying it.

Next, an ATM traffic descriptor should be configured and applied to the ATM VC. The user specifies the ATM traffic parameters, the ATM service category, and enables such functions as ATM policing and shaping.

Once an AAL5 PDU is reassembled by the ATM segmentation and reassembly sublayer (SAR) at the ingress ATM port in PE 1, the contained Ethernet frame is extracted. Ingress classification of the Ethernet frames received on an ATM VC allows the user to filter the received frames based on both MAC and IP criteria. An example of a MAC match criterion is the match on the 802.1 p field or a match on the source or destination MAC address field. An example of an IP match criterion is a match on the differentiated services code point (DSCP) field or a match on the source IP address field in the header of an IP packet inside the Ethernet frame. Frames that match a specified criterion can be directed to a separate forwarding class queue dedicated to this ATM VC as configured in the ingress QoS policy. Frames that did not match any of the configured criteria will be queued in the default forwarding class queue assigned to this VC as specified in the ingress QoS policy.

Frames that are received from the IP/MPLS network port are classified based on the EXP field in the shim header of the label stack.

An important aspect of providing a VPLS service over an ATM VC is the ability to achieve the desired QoS objectives for the service. When Ethernet frames are sent over an ATM VC in PE 1, the scheduling of data becomes hierarchical with two main levels: packet level scheduling and per-VC cell level scheduling.

At the first level, frames are queued on a per-CoS (or forwarding class), per-VC basis in order to achieve the proper class of service differentiation for the frames in the same VC. Each Ethernet frame is queued based on the VC dedicated forwarding class queue, as configured in the ingress classification profile. The packet level scheduling can make use of a hierarchy in order to enforce aggregate bandwidth among a group of queues feeding an ATM VC or to enforce aggregation of bandwidth across all queues of all VCs at a given customer site.

At the second level, the segmented cells are queued in per-VC queues according to the configured ATM service category and the traffic descriptor of the ATM VC. Scheduling at the ATM level enforces the priority and bandwidth sharing desired at the cell level. This architecture is illustrated in Figure 2.

Figure 2 – Hierarchical scheduling into a ATM VC

It is important to note that any discard decision should be performed exclusively at the packet level where the context for the frame forwarding class and for the 802.1p bit mapping to a forwarding class is known. When a per-VC queue backs up, a back-pressure scheme should be applied such that the frames are held in the per-forwarding class packet queues dedicated to this VC. There is, however, a condition under which a discard occurs in the ATM SAR device. This is when the CRC 32 check for a re-assembled AAL5 PDU fails. This occurs when a cell is missing or was re-ordered in the ATM network for a given AAL5 PDU.

This hierarchical scheduling of frames and cells of a given VC terminating on a VPLS instance provides the flexibility to apply policing and shaping on a per-forwarding class basis for the Ethernet frames of each VC, as well as the option to shape the aggregate cell flow into the ATM VC back into the customer site.

Resilience of the ATM VC at the gateway PE router is provided via a SONET/SDH link automatic protection switching group. Furthermore, customer STP bridge protocol data units (BPDUs) are transparently passed from the TLS network to the VPLS network. This requires the translation of customer BPDUs from 802.1d format, which operates in the ATM TLS network, to the per-VLAN STP (PVST) format, which is typically used by customer premises equipment that is directly attached to a VPLS PE. This allows each customer to run STP end-to-end to prune the entire topology in order to select an active path and to disable loops.

Resilience of the ATM VC at the gateway PE router is provided via a SONET/SDH link automatic protection switching group. Furthermore, customer STP bridge protocol data units (BPDUs) are transparently passed from the TLS network to the VPLS network. This requires the translation of customer BPDUs from 802.1d format, which operates in the ATM TLS network, to the per-VLAN STP (PVST) format, which is typically used by customer premises equipment that is directly attached to a VPLS PE. This allows each customer to run STP end-to-end to prune the entire topology in order to select an active path and to disable loops.  Resilience is further enhanced on the PEs with technology enhancements such as non-stop routing and non-stop service (NSS) to augment MPLS fast reroute (FRR) on the VPLS network to provide better than sub 50m/s availability.

Conclusion

Enterprises are transitioning from network orientation to application orientation and require an architecture that supports the convergence of sophisticated on-demand video, voice over IP (VoIP) and data applications. The best-effort performance of traditional transparent LAN services becomes insufficient: they do not scale economically, become increasingly difficult to manage, and offer limited support for multiple service classes.   Service providers are seeing the writing on the wall and have already begun to structure their migration to an MPLS-enabled WAN Ethernet solution, such as VPLS.