e that the signaling message arrives at the next hop on the data path and that the transit nodes in the signaling path do not interfere with it: The IP packet carrying the signaling message can be addressed to the LSR that is the next hop on the data path, rather than to the LSP egress, and can be sent without setting the Router Alert flag in the IP header. This is done for a couple of reasons: Addressing to the next-hop LSR ensures that the packet will reach the correct LSR, but requires that the receiving LSR relaxes the rule that the IP packet should be addressed to the egress LSR. (In practice, many LSR implementations may not police this last rule anyway.) Not setting the Router Alert flag should mean that the packet is forwarded without being intercepted by any router except the one to which it is addressed. However, it is likely that some IP stack implementations will not correctly check the Router Alert flag. When traveling through an arbitrary IP cloud, this is not a reliable solution. The IP packet can be sent double encapsulated with an extra IP header. The outer header is addressed to the next hop on the data path and shows the payload protocol as IP encapsulated, while the inner header is the normal header for an RSVP packet. The second of these approaches is the more robust. It requires some addi- tional straightforward function at the receiving LSR to recognize that it is the target of the IP packet, strip the outer header, and then treat the inner header as normal, passing it up to the signaling stack. Note that these issues primarily concern RSVP signaling. CR-LDP transfers signaling data over Transmission Control Protocol/Internet Pro- tocol (TCP/IP) sessions between signaling peers and therefore does not suf- fer from the problems described previously. 8.3.3 Data Interface Identification An LSR can expect to receive out-of-band signaling messages over a differ- ent interface from the one that is going to carry data. This raises two con- cerns. First, on receipt of a Path message, how does the L