4.2 Evaluation of an experimental GMPLS-enabled multi-layer control
4.2.1 Forwarding adjacencies mechanism implementation
In current GMPLS standardization there is an intrinsic association between the signaling of a new client LSP and the creation of the required λ-LSP to support it [RFC4206]. Hence, a route from source to destination is computed upon client LSP request, which may be constituted of both unallocated data links and already existent FA-LSPs. In the case that no FA-LSP is comprised along the route, a new λ-LSP is typically set up from source to destination to support the incoming request. Otherwise, λ-LSPs are set up to provide connectivity on those route segments where no FA-LSP is yet established. In light of this, three possible scenarios can be found when establishing a client LSP in a multi-layer environment:
• A client LSP which only uses data links: In this case an end-to-end FA-LSP is created and logically associated to the client LSP. In the transport plane, the client data flow is tunneled through the new λ-LSP.
• A client LSP which uses both data links and forwarding adjacencies: New FA-LSPs are created in the sections composed of consecutive data links (satisfying the WCC). Each used FA-LSP is associated to the new client LSP and the client data flow is transported through the concatenation of λ-LSPs.
• A client LSP which only uses forwarding adjacencies: No FA is created. Like in the previous case, the used FA-LSPs are associated to the new client path and the occupied bandwidth of each one is updated. From the transport plane perspective, the client LSP is tunneled through the concatenation of λ-LSPs.
Figure4.3(a) depicts the first situation in the list. There, a new client LSP request from E to D arrives to the CC of the source node E. The CC requests a route to its RC which calculates the shortest path using the information contained in the traffic engineering database (i.e. data links and existing FAs). Particularly in this first case, the route is only composed by data links so, an end-to-end λ-LSP from E to D will be created to tunnel the client LSP. Furthermore, the newly established λ-LSP will be associated to a new FA-LSP resource (FAE-D) which, in turn, will be available to tunnel as many client
The RC builds the ERO from the computed route and passes it back to the CC which starts the signaling process by means of the RSVP-TE protocol. As the source node of the yet to be created λ-LSP, the CC in A pops the first ERO subobject containing the node and the interface identifiers of the data link that has to be reserved by the LRM. Addi- tionally, the CC asks to the LRM for the local identifier to be associated to the new FA re- source (E1 in the figure). This value is used to create the LSP TUNNEL INTERFACE ID object which is added to the PATH message. Finally, the PATH message is forwarded to the next hop of the ERO. Each intermediate node (i.e., F and G) of the yet to be created λ-LSP proceeds as in the usual single-layer signaling mechanism to reserve the requested local resource (data link). Upon the arrival of the PATH message, the desti- nation node D is responsible for assigning a remote identifier (D1) to FAE-D in the same
manner as done in node A, that is, by asking to the LRM for a value for the remote LSP TUNNEL INTERFACE ID object. This remote identifier is sent to the source node through the RESV message initiated by the destination node. Like in the single layer scenario, the RESV message is also used to allocate the data links assigned to the new λ-LSP. Once the RESV message reaches the source node, the new client and λ LSPs are established and the new FA-LSP resource is created in the scope of the LRM. Eventually, the LRM notifies about the created resource to the local RC which, in turn, dissem- inates it as a new Opaque LSA to the remainder OCCs in the network by means of the extended OSPF-TE protocol. Note that the newly created FA resource presents an allocated bandwidth equal to the one requested by the client LSP.
In the second case, shown in Figure 4.3 (b), a client LSP between nodes A and G is requested. There, the best calculated route contains data links (one from A to E and another one from D to G) and the previously created FA (FAE-D). In this situation, new
FA-LSPs (each one associated to a λ-LSP) are created from the segments of the route composed by consecutive data links, and the bandwidth requested by the new client LSP has to be allocated from the already active FAE-D. As shown in the figure, the
mechanism for creating FAs in this context is exactly the same as the one described for the first scenario. Specifically, two FAs (from A to E and from D to G) are created in this example. Once the ERO has been created in node A, the signaling process is started by assigning the identifier A1 to FAA-E. Upon the reception of the PATH message, the CC
at node E notices that the incoming resource is a data link (so a new FA will be created) and the outgoing resource corresponds to the already existing FAE-D. Therefore, being
the destination node of FAA-E, node E requests an identifier E2 that will be sent back to
node A by means of the RESV message. Furthermore, node E allocates the client LSP requested bandwidth from FAE-D and forwards the PATH message to the downstream
node which, in that case, results to be node D since it is the tail-end of the used FAE-D.
When the PATH reaches node D, the local CC checks that the incoming resource is an FA but the outgoing one is a data link so, the reverse process from node E has to be initiated. Herein, node D requests an identifier D2 for the new FA (from D to G) and forwards the PATH message. Finally, node G assigns the remote identifier G1 to FAD-G. As explained
in the previous scenario, the RESV message is used to disseminate remote FA identifiers as well as for allocating the network resources. The new FA resources (FAA-E and FAD-G)
are disseminated along with the new available bandwidth of the already existing FAE-D.
As can be extracted from the previous case, in a scenario using only FAs the head-end node of each FA allocates the requested bandwidth during the signaling but no FA creation process is triggered. The used FA resources with their updated bandwidth information are flooded by means of the extended OSPF-TE.