bution. The MPLS architecture document does not mandate a single protocol for the distribution of labels between LSRs. The MPLS architecture document allows multiple different label LDPs for use in different scenar- ios. Alternatively, LSPs may be configured as static or permanent LSPs by programming the label mappings at each LSR on the path using some form of management such as Simple Network Management Protocol (SNMP) control of the Management Information Bases (MIBs). A key to MPLS is that once the labels required for an LSP have been exchanged between the LSRs that support the LSP, intermediate LSRs transited by the LSP do not need to examine the content of the data pack- ets flowing on the LSP. For this reason, LSPs are often considered to form tunnels across all or part of the backbone MPLS network. A tunnel carries opaque data between the tunnel ingress and egress LSRs. In Figure 7-13, both LSPs are acting as tunnels. LSR B forwards the packets based only on the label attached to each packet. It does not inspect the contents of the packets or the encapsulated IP header. Where LSPs are parallel, they can be routed, together, down a higher-level LSP tunnel between LSRs in the network. Labeled packets entering the higher-level LSP tunnel are given an additional label to see them through the network and retain their first- level labels to distinguish them when they emerge from the higher-level tunnel. The process of placing multiple labels on a packet is known as label stacking, which is shown in Figure 7-16. Label stacks provide a finer gran- ularity of traffic classification between tunnel ingress and egress nodes than what is visible to the LSRs in the core of the network, which route data solely on the basis of the topmost label in the stack. This helps to reduce both the size of the forwarding tables that need to be maintained on the core LSRs and the complexity of managing data forwarding across the backbone. In Figure 7-16, two LSPs between LSR A and LSR E, and between LSR B and LSR E, shown as dark gr