alizes the Request Setup message for two reasons: to dis- tinguish it from a nongeneralized request setup and to enable it to carry additional parameters that specify the request in more detail. In RSVP, this is done by using a Generalized Label Request object instead of LABEL_REQUEST object in the Path message and CR-LDP by adding a Generalized Label Request TLV to the Label Request message. Some of the information that the downstream LSR needs in order to allo- cate a suitable label value is implied by the context. At the most basic level, both LSRs know that the label must be a generalized one, rather than, say, a nongeneralized ATM label, because they know that the link to which the request applies is a generalized optical link. Therefore, this information is not explicit in the request message. However, because an optical link may consist of a bundle of fibers and the switches may support more than one kind of multiplexing on those fibers, it is necessary for the upstream LSR to specify the LSP encoding type that it wants for the data flow being set up. This encoding type then determines whether the agreed label will be time slot or wavelength based and deter- mines the kind of label. So the Generalized Label Request specified by GMPLS carries an LSP encoding-type field. The currently supported values for this field that are relevant to optical networks are American National Standards Institute (ANSI) Plesiochronous Digital Hierarchy (PDH) European Telecommunications Standards Institute (ETSI) PDH GMPLS in Optical Networks SONET Digital wrapper Lambda Fiber Because some links may advertise the capability to support more than one type of switching capability (through the Interior Gateway Protocol [IGP]), the Generalized Label Request object/TLV contains a field that indicates the switching mode to be applied to the particular LSP. This enables, for example, a switch to switch whole fibers, wavebands, or indi- vidual lambdas. The choice of how to switch for any particular LSP is made when the LSP is set up. Th