That is, they need to be capable of carrying data in both directions. In the original specification of MPLS, bidirectional connections required the setup of two unidirectional LSPs and therefore coordination between the endpoints. This may have required management messages to be sent to both ends of the LSP, requesting that the two directions be signaled by the two ingress nodes. This had the disadvantage of needing two signaling pro- tocols (one for MPLS and one for the management messages) and could result in the two directions of the LSP following different paths through the network. It also left the endpoints with the need to invent a way of identi- fying and coordinating the two unidirectional LSPs that made up a single bidirectional LSP. An improvement was achieved using special processing at the egress of a unidirectional LSP to react to the receipt of a request for an LSP not just by sending a response, but also by sending a request in the opposite direc- tion. With the use of route recording and explicit routing, this allowed the two directions to follow the same path through the network, but still left coordination problems between the two directions of LSP. Both of these solutions have the additional issue that four signaling mes- sages are required (request and response in each direction) to set up the single LSP. GMPLS makes extensions to MPLS to address all of these issues and to allow a bidirectional LSP to be set up using a single message exchange. This has the benefit of requiring less signaling and achieves immediate coordi- nation between the directions of flow. For the sake of clarity, we define the head end of the LSP as the initiator and the tail end as the terminator. In a unidirectional LSP, the ingress is the initiator and the egress is the terminator. In a bidirectional LSP, the concepts of ingress and egress and upstream and downstream are not clear because data flows in both directions, but as the LSP is originally requested from one place and responded to from another, we can use the 