ng via an exist- ing Internet Protocol (IP) cloud. GMPLS in Optical Networks Out-of-band signaling raises three key issues for the application of GMPLS to optical networks: The routing that an optical LSR performs during LSP setup must be extended to calculate suitable distinct next-hop IP addresses and outgoing interfaces for the data and signaling. Signaling messages may need to be encapsulated to ensure that they arrive successfully at the intended next-hop LSR. Because signaling messages are no longer in band, they need a way of indicating the data interface to which they refer. The following subsections explain these issues further and how they are resolved. 8.3.1 Extending Routing Calculation When an LSR on the data and signaling paths attempts to route the LSP setup, it must calculate two outgoing routes to the next hop: one via the data path and one via the signaling path. The data path must be evaluated first and a signaling path must then be found that reaches the next hop on the data path. The topologies for the signaling and data networks are obviously differ- ent SO the routing decision is complicated. Work is ongoing on optical exten- sions to Open Shortest Path First (OSPF) that will permit the distribution of topology data for both signaling and data networks. Once this data has been distributed, each individual LSR has the information that it needs to calculate the required routes for out-of-band signaled GMPLS. 8.3.2 Signaling Message Encapsulation When running RSVP signaling, each signaling message is addressed to the egress (destination) LSR, never to the immediate next hop. Routers on the path intercept such messages by noticing that the Router Alert flag is set. In out-of-band signaling, there are two problems with this approach: The IP cloud spots a neat short route to the egress that entirely misses the next hop on the data path. A transit node in the IP cloud is RSVP capable, intercepts the signaling message, and attempts to process it. Chapter 8 There are two possible approaches to ensur