ed to differentiate site-specific traffic because the different customer sites connected to the PE might use overlapping address spaces. This problem is overcome by the use of a label stack operation at the ingress PE router. To see the solution (and another explanation of the problem), note the example shown in Figure 13.16, which takes two common customer sites, and the associated path, from Figure 13.15. The packet from site E, destined for site D, is forwarded using conventional IP from CEE to PEE. At PEE it enters the interface belonging to RD 1:2 and SO there is a lookup in the associated PSFT. The PSFT is used to configure a unique FEC-to-NHLFE map for each RD. This determines that the packet needs two labels pushed onto it. The first label pushed onto the packet is the label used by the egress PE to distinguish between different In the example of Figure 13.16 this is label 55. This label value is passed from PECD to PEE using BGP to carry the label binding. Thus BGP becomes a label distribution protocol by including a label-mapping object as an extension to BGP as specified in RFC 3107. This label will only be used at the egress (PEE) to distinguish packets destined for site D from those destined for site C; it is not a label advertised by the next physical hop, which is P5. Thus, P5 will advertise a label using LDP such that it can forward the packet to the internal interface of PECD. In Figure 13.16, P5 advertises label binding 34 to PEE, and this is pushed onto the top of the stack. Now the packet is forwarded along the LDP-provisioned LSP to PECD using only the top label. When the packet enters PECD, the top-level label is removed, exposing label 55, which specifies that the label stack should be popped and the (unlabeled) packet should use the PSFT for RD 1:2. In practice the NHLFE table for this label will specify the link layer encapsulation and outgoing port (to CED) directly SO that an IP table lookup is not required. Finally, the unlabeled packet reaches CED and is forwarded to the destina- tion