th between the client nodes is then set up by overlaying it upon this internal tunnel. For the remainder of this section, we will look at the requirements and specifications of this O-UNI. 8.7.2 UNI Services The client and OTN edge nodes that support UNI are not traditional sig- naling peers in that the OTN service provider agrees on a contract (in the billable sense) with the client to provide a certain level of service across the network. A UNI message from the client to the OTN is best viewed as a request for service. Given the contractual angle, it is important to have a defined method for identifying and authenticating clients across the UNI. This enables the OTN to ensure that a client's account is in good standing before granting a connection request. For billing and auditing purposes, the OTN may also need to keep track of the connection by assigning a connection identifier that is valid beyond the lifetime of the connection and by returning this identifier to the client. GMPLS in Optical Networks Figure 8-12 Optical Transport The OTN and UNI Network access. Client Network Client Network In order to set up a connection, a client needs to discover what services are available from the OTN and then signal its requirements across the UNI. The types of service parameters signaled across the UNI are Requested bandwidth of the connection Class of service (CoS) (for example, the network restoration/protection strategy required) Diversity (discussed in the following section) Data-plane-specific characteristics (for example, for SONET/SDH, port, transparency, and concatenation information) A fundamental requirement of UNI is that clients are not given access to OTN internal addresses or topology information. This means that UNI con- nection requests are not allowed to specify explicit routes. The diversity parameter enables a UNI client to request that a new connection must fol- low a different route to a set of previous connections without requiring internal knowledge of the OTN. This is necessary SO that the clie