tributes are disseminated within the TE domain. This routing process is implemented using routing pro- tocols specified for the MLCP. However, this routing process is not used for routing user traf- fic, but only for distributing information in the MLCP. To understand this point, we have to remember that, taking as an example the optical domain, user signals are organized in opti- cal channels that are routed like circuits in that layer. Extensions to existing protocols neces- sary for this routing process were therefore created in the relevant IETF and OIF standards. Essentially, with OSPF-TE, participating generalized label switched routers (GLSRs) first establish routing adjacencies by exchanging hello messages. After routing adjacencies have been established, the GLSRs then synchronize their link state databases. This is done by exchanging database description packets. The database description packets contain at least one database structure referred to as a link state advertisement (LSA). Different LSA types exist but all share a common 20-byte header whose structure is shown in Figure 8.11. The primary OSPF-TE operation is to flood LSAs throughout the MLCP domain by appending them to "link state update" messages periodically sent between adjacent GLSRs. To avoid interference with any ordinary routing processes, a TE LSA is made opaque. Such an opaque LSA is a special type of LSA only processed by specific applications (e.g., the GMPLS routing process). By extending the link state database with TE information, a traffic engineering database (TED) is produced. From this TED, a network graph with traffic engi- neering content can be computed. Constructing a TE network graph is necessary to provide input for the constraint-based algorithms subsequently used to compute network paths. When flooding LSAs, each OSPF-TE routing message contains a common 24-byte header, which is used to forward it. This routing message header includes information about mes- sage type, addressing, and integrity. Within this header, LSA