SR know which data interface is being signaled? There are several options: GMPLS in Optical Networks Instead of a network (IPv4 or IPv6) address, an explicit route may specify an unnumbered link object. The unnumbered link ID in this object is sufficient to identify the data interface to which the signaling message refers. An explicit route may specify the label for the hop. It is conceivable that the label value could also encode the interface index to which the label applies. For example, the label could carry the port ID in the top 16 bits and the lambda ID in the lower 16 bits. The data interface may be communicated via some new signaling protocol object. Second, the LSR needs to relax its explicit route processing rules SO that it is acceptable for the top hop to refer to the data path and not the signaling path. 8.3.4 Standardization Status The latest GMPLS drafts address some of the issues of out-of-band signaling: Data interface identification-this is supported by the interface ID TLV, which can carry any combination of the following kinds of addresses: An IPv4 address. An IPv6 address. An IP address together with an interface identifier. An IP address together with an upstream component link identifier. An IP address together with a downstream component link identifier. In Generalized RSVP-TE, this TLV is part of the IF_ID RSVP_HOP object, which replaces and extends the previously defined RSVP_HOP object. In Generalized CR-LDP, this TLV forms the body of the new interface Control plane link and node failure. Generalized RSVP-TE uses standard RSVP refresh mechanisms to synchronize state following a control plane link or node failure, but it also does the following: Defines a way to negotiate the maximum control plane recovery period Chapter 8 Reuses the suggested label object to enable an upstream node to tell the recovered downstream node about the label values that it allocated before failure Generalized CR-LDP uses the mechanisms already described in draft ietf-mpls-ldp-ft4 to synchronize signaling sta