The Routing Controller (RC, Figure 3.4) is responsible for providing routing adjacency to the OCC within the DCN. Being an IP network, the routing in the DCN is done by means of the standard OSPF version 2 protocol ([RFC2328]). In this way, the activity (i.e. route calculation, signaling and link management) in the whole control plane is enabled.
Furthermore, the RC is the main actor in the path computation tasks. In this regard, when the OCC (concretely, the CC) receives a connection request, a path computation request is sent to the RC. Since this calculation comprises the routing and the wavelength assignment, each RC manages a complete graph of the optical transport network to obtain
Figure 3.4: Routing Controller architecture.
end-to-end traffic engineered routes. To build the global map of the network, the RCs in the different OCCs cooperate sharing the local data plane information provided by their respective LRMs. This is achieved thanks to the OSPF protocol engine and the TE extensions it is provided with (OSPF-TE). Thus, the RC disseminates the TE and data links information by means of OSPF-TE and processes the one coming from its neighbors. This information is then stored in the Traffic Engineering Database (TED) and used to build the network graph over which route computations are performed.
As said, the OSPFv2 protocol for IP networks is defined in [RFC2328]. Nonetheless, a set extensions is applied to the protocol so it is able to fulfill the traffic engineering requirements of new generation optical transport networks. In this context, [RFC3630] defines a number of Traffic Engineering attributes aimed to cope with the MPLS technol- ogy routing requirements and, by extension, the GMPLS ones. Note that extensions in OSPF are usually introduced as Type/Length/Value (TLV) objects, which are inserted in the Link State Advertisement (LSA) messages to convey specific topological informa- tion. Particularly, to disseminate TE information, the Opaque LSA (OLSA, [RFC2370]) message is extended with two top-level TLVs, namely Router Address and Link which, in turn, are provided with a set of sub-TLVs. It is clear that whilst OLSAs conveying a Router Address TLV disseminate information related to the node, the ones provided with a Link TLV disseminate data related to a TE link. For sake of conciseness, the Router Address TLV is left out of the scope of this document. Table 3.1 shows the parameters related to a TE link, which are mainly focused on link identification (through a set of identifiers) and bandwidth occupancy. More precisely, sub-TLV type 1 characterizes the link type as point-to-point or multi-access. Sub-TLVs from 2 to 4 identify the TE link through a unique link identifier, and the interfaces of the routers it is connected to. Sub- TLV 5 allows setting a user-defined cost to the link. Sub-TLVs ranging from 6 to 8 carry the link bandwidth occupancy. Finally, sub-TLV 9 is set by the network administrator and identifies the administrative group assigned to the TE link.
Type Name 1 Link Type 2 Link Id
3 Local Interface IP Address 4 Remote Interface IP Address 5 Traffic Engineering Metric 6 Maximum Bandwidth
7 Maximum Reservable Bandwidth 8 Unreserved Bandwidth
9 Administrative Group
Table 3.1: TE attributes (sub-TLVs) assigned to the Link TLV [RFC3630].
In light of the stated in [RFC4202], additional extensions for OSPF-TE in support of GMPLS are proposed in [RFC4203]. Like in the previous case, they consist of new sub- TLVs which are added to the above-mentioned Link top-level TLV. These extensions are depicted in Table3.2and the list below highlights the most relevant ones for the research done in this work:
• The Link Local/Remote Identifier is proposed to support unnumbered links as re- ported in section 2.2.1. In contrast to the previously depicted Local and Remote Interface IP Address sub-TLVs (type 3 and 4 in Table 3.1), which were defined to carry the numbered interfaces (i.e., IP addresses) of the two routers connected by the link, this new sub-TLV carries user-defined local and remote identifiers assigned to the TE link.
• The Link Protection Type contains the protection capabilities of such TE link. • The Interface Switching Capability Descriptor gives information about the switching
technologies (i.e., packet, TDM, wavelength, fiber) associated to the interfaces the TE link is physically connected to.
• The Shared Risk Link Group is used for protection and restoration. The SRLG identifies TE links having the same exposure to failures. This attribute is not used in the scope of this thesis.
Section 2.2.1 has introduced the work that is being currently done regarding the defi- nition of routing protocols extensions for wavelength information dissemination, which
Type Name
11 Link Local/Remote Identifier 14 Link Protection Type
15 Interface Switching Capability Descriptor 16 Shared Risk Link Group
Table 3.2: TE attributes (sub-TLVs) assigned to the Link TLV in support of GM- PLS [RFC4203].
facilitates the combined RWA within the RC. Based on those proposals, a new non- standard Wavelength availability sub-TLV is added to the CARISMA OSPF-TE protocol implementation, in particular to the Link top-level TLV. In this way, the information related to the wavelengths (i.e. data links) of each TE link is flooded at network boot-up and under changes occurred in the TE link status. Specifically, the new sub-TLV conveys a bitmap representing the status (free or occupied) of the wavelengths supported by the TE Link, so the routing engine is aware of the availability of such resources. Hence, each wavelength is represented by a bit in the bitmap being set to 1 for free channels and to 0 for the occupied ones. The proposed encoding of this sub-TLV is based on the defined in [WSON-Enc], and its building fields, headed by the type and length, are shown in Figure3.5. Therein, the Action field gives information about the type of data contained in the sub-TLV. In this case it is always set to 4 indicating that the sub-TLV conveys a bitmap (the interested reader may refer to [WSON-Enc] for further detail). Next, the number of wavelengths contained in the TE Link is conveyed. Length indicates the num- ber of bytes remaining in the sub-TLV and is used to process the sub-TLV properly. The next four bytes indicate the lowest channel of the TE Link encoded following the established in [RFC6205]. The lowest channel is mapped in the bit position zero while each succeeding bit position represents the next frequency a channel spacing (CS) above the previous. The bit map is made up of 32-bit words to assure that the sub-TLV is multiple of four bytes so, in some cases, there will be unused bits in the bitmap which will be set to zero and ignored. Note that, with this sub-TLV format, there is no differ- entiation between occupied and unused wavelengths, since both types are ignored during route computation. Further, extensions could be applied to the sub-TLV for more precise wavelength information.
More specific details will be given on these extensions when necessary in forthcoming chapters.
Figure 3.5: Wavelength availability sub-TLV