 be protected from having to advertise this huge number of links? With a large number of fibers, how can the neighboring devices agree on how to address these links without manually configuring each node with the other's link-numbering scheme? Given that some channel session protocol is required to address these issues, what other features of this protocol are needed, for example, to authenticate session peers and detect interrupted sessions? LMP³ has evolved to address these issues. This section presents some of its features. Between two nodes in an optical network, there may be multiple paral- lel optical data links that carry the data traffic. These data links may be Electrically terminated at a node, in which case the node is always aware of the flow of data Transparent, for example, if a node is implemented using Micro- Electro Mechanical Systems (MEMS) mirror technology, in which case the node cannot normally see the data flowing (although in many optical devices, an optical tap can be used to check the data flow when necessary) In the general case, as described previously in Section 8.3, there is a sep- arate control channel that is used for protocol exchange (out of band), although it is also possible for the protocol exchange to take place through GMPLS in Optical Networks one or more of the data links (in band). The fundamental job of LMP is to validate the "wiring" of the links between adjacent nodes, validate that each data link is operational, and localize faults. Therefore, LMP protocol exchange is only required between adjacent nodes that are directly con- nected by data links. The IETF LMP specification covers the following areas of functionality. Some of these areas are optional within the protocol and do not need to be present in an LMP implementation. Each area is described in greater detail in the following subsections: Control channel management This covers the establishment, configuration, and maintenance of an IP control channel between a pair of neighboring LMP nodes. Link verification Thi