jsharma

Pro-Active and On-demand CV (Connectivity Verification) in MPLS-TP

Discussion created by jsharma Employee on Feb 14, 2017
Latest reply on Feb 21, 2017 by jsharma

Pro-Active and On-demand CV (Connectivity Verification) in MPLS-TP

 

A tunnel can be thought of as a service, which provides you the capability that if you pump-in traffic at a particular source, you get the data out at a certain destination. This is  just analogous to a road tunnel in hilly areas, you enter the tunnel at a certain point and tunnel makes you come out at a certain point. In data transport network this tunnel functionality can be realised by a number of different ways, LSP tunnels, GRE tunnels are few of them.

 

In MPLS, an LSP is the means to realise the service or to realise the tunnel in action, by creating a label switched path traversing a number of nodes in between, all forwarding the traffic based on Labels. An LSP can be thought of as an instance of a tunnel, a means to realise the tunnel as an end-to-end service. To identify an LSP uniquely, combination of following parameters is used and should be unique:

 

  • Source Node Identifier (Generally the router-id/loopback interface)
  • Destination Node Identifier (Generally the router-id/loopback interface)
  • Tunnel Id or Tunnel Number (Unique in context of a pair of nodes, i.e. source and destination as identified above)
  • LSP Id or LSP Number (Unique in context of the tunnel, need not be globally unique)

 

The above 4 parameters are used to uniquely identify an individual LSP in global context. When RSVP-TE is used to signal MPLS LSPs, an additional parameter (because of inheritance from RSVP) is also used, i.e. “Extended Tunnel Id”, which can either be set to ZERO or same as Source Node Identifier. (Please see my earlier post [MPLS RSVP-TE Tunnel and LSP - Mind You, They are Not Same])

 

Now talking about OAM, when an MPLS LSP fails to fulfil its intended purpose, or in words fails to deliver user traffic, the failures can’t be detected entirely through control plane. Some tools are needed which can actually exercise the data path and check its end to end sanity. In addition, these tools should also help isolate or localize the faults.  RFC 4379 defines the procedures for detecting data plane failures in MPLS Label Switched Paths. Information is carried in “Echo Request” and “Echo Reply” packets. These are not the conventional IP Echo packets, but the purpose is similar. In addition, this RFC also defines procedures for verifying and cross checking data plane against control plane. By verifying whether control plane and data plane are in sync or not, the egress router for an FEC verifies whether for a received MPLS packet, it is actually the egress router for this FEC or not. The basic idea is to verify that packets that belong to a particular Forwarding Equivalence Class (FEC) actually end their MPLS path on a  Label Switching Router (LSR) that is an egress for that FEC. For verifying this information, the receiving router can’t entirely rely on the incoming MPLS label, so the FEC information needs to be encoded in the probe packets itself. This is also needed in case of PHP, where EXPLICIT_NULL or IMPLICIT_NULL labels are used and the information can’t be gleaned from the label stack. RFC 4379 defines the FEC definition for various MPLS paths, like RSVP-TE signaled LSPs, LDP LSPs, PWs, BGP VPVs etc. In addition, RFC 6428 defines FEC definition for Static LSPs, PW end points and Sections.

 

In MPLS-TP, two basic standards govern the procedures and functions used in CV (Connectivity Verification):

  •  Proactive CV - For BFD CV (Connectivity Verification) according to RFC 6428, in addition to traditional BFD CC (Continuity Check) [GACH type 22 for CC and 23 for CV, with CC at TX/RX of negotiated BFD interval, CV at one second frequency]
  • On Demand CV - For Target FEC Stack validation as per RFC 4379/RFC 6426 in MPLS Ping and Trace-Route

 

Ciena SAOS implementation is compliant with both these RFCs except that T3 devices do not support BFD CV in HW offload mode. Additionally for backward compatibility to older BFD implementations (which do not support CV mode and use an older GACH channel type, GACH_TYPE can be set to 7 at global level in SAOS). Please note that all these procedures explained in context of an LSP are also applicable to PWs and MPLS-TP sections.

 

In subsequent post, I will try to capture how the above mentioned information (to identify and validate the FEC) is used in Connectivity Verification (CV), both BFD CV and MPLS Ping, for MPLS LSP, PW and Sections.

Outcomes