VC-Merge-Capable ATM-LSRs

ATM MPLS was developed to control very large networks. The protocol's scalability was considered from the ground up. Very large networks with many LSRs, eLSRs, and destinations and that provide CoS support have an extra scalability tool: VC-merge reduces the number of labels required per link. A VC-merge MPLS link allocates at most one label per FEC. On multi-vc networks, a FEC is defined by a destination and a CoS; therefore, the VC merging occurs only for the same CoSs without jeopardizing multiple-class support.

VC-merge is the capability by which an LSR receives cells on several incoming LVCs (that is, on different VPI/VCI pairs) and transmits them on a single outgoing LVC without causing the cells of different AAL5 PDUs to become interleaved.

The primary difference is that a VC-merge-capable ATM-LSR needs only one outgoing label per FEC, even if multiple requests for label mapping to that FEC are received from upstream neighbors. In other words, VC-merge allows a multipoint-to-point connection to be implemented by queuing complete AAL5 frames in input buffers until the end of a frame has been received. This requires buffering because the cells from the same AAL5 frame are all transmitted before cells from any other frames.

Figure 4-19 shows an example of VC-merge.

Figure 4-19. VC-Merge-Capable ATM-LSRsMultipoint-to-Point

Figure 4-20 shows the network-wide LVC reduction effect in VC-merge MPLS networks.

Figure 4-20. Network-Wide Effect of VC-Merge

On Cisco multiservice switching platforms, VC-merge capability is implemented in the egress line cards. The primary endpoints are configured as with nonmerging endpoints, but the secondary endpoints in the egress line card are divided into leaves and root. The leaf receives cells from the switch fabric and translates the VC to the root. This is shown in Figure 4-21.

Figure 4-21. VC-Merge Implementation in Multiservice Switches

From a design perspective, VC-merge might be required only in core links.

There are differences between a conventional ATM-LSR and a VC-merge-enabled ATM-LSR with respect to label mapping. The messaging that takes place in a VC-merge-enabled LSR is shown in Figure 4-22.

Figure 4-22. VC-Merge Label Mapping

From Figure 4-22, we can identify the following steps:

Step 1.	The LSR receives a label request from the upstream LSR.
Step 2.	The LSR allocates an incoming label.
Step 3.	Assuming that an outgoing mapping for the FEC has been set up by a previous request, no further downstream request is required.
Step 4.	The LSR returns a label mapping to the upstream requester, regarding the label request from Step 1.
Step 5.	Repeat for all further requests for that FEC.

In a non-VC-merge ATM-LSR, the procedure diverges in Step 3. A non-VC-merge environment has the following Step 3:

Step 3.

The LSR requests a label from the downstream device. The downstream LSR returns a label mapping.

This non-merging scenario is shown in Figure 4-23.

Figure 4-23. Non-VC-Merge Label Mapping

In summary, VC-merge improves signaling performance as well as label space.