The MulTreeLDP protocol

In this section, we describe MulTreeLDP, our signaling protocol for label distribution of multicast LSPs (mLSPs). Two signaling protocols have been developed for MPLS unicast, TE-RSVP [8] and LDP/CR-LDP [3] [41]. Neither supports multicasting, nor have they been implemented for Linux. Unlike RSVP-TE, CR-LDP has been specifically designed for MPLS, thus it is easier to engineer multicast extensions for CR-LDP than for RSVP-TE.

Our MulTreeLDP signaling protocol is a new label distribution protocol which conforms to the requirements of the MPLS architecture [62]. The MulTreeLDP protocol is different from CR-LDP, however we kept the CD-LDP message formats, making it possible to envision a merging of MulTreeLDP with CR-LDP. MulTreeLDP defines three different categories of messages. Advertisement messages create label mappings and LSPs. Link failure and recovery detection messages are used to detect the failure or the recovery of links attached to interfaces of an MPLS router. For proper MulTreeLDP operation, advertisement and notification messages must be delivered reliably and in-order. To satisfy this requirement, we chose TCP (port 2646) as the transport protocol for these messages. On the other hand, a link failure or repair needs to be detected as early as possible and TCP retransmission timers would increase the detection time. Therefore, link failure and recovery detection messages run over UDP (port 2646).

All MulTreeLDP routers listen for advertisement and notification messages on TCP port 2646. When a router needs to send a MulTreeLDP message to another router, it opens a new connection on port 2646 of the destination router. MulTreeLDP advertisement and notification messages consist of a MulTreeLDP header, a message header, and a series of Type-Length-Value (TLV) objects as illustrated in Figure 5.4. A TLV is a 3-tuple which contains the type of the message, the length of the value field, and a value field.

Figure 5.4: General format of a MulTreeLDP message. MulTreeLDP messages carry information in the TLV objects.

Our implementation of MulTreeLDP consists of three threads. The main thread handles all advertisement and notification messages. On reception of an advertisement message, the main thread can modify the FIB of the router and send other MulTreeLDP messages in accordance with the MulTreeLDP protocol described in the remainder of this section. The main thread can also perform switchback and switchover when it receives notification messages. The second and the third threads detect failures between a router and its neighbors in the multicast routing tree. The second thread sends link failure and recovery detection messages to every neighbor of a router while the third thread listens for these messages. In the remainder of this chapter, we describe the MulTreeLDP signaling protocol.

Multicast Explicit Routing

We now describe how MulTreeLDP supports multicast Explicit Routing. Explicit Routing is the technique which enables any node in a network to set up a LSP. This path is usually computed offline. MPLS uses Explicit Routing for traffic engineering purposes but so far no support for multicast routing trees has been defined. MulTreeLDP defines messages and procedures that enable Explicit Routing for core based trees. Our implementation can easily be modified to support shortest path trees. We denote by $S$ the core of the tree.

First we explain how a user can provide the description of a multicast routing tree that is understandable by MulTreeLDP. Users must write in a configuration file the multicast routing tree description before MulTreeLDP establishes the mLSP that maps the multicast routing tree. Multicast routing tree description files contain IP addresses separated by a ``,'' symbol, a ``('' symbol, a ``)'' symbol or a combination of these three symbols. We next describe the rules for describing multicast routing trees.

Trees must be described depth-first, starting from $S$. The IP address chosen for a router is the address of the interface via which packets would arrive if they were sent by $S$ over the multicast routing tree. The IP address of any interface of $S$ can be used for $S$. A ``,'' separates the IP addresses of two consecutive routers if the only router downstream of the first router of the expression with regards to $S$ is the second router of the expression. If a router has several children in $T$, then all subtrees of this router are successively described in the configuration file. The descriptions of the subtrees are put between a ``('' and a ``)'' symbol and the description of the first subtree follows immediately the IP address of the parent router. Subtrees are described using the above rules recursively. Let us take an example to illustrate the rules. Consider Figure 5.5 and tree $T_A$ rooted at $A$. The configuration file first contains any IP address of $A$. This IP address can be either 10.0.1.1 or 10.0.2.1. We arbitrarily choose 10.0.1.1 as the address that describes $S$ and write this address in the configuration file. Node $S$ has two children $B$ and $D$, therefore two subtrees $T_B$ and $T_C$ of $T_A$ originate from a child node of $S$. We put the description of these subtrees in brackets. The first subtree $T_B$ is constituted by node $B$ only. If packets are sent from $S$ to $B$ then they arrive at $B$ via the interface associated with IP address 10.0.1.2. Therefore $T_B$ is described by (10.0.1.2). The second subtree $T_C$ is the subtree of $T_A$ rooted at $C$. Node $C$ has only one child $D$ so the description of $T_C$ will start with (10.0.2.2,10.0.3.2. Then $D$ has three children $E$, $F$ and $G$ that are leaves of the tree, hence $T_C$ is described by (10.0.2.2,10.0.3.2(10.0.4.2)(10.0.5.2)(10.0.6.2)). Consequently the configuration file for $T_A$ contains:
10.0.1.1(10.0.1.2)(10.0.2.2,10.0.3.2(10.0.4.2)(10.0.5.2)(10.0.6.2)).

Figure 5.5: Description of a tree in a file and in a Explicit Route Tree TLV. Node $A$ is the core of the tree.

We now explain how MulTreeLDP builds the bidirectional mLSP that maps a multicast routing tree described in a tree configuration file. Any computer can establish an explicit mLSP. For example, a multicast routing tree can be computed by a computer offline and this computer can establish the mLSP. The computer responsible for establishing the tree first parses the configuration file. The computer creates an Explicit Route Hop TLV for each IP address found in the file, a New Branch TLV for each ``('' symbol and an End Branch TLV for each ``('' symbol. Then the computer responsible for establishing the mLSP creates an Explicit Route Tree TLV that contains all Explicit Route, New Branch and End Branch TLVs it has created in the order their corresponding entries were parsed in the file. In Figure 5.5, we show the contents of the Explicit Route Tree TLV (ER-Tree TLV) for the example developed in the previous paragraph. Also the computer creates a FEC TLV which contains the IP multicast address of the group for which we want to create the mLSP. Finally the computer sends an Explicit Route Request message that contains the Explicit Route Tree TLV and the previously created FEC TLV to the router designated by the IP address of the first Explicit Route Hop TLV. This IP address is the address of one of the interfaces of the core of the tree. The size of a multicast routing tree established with MulTreeLDP is limited by the maximum size of a TCP datagram.

Each child of the core is the root of a subtree of the multicast routing tree. When the core receives the Explicit Route Request message, it extracts the tree topology from the contents of the message. The core of the multicast routing tree builds a new Explicit Route Tree TLV that contains the description of one of these subtrees for each of its children. Then the core sends a Label Request Message that contains one of the Explicit Route Tree TLVs to the corresponding child. When a node $B$ receives a Label Request Message from a node $A$, it performs two actions. First, $B$ sends a label mapping to $A$. Node $B$ chooses a label, creates the corresponding Label TLV and sends to $A$ a Label Mapping message that contains the Label TLV. Because the mLSP that maps the multicast routing tree is bidirectional, node $B$ that sent the Label Mapping message also sends a Label Request message to $A$. The Explicit Route Tree TLV sent in this message contains only the IP address of the interface of $A$ on the link between $A$ and $B$. Node $A$ replies with a Label Mapping message. At that point, a bidirectional LSP is established between $A$ and $B$, or in this case the core and one of its children. Second, for each child $C$ of $B$, $B$ builds an Explicit Route Tree TLV that contains the description of the subtree rooted at $C$ and sends a Label Request Message that contains this Explicit Route Tree TLV to $C$. The mLSP formerly created between the core and its children is thus expanded until all leaves of the tree are reached. When all leaves of the tree are reached, the mLSP maps the entire multicast routing tree.

Figure 5.6: Advertisement of a multicast routing tree.

As an example, consider the tree depicted in Figure 5.6(a). Figures 5.6(b), (d), (f), (g), (h), (j), (l) depict the MulTreeLDP messages exchanges in the MPLS network while Figures 5.6(c), (e), (g), (i), (k), (m) depict the expansion of the mLSP that maps the multicast routing tree after a message exchange. Suppose node $A$ receives a Label Request message that contains the Explicit Route Tree TLV presented in Figure 5.5. Node $A$ sends a Label Request message to nodes $B$ and $C$ (Figure 5.6(b)). Both messages contain an Explicit Route Tree TLV. The Explicit Route Tree TLV that is sent to $B$ contains the IP address 10.0.1.2 of $B$. The Explicit Route Tree TLV that is sent to $C$ describes the subtree of the multicast routing tree that is rooted at node $C$: 10.0.2.2,10.0.3.2(10.0.4.2)(10.0.5.2)(10.0.6.2). At that point no label mapping is established yet as shown in Figure 5.6(c). Then, nodes $B$ and $C$ send a Label Mapping message to $A$ (Figure 5.6(d)). The portions of the mLSP that correspond to the label mapping established after $A$ receives the Label Mapping messages from $B$ and $C$ are shown in Figure 5.6(e). Also, node $C$ sends to $D$ a Label Request message that contains the Explicit Route Tree TLV which contains the description the subtree of the multicast routing tree rooted at $D$: 10.0.3.2(10.0.4.2)(10.0.5.2)(10.0.5.2). In Figure 5.6(f), nodes $B$ and $C$ send a Label Request message to $A$ in order to establish the second direction of the portions of the mLSP between $B$ and $A$ on the one hand, and between $C$ and $A$ on the other hand. The Label Request message sent by $B$ to $A$ contains the Explicit Route Tree TLV 10.0.1.1 and the Label Request message sent by $C$ to $A$ contains the Explicit Route Tree TLV 10.0.2.1. Node $D$ sends a Label Request message to $E$, $F$ and $G$. The Label Request message sent to $E$ contains the Explicit Route Tree TLV 10.0.4.2, the Label Request message sent to $F$ contains the Explicit Route Tree TLV 10.0.5.2, and the Label Request message sent to $G$ contains the Explicit Route Tree TLV 10.0.6.2. Node $D$ also sends a Label Mapping message to $C$ and establishes the portion of the mLSP from $C$ to $D$ as shown in Figure 5.6(g). In Figure 5.6(h), node $A$ sends a Label Mapping message to $B$ and $C$ and a bidirectional mLSP is established between $A$ and $B$ on the one hand, and $A$ and $C$ on the other hand. Node $D$ sends a Label Request message to $C$ to establish the other direction of the part of the mLSP between $C$ and $D$. The Label Request message sent by $D$ to $C$ contains the Explicit Route Tree TLV 10.0.3.1. Nodes $E$, $F$ and $G$ send a Label Mapping message to $D$ and the three corresponding mLSP portions are established. The new mLSP portions are depicted in Figure 5.6(i). In Figure 5.6(j), node $C$ sends a Label Mapping message to $D$. The part of the mLSP between $C$ and $D$ becomes bidirectional (Figure 5.6(k)). Nodes $E$, $F$ and $G$ send a Label Request message to $C$. In Figure 5.6(l), $D$ replies to $E$, $F$ and $G$ with Label Mapping messages to establish a bidirectional mLSP between $D$ and $E$, $D$ and $F$, and $D$ and $G$. The mLSP that maps the multicast routing tree is complete (Figure 5.6(m)).

Backup path establishment is very similar to mLSP establishment, except that unidirectional mLSPs are created instead of bidirectional mLSPs. When a computer wants to advertise a backup path, it sends a Backup Route Request message to each of the end nodes of the backup path. This message contains the FEC TLV that corresponds to the FEC of the protected multicast routing tree, the Explicit Route Tree TLV that corresponds to the backup path as described in Section 4.4, and a Routers TLV. Since a path can be viewed as a tree where every node has only one child, we kept the format of the Explicit Route Tree TLV to describe a backup path. Therefore the Explicit Route Tree TLV contains Explicit Route Hop TLVs only. The routers TLV contains all the IP addresses of MPLS routers interfaces on the protected path. Then, the node that receives the Backup Route Request message removes the first hop from the Explicit Route Tree TLV and sends a Backup Label Request message to the next hop of the backup path. The Backup Label Request message contains the new Explicit Route Tree TLV and the FEC TLV of the protected tree. When a node receives a Backup Label Request message, it sends another Backup Label Request message to the next hop of the backup path after it has removed a Explicit Route Hop TLV from the Explicit Route Tree TLV which describes the backup path. Also, this node sends a Backup Label Mapping message to the sender of the Backup Label Request message. The Backup Label Mapping message contains a Label TLV. At that point a label mapping is established in one direction between the first node and the second node of the backup path. Other mappings are established similarly with exchanges of Backup Label Request and Backup Label Mapping messages.

The process we have described establishes a LSP that maps only one direction of a backup path. Using the notations of Section 4.4, this path is for instance the path between PSL $A$ and node $S'$ via the backup path. In order to establish the second direction, the node that sent the Backup Route Request message needs to send a Backup Route Request message to the other end of the backup path. This second Backup Route Request message describes the reverse direction of the backup path, that is, the path between PSL $B$ and node $S'$ via the backup path.

Link failure and recovery detection

Link failure and recovery detection is implemented with two threads. Consider an MPLS router $A$. Every period $T_p$, the first thread of $A$ sends a probe to each of its neighbors on UDP port 2646. A node of the MPLS network can be an neighbor for $A$ with regards to several multicast routing trees. In that case, $A$ sends only one probe every period $T_p$ to this multiple neighbor. Router $A$ maintains a counter per neighbor and increments this counter by ``1'' every period $n T_p$ and puts the value of this counter in the probes. This counter value is the only payload of a probe (see Figure 5.7).

Figure 5.7: Link failure and recovery detection probe format. Probes have been kept as small as possible in order to decrease the failure or recovery detection time.

The second thread listens for probe messages on UDP port 2646. Every period $n T_p$ ($n\ge2$), the second thread checks the number of received probes for each neighbor. If this number is zero, then the link from $A$ to its neighbor has failed. Router $A$ has detected a link failure and sends link failure notification messages using the mechanism described in Section 5.2.3. Router $A$ internally records the link failure. When router $A$ receives a probe on a link recorded as failed, it immediately sends link recovery notification messages using the mechanism described in Section 5.2.3.

The payload of the probes is not used in our implementation of MulTreeLDP but can be used in future work for probe numbering to dismiss reordered or duplicate probes.

Link failure and recovery notification

When a node detects a link failure or a link recovery, it must notify the two PSLs of the mLSP of the event so that they can perform either a switchover in case of a link failure on the protected path or a switchback in case of a link recovery on the protected path. A node that detects the failure or recovery may be a LSR or LER for several mLSPs and does not know which routers are the PSLs for each of these mLSP, therefore it must notify all routers of each mLSP of the failure or recovery.

Suppose a node detects a link failure using the link failure detection mechanism presented in Section 5.2.2. After the link has failed, the node creates an IPv4 node TLV which contains the IP address of the interface on which the failed link is connected. The node then considers in turn each link from which it receives traffic, except the failed link. For each of these links, it builds a list of the labels of packets for flows forwarded from the considered link to the failed link. Then the node sends a Link Failure Notification message that contains the IPv4 node TLV and a Label TLV per label in the aforementioned list on all links except the failed link. When a node receives a Link Failure Notification message, it knows that all outgoing packets that are labeled with a label of the list embedded in the Link Failure Notification message will eventually be dropped due to the failed link. A node which receives a Link Failure Notification message acts as if the link through which it received the message had failed and builds a list of incoming labels for packets that are forwarded on this link. This node sends on every link, except the link through which it has been notified of the failure, a Link Failure Notification message which contains a Label TLV for each label of the list and the same IPv4 node TLV as the one it received in the Link Failure Notification message. The failure notification information is thus propagated by each node that detects the failure to all routers of all mLSPs that use the failed link.

Consider, for instance, the multicast routing tree topology from Figure 5.8(a) and the mLSP that maps the tree in Figure 5.8(b). Suppose that the link $BC$ between nodes $B$ and $C$ fails. Figure 5.8(c) shows the Failure Notification process. Both $B$ and $C$ detect the failure. Before the failure, node $B$ forwards packets labeled with ``2'' on link $BC$. Those packets are the packets labeled with ``1'' coming from $A$, and the packets labeled with ``3'' coming from $D$. The IP address of the interface of $B$ at the failed link is 10.0.1.2. Therefore, $B$ sends a Link Failure Notification message with an IPv4 node TLV containing the IP address 10.0.1.2 and the Label TLV for label ``1'' to $A$, and a Link Failure Notification message with an IPv4 node TLV containing the IP address 10.0.1.2 and the Label TLV for label ``3'' to $D$. When $D$ receives the Link Failure Notification message from $B$, it knows that the packets forwarded with label ``3'' will eventually reach the interface with IP address 10.0.1.2 and then will be dropped. Node $D$ forwards packets with label ``5'' coming from node $F$ on link $FD$ with label ``3''. Therefore, $D$ sends a Link Failure Notification message with an IPv4 node TLV containing the IP address 10.0.1.2 and the Label TLV for label ``5'' to $F$. On the other end of the failed link, node $C$ also detects the failure. Before the failure, node $D$ forwards packets with label ``14'' coming from node $E$ on link $BC$ with label ``12''. The IP address of the interface of $C$ at the failed link is 10.0.1.1. Therefore, $C$ sends a Link Failure Notification message with an IPv4 node TLV containing IP address 10.0.1.1 and the Label TLV for label ``14'' to $E$. At this point, all nodes of the mLSP are notified of the link failure. If the mLSP is protected by a backup path, then the end nodes of the backup path must perform a switchover.

Figure 5.8: Failure and recovery notification process.

There is no difference between the link recovery notification and link failure notification processes except in the type of the messages used. Indeed, the link recovery notification process uses Link Recovery Notification messages to notify the other nodes of mLSP whose traffic was forwarded on the recovered link before the failure. On the example illustrated by Figure 5.8(c), suppose that the formerly failed link $BC$ is repaired. Nodes $B$ and $C$ detect the recovery with the mechanism described in Section 5.2.2. Node $B$ sends a Link Recovery Message to node $A$ with the IPv4 node TLV containing the IP address 10.0.1.2 and a Label TLV for label ``1'', and a Link Recovery Message to node $A$ with the same IPv4 node TLV and a Label TLV for label ``3'' to $D$. When it receives the Link Recovery Notification message from $B$, $D$ sends a Link Recovery notification message to $F$ which contains the same IPv4 node TLV again and a Label TLV for label ``5''. Node $C$ also detects the link recovery and sends Link Recovery notification message to $E$ which contains the IPv4 node TLV for the IP address 10.0.1.1 and a Label TLV for label ``14''. At this point all nodes of the mLSP are notified of the link recovery. If the mLSP is protected by a backup path, then the end nodes of the backup path must perform a switchback.

Switchover and switchback

Consider a mLSP protected by a backup path and the associated protected path of the backup path. A PSL of a mLSP must perform switchover when itself detects the failure of a link of the protected path or when it is notified of the failure of a link of the protected path. Likewise, a PSL of a mLSP must perform switchback when it detects the recovery of a link of the protected path or when it is notified of the recovery of a link of the protected path.

When a node receives a Link Failure Notification message or detects the failure of a link attached to one of its interfaces, it first checks if it is a PSL for a mLSP that uses the failed link. PSLs are nodes which receive a Backup Route Request message. Backup Route Request messages contain the list of the interfaces that end a link of the protected path. We call failed interface the IP address contained in the IPv4 Node TLV of the Link Failure Notification message if the PSL received such a message, or the IP address of the interface at the failed link if the PSL itself detected the failure. If the failed interface matches one of the addresses previously received in the Router TLV of a Backup Route Request message, the PSL knows that one link on the protected path has failed and must perform a switchover. The switchover consists of modifying the MPLS forwarding tables of the LSRs and is performed instantaneously on each of the LSRs. Tables are changed such that all incoming traffic from the protected mLSP is forwarded also on the backup path.

Figure 5.9: Switchback and switchover. Modification of the forwarding tables at a PSL.

Consider, for example, Figure 5.9(a). Nodes $C$ and $D$ are the PSLs for the tree represented as solid lines protected by the backup path represented in dotted lines. The backup path consists of link $CD$ and the protected path consists of links $BC$ and $BD$. We study the behavior of PSL $D$ on failure and recovery of link $BC$ . When link $BC$ has not failed, $D$ forwards traffic from $F$ to $B$ and from $B$ to $F$ as shown in Figure 5.9(b) where only one direction of the backup path between $C$ and $D$ is represented. Packets coming from $B$ with label ``13'' are forwarded to $F$ with label ``15'' and packets coming from $F$ with label ``5'' are forwarded to $B$ with label ``3''. Node $C$ does not forward packets over the backup path (Figure 5.9(b)). When $D$ learns that it must perform switchover because a link of the protected path has failed, $D$ forwards packets with label ``13'' from $B$ both to $F$ using label ``15'' and over the backup path to $C$ using label ``14''. Node $D$ also forwards packets with label ``5'' from $F$ both to $B$ using label ``3'' and over the backup path to $C$ using label ``14'' (Figure 5.9(c)). When node $D$ learns it must perform switchback because the failed link has been repaired, it stops forwarding packets over the backup path as in Figure 5.9(b).

MulTreeLDP messages and TLV formats

The messages and TLVs in MulTreeLDP are similar to those in LDP and CR-LDP. We indicate for each message or TLV whether it is a modified CR-LDP message which has been amended or a new message. The general form of MulTreeLDP messages is a MulTreeLDP header, followed by a message header and any number of TLV objects (Figure 5.4). A TLV object itself consists of a TLV header which contains the type and the length of the TLV, and a payload which contains the value of the TLV.

MulTreeLDP header

Figure 5.10: MulTreeLDP header.

The Version field is set to 0x1. The Length is the length in bytes of the MulTreeLDP message, version and length fields of the MulTreeLDP message excluded.

We now give the format of all TLVs and messages presented in this chapter. MulTreeLDP TLVs and messages are compatible with CR-LDP. The ``u'' and ``unused'' bits that appear in the MulTreeLDP TLV and messages formats correspond to CR-LDP fields that are not used in MulTreeLDP.

MulTreeLDP TLV formats

FEC TLV

Figure 5.11: FEC TLV format.

Figure 5.12: FEC element format.

The FEC TLV, of type 0x0100, is adapted from CR-LDP. A FEC is defined in a FEC element by a prefix and a prefix length. For an IPv4 address like an IP multicast group address, the LDP specification [3] requires that the element type field is set to ``2'', the Address Family to ``1'' and the Host Address Length to ``4'' which is the number of bytes of the IP address. The host address is the IPv4 address of the multicast group described by the FEC element.

Label TLV

Figure 5.13: Label TLV format.

The Label TLV, of type 0x0200, is adapted from CR-LDP and contains a label number.

IPv4 node TLV

Figure 5.14: IPv4 node TLV format.

The IPv4 node TLV, of type 0x0805, is a new TLV and does not exist in CR-LDP. It contains an IPv4 address and is used in the notification messages.

Explicit Route Tree TLV

Figure 5.15: Explicit Route Tree TLV format.

The Explicit Route Tree TLV, of type 0x0900, is a new TLV and does not exist in CR-LDP. It defines a multicast explicit route tree. A multicast routing tree definition consists of New Branch TLVs (Figure 5.16), End Branch TLVs (Figure 5.17), and Explicit Route Hop TLVs (Figure 5.18).

New Branch TLV

Figure 5.16: New Branch TLV format.

The New Branch TLV, of type 0x0901, is a new TLV and does not exist in CR-LDP. It has no payload and therefore the length field is set to ``0''.

End Branch TLV

Figure 5.17: End Branch TLV format.

The End Branch TLV, of type 0x0902, is a new TLV and does not exist in CR-LDP. It has no payload and the length field is set to ``0''.

Explicit Route Hop TLV

Figure 5.18: Explicit Route Hop TLV format.

The Explicit Route Hop TLV, of type 0x0801, is adapted from CR-LDP. An Explicit Route Hop TLV contains the IP address in the IPv4 address field of an interface of a router part of an multicast route tree. The Prefix Length field is set to ``32'', which is the number of bits of an IPv4 address. If the ``E'' bit is set then packets received on this interface must be passed to the IP layer and the host can perform mixed L2/L3 forwarding.

Routers TLV

Figure 5.19: Routers TLV format.

The Routers TLV of type 0x0910 is a new TLV and does not exist in CR-LDP. The Routers TLV contains a list of Explicit Route Hop TLV.

MulTreeLDP message formats

Explicit Route Request message

Figure 5.20: Explicit Route Request message format.

The Explicit Route Request message, of type 0x0411, is a new message and does not exist in CR-LDP. Any router can send a route request message to initiate the creation of an Explicit Route Tree. The Explicit Route Request message must be sent to the core of the tree. The FEC TLV (Figure 5.11) contains the definition of the FEC for the advertised tree. The Explicit Route Tree TLV (Figure 5.15) contains the definition of the tree.

Explicit Backup Route Request message

Figure 5.21: Explicit Backup Route Request message format.

The Explicit Backup Route Request message, of type 0x0412 is a new message and does not exist in CR-LDP. Any router can send an Explicit Backup Route Request message to initiate the creation of a backup path. This message has to be sent to the first hop of the backup path. Two Explicit Backup Route Request messages must be sent to establish a bidirectional backup path. The FEC TLV (Figure 5.11) contains the definition of the FEC for the tree protected by the backup path. The Routers TLV (Figure 5.19) contains the IP addresses of interfaces at the end of links of the protected path. The Explicit Route Tree TLV (Figure 5.15) contains the definition of the backup path.

Label Request message

Figure 5.22: Label Request message format.

The Label Request message, of type 0x0401, is adapted from CR-LDP. A router sends a Label request message to request a label mapping for a LSP defined in the Explicit Route Tree TLV (Figure 5.15) associated to the FEC defined in the FEC TLV (Figure 5.11).

Backup Label Request message

Figure 5.23: Backup Label Request message format.

The Explicit Backup Route Request message, of type 0x0412, is a new message and does not exist in CR-LDP. This message is the same as Label Request message, except that the Explicit Route Tree TLV describes a backup LSP associated with the FEC defined by the FEC TLV.

Label Mapping message

Figure 5.24: Label Mapping message format.

The Label Mapping message, of type 0x0400, is adapted from CR-LDP. Label Mapping messages are sent from downstream nodes to upstream nodes for a given LSP. A Label Mapping message contains a label mapping in the Label TLV (Figure 5.13) for the LSP associated with the FEC defined in the FEC TLV (Figure 5.11).

Backup Label Mapping message

Figure 5.25: Backup Label Mapping message format.

The Backup Label Mapping, of type 0x0421, is a new message and does not exist in CR-LDP. This message is the same as the Label Mapping message, except that the label in the label TLV refers to the backup path associated with the FEC defined in the FEC TLV.

Link Failure Notification message

Figure 5.26: Link Failure Notification message format.

The Link Failure Notification message, of type 0x0501, is a new message and does not exist in CR-LDP. This message contains the IP address in the IPv4 node TLV (see Figure 5.14) of an interface on which a failed link is attached. It also contains a list of (incoming) labels in the Label TLVs (Figure 5.13) as explained in Section 5.2.3.

Link Recovery Notification message

Figure 5.27: Link Recovery Notification message format.

The Link Recovery Notification message, of type 0x0502, is a new message and does not exist in CR-LDP. This message contains the IP address in the IPv4 node TLV (see Figure 5.14) of an interface on which a recovered link is attached. It also contains a list of (incoming) labels in the Label TLVs (Figure 5.13) as explained in Section 5.2.3.