 Resource Reservation Protocol Traffic Engineering (RSVP-TE). The GMPLS specification presents a functional description of the extensions needed to generalize the MPLS control plane to support each of the four classes of interfaces. Only signaling-protocol-independent for- mats and definitions are provided in this document. Protocol-specific for- mats are defined in the documents GMPLS-RSVP and GMPLS-LDP. Technology-specific details are specified in technology-specific documents, such as GMPLS-SONET. The sections that follow, which are contributed by Data Connection Ltd., explain how the concepts of classical MPLS are generalized enough to be applicable to optical networks and describe key aspects of GMPLS technology.2 8.1 Labels in Optical Networks A basic requirement in MPLS is that the two LSRs at either end of a link must agree on how they will mutually identify a traffic flow. For this pur- pose, they use a label that is assigned by one of the LSRs and distributed to the other LSR using signaling protocol messages. Chapter 8 8.1.1 Nongeneralized Labels In nongeneralized MPLS, a label is a number (up to 32 bits) that is written into the protocol header fields of data packets traveling on the link. Once a pair of LSRs have agreed on this number, they also agree that the corre- sponding data flow consists of all data packets with this number in the appropriate protocol header field and will switch all the packets in this flow in the same way. Note that with this kind of label, the agreed label value does not neces- sarily imply a relationship to bandwidth allocation or quality of service (QoS) for the corresponding data flow. The label value might not imply any- thing about how frequently packets with that value might arrive or what bandwidth is available. Traffic-engineering LDPs (such as RSVP and CR-LDP) facilitate QoS and bandwidth negotiation as part of the label exchange. Other protocols (such as LDP) simply exchange labels. 8.1.2 Generalized Labels The premise of GMPLS is that the idea of a label can be g