" replies, the traceroute utility can determine the IP address of each hop along a path. This is highly useful for debugging connectivity problems. Because TTL is SO important for both loop mitigation and debugging, it was decided to support its implementation in MPLS. However, because an LSR cannot change the contents of a labeled packet, the TTL field in a labeled IP packet will not decrement as it passes through the LSR. Consequently, the TTL field in the shim label is used and decremented as it passes through each IP router. To make the MPLS TTL field compatible with the IP TTL field, the TTL field from an unlabeled IP packet is copied, decremented by 1, and put into the TTL field of the shim label as the packet enters the LSP. At the end of the tunnel the TTL field from the shim label is copied back into the IP packet. MPLS designers chose to specify that, when a TTL field expires in a LSR, the packet is dropped and an ICMP packet with a "time exceeded" message is sent. However, as we will see later when discussing VPNs, it is possible that an intermediary LSR will not use the same address space at the two ends of the tunnel. Thus, MPLS defines that the ICMP message is sent to the end of the tunnel and that it is the router at the end that is responsible for sending the ICMP packet back to the source. Signaling Other Issues with Forwarding The previous section presented an overview of MPLS forwarding architecture, but in prac- tice there are a number of details that require more depth of discussion than possible here. A brief discussion of some of these details with further reading is provided. The forwarding summary described in this section matches the description in RFC 3031. In practice the breaking up of tasks into various tables (or maps) is somewhat arbitrary, and router vendors often have their own internal architectures that perform tasks by a method that matches their implementation. For example, Cisco has a mechanism termed Cisco Express Forwarding (CEF) that is used to perform IP forwarding in an