h leads to a num- ber of difficulties: The OTN has no control over these address spaces SO it cannot organize them to facilitate routing (for example, via hierarchies and summarization). Clients who need to interconnect to other clients using different protocols would need to be capable of translating between multiple address formats. GMPLS in Optical Networks Within a single address format, two client networks may use addresses that clash (for example, in the case of virtual private networks [VPNs]). This means that a client address on its own may not actually be a unique identifier. 8.7.4 The Realization of UNI in GMPLS Protocols Although UNI is not a standard GMPLS peer-to-peer relationship, the sig- naling function required by UNI is very close to that achieved by the exist- ing GMPLS signaling protocols RSVP and CR-LDP (although in practice, as with GMPLS, RSVP is well ahead in terms of current implementation). With a few extensions to support the UNI-specific features such as TNA addressing, diversity, and connection identification, these protocols can be used for UNI signaling. Similarly, the various link management and service discovery functions carried out by client and OTN UNI neighbors can be achieved by an extended flavor of LMP (see Section 8.6). The mapping between the standard and UNI flavors of the protocols are nontrivial so an edge node for a GMPLS-provisioned OTN needs to be capa- ble of running UNI across some interfaces and standard optical signaling across others. The OIF has produced a specification document describing how existing protocols can be extended to provide UNI functionality. The OIF UNI cur- rently covers SONET/SDH connections and includes a wide range of proto- col features discussed in this chapter, including the following: RSVP, LDP, and LMP with UNI extensions UNI TNA addressing Out-of-band signaling Bidirectional LSPs Label set Reduced refresh processing Setup confirmation Chapter 8 8.7.5 LMP Extensions In addition to the standard LMP features described in Section 8.6, OIF