abels that are used in the GLSPs. The mechanism used by RSVP-TE is downstream-on-demand label distribution: this means that upstream GLSRs request downstream GLSRs to select labels for the links connecting them. In this way, each GLSR acknowledges a request to install an GLSP, for- ward the request to the next downstream hop, and awaits the response. As a response is returned upstream, the GLSR can install a cross-connection (i.e., state describing ingoing and outgoing label-to-interface mappings and associated network resources) for this GLSP. Here, downstream is defined as the direction from GLSP ingress to GLSP egress for a unidirectional GLSP. In the case a bidirectional GLSP is to be set up, this is done by contemporary setup of two unidirectional GLSPs. Once all the labels are assigned, the GLSP can be set up. As a matter of fact, GLSR can route the signal incoming from an input port toward the output port with the same label and the GLSP is identified in the path topology through the vectors whose elements are the labels of the links traversed by the path in the correct order. As for all signaling protocols, RSVP-TE operation is composed of three main functions: 1. GLSP setup that is carried out via labels distribution. 2. GLSP management, a function composed by various elements among which error management is probably the most important. 3. GLSP tear down that is carried out by labels removal. 8.3.2.4.1 GLSP Setup Establishing bidirectional GLSPs employing RSVP-TE for signaling requires full sets of Path and Reservation (Resv) messages to be exchanged between two GLSRs. This proce- dure is sketched in Figure 8.14. Initially, a sender GLSR (GLSP ingress) requests a GLSP to be set up by sending a Path message downstream to the next hop. This Path message contains an UPSTREAM_LABEL object defining the label to use in the upstream direction, objects describing the data flow, and a GENERALIZED_LABEL_REQUEST object for requesting the GLSP. If the Path message is successfully received, the next hop then reserves