TLVs and Sub-TLVs Supported for Point-to-Multipoint LSPs Connectivity Verification at Egress Nodes

To enable detection of data plane failures using the ping mpls and trace mpls commands at egress nodes of point-to-multipoint LSPs, JunosE Software supports two new TLVs, Echo Jitter and P2MP Responder Identifier. Also, a sub-TLV, RSVP P2MP IPv4 Session, is supported in the Target FEC Stack TLV to verify MPLS connectivity to egress nodes of point-to-multipoint LSPs.

Echo Jitter TLV Operations

The initiator (ingress) of a ping request might require the responding egress to introduce a random delay (or jitter) before forwarding the response. The delay period enables the responses from multiple egresses to be spread over a time period. This mechanism is very useful in situations when the entire LSP tree is being pinged because it helps the ingress (and nearby routers) node from being flooded with a number of responses, or from discarding responses if any rate limits are applied on the incoming traffic.

In JunosE Software, the delay is set to a maximum of 30 seconds. The ingress node informs the egresses of this time interval limitation by supplying a value in the Echo Jitter TLV in the echo request message. If this TLV is present in the echo request packet, the responding egress node delays sending a response for a random amount of time between zero milliseconds and 30 seconds that is predefined for this TLV. If the TLV is not contained in the echo request packet, the responding egress node does not create any additional delay in responding to the echo request. The Echo Jitter TLV is valid only in an echo request message. If this TLV is included in an echo response message, it is ignored. The Echo Jitter TLV is assigned the TLV type value of 12.

P2MP Responder Identifier TLV Operations

You can select the egress node in a point-to-multipoint LSP for which you want to trace the path from an ingress node and detect network failures by including a P2MP Responder Identifier TLV in the echo request packet sent to the egress node. The initiator can determine whether only the node identified in the TLV must respond or any node on the path to the selected egress node in the TLV needs to respond. If you do not include the P2MP Responder Identifier TLV in an echo request packet, all egress nodes in the path to the ingress node respond to echo request packets.

If the node is an egress of the P2MP LSP, the node checks whether it has received a P2MP Responder Identifier TLV in an echo request. If a P2MP Responder Identifier TLV is contained in the received echo request, the node uses the sub-TLVs contained in this TLV to determine whether it must respond to the request. If the P2MP Responder Identifier TLV is not present (or does not contain any sub-TLVs), the egress node responds to the echo request depending on the setting of the Response Type field in the echo message.

The P2MP Responder Identifier TLV is assigned a type number of 11. The P2MP Responder Identifier TLV is valid only in an echo request message.

Four sub-TLVs are defined for inclusion in the P2MP Responder Identifier TLV in the echo request message. Table 53 lists the sub-TLVs supported for the P2MP Responder Identifier TLV.

Table 53: Sub-TLVs Supported for the P2MP Responder Identifier TLV

Subtype Number

Value

Comments

1

IPv4 Egress Address P2MP Responder Identifier

The IPv4 address in this sub-TLV is the IPv4 address of the egress node and does not specify the IPv4 address of a branch or intermediate node.

2

IPv4 Node Address P2MP Responder Identifier

The IPv6 address in this sub-TLV is the IPv6 address of the egress node and does not specify the IPv6 address of a branch or intermediate node.

3

IPv6 Egress Address P2MP Responder Identifier

The IPv4 address in the sub-TLV might be of any physical interface or the router ID of the node itself.

4

IPv6 Node Address P2MP Responder Identifier

The IPv6 address in the sub-TLV might be of any physical interface or the router ID of the node itself.

The echo response is always controlled by the Response Type field in the echo message and also depends on whether the responding node is part of the point-to-multipoint LSP that is denoted in the Target FEC Stack TLV. The following sections describe the sub-TLVs of the P2MP Responder Identifier TLV, which are additional influencing factors to those requirements and are not a replacement for those requirements:

Egress Address P2MP Responder Identifier Sub-TLVs

You can use the IPv4 or IPv6 Egress Address P2MP Responder Identifier sub-TLVs in an echo request that contains the RSVP P2MP Session or Multicast LDP FEC Stack sub-TLV. An egress node that receives an echo request with this sub-TLV present responds only if the node lies on the path to the address in the sub-TLV. The address in this sub-TLV is the address of the egress node and does not specify the address of a branch or intermediate node. This address is made available to the nodes upstream of the target node, using signaling protocols, such as RSVP. This sub-TLV may be used to trace a specific egress node in a point-to-multipoint LSP.

Node Address P2MP Responder Identifier Sub-TLVs

You can use the IPv4 or IPv6 Node Address P2MP Responder Identifier sub-TLVs in an echo request that contains the RSVP P2MP Session or Multicast LDP FEC Stack sub-TLV. A node that receives an echo request with this sub-TLV present responds only if the address in the sub-TLV corresponds to any address that is local to the node. This address in the sub-TLV might be of any physical interface or the router ID of the node itself. The address in this sub-TLV can be the address of any transit, branch, or egress node for that point-to-multipoint LSP.

Related Documentation