PIPE MODE EXPLICIT NULL

[gauravprakash]

Hi,

For Pipe mode Diffserve tunneling, why do I need to use explicit null label for my MPLS VPN customers. The main objective is to be transparent in regards to DSCP marking of IPv4 packets from one CPE to other CPE of a VPN.

My understanding is that I will always have a label on egress PE , which can be used to dispose the IP packet based on the original EXP in the VPN label.

Regards,

Gaurav Prakash

[swaroop.potdar]

Hi,

If you go by the RFC 3270 Pipe model cannot exist with PHP in place. But Cisco's implementation of Pipe for MPLS VPN is with PHP, thats because using the internal marking mechanism which is local to the router (qos-group) it achieves what is desired as the right behaviour by the RFC 3270. Hence the Explicit null label is not required if Pipe is implemented on Cisco devices.

From the RFC point of view the motivation behind having outer core label intact is to convey the outer diffserv till the egress as the egress is supposed to take forwarding decisions based on the outer diffserv value, if PHP is carried out on the Penultimate router then this value is lost, but from Cisco persepctive the same is achieved using qos-group marking for the popped label and the value is copied onto the freshly exposed underneath label when forwarding out to the egress PE. Again same method if used on the egress PE to classify the outgoing IP packet as per the received EXP from the penultimate router.

Although this is not applicable if the implementation is not MPLS VPN model but IP over MPLS where you only have a single label throughout, in this case Explicit null is required as the EXP value is to be conveyed till the egress.

(see the FAQ link below)

Here is a link for different diffserv models configuration in Cisco with illustration if you see the configurations for Pipe model it will be more clear.

Here is a link for RFC 3270, which explains the conditions to be met for Pipe model to be implemented.

Also take a look at this FAQ for MPLS QOS.

http://www.cisco.com/en/US/tech/tk828/technologies_q_and_a_item09186a00800a43f5.shtml#wp27407

HTH-Cheers,

Swaroop

[gauravprakash]

Thx Swaroop. I assume that normally the EXP bits on both VPN & LDP label ( topmost labeL) wil have same EXP bit value, so even if LDP label is popped on the Pen-Ultimate router, the Egress PE still recevies VPN labeled packet which will have same EXP value. And this value can be used to dispose the IP packet. Is my understanding right?

one personal question (if u dont mind) ..r u bangalore based..?

Thx again,

Gaurav Prakash

[swaroop.potdar]

Gaurav,

Here are the links which i missed to post.

"Here is a link for different diffserv models configuration in Cisco with illustration if you see the configurations for Pipe model it will be more clear.

http://www.cisco.com/en/US/tech/tk436/tk428/technologies_tech_note09186a008022ad7e.shtml#pipe

Here is a link for RFC 3270, which explains the conditions to be met for Pipe model to be implemented.

http://tools.ietf.org/html/rfc3270#section-2.6

"

Now its true that the default mode is to trust the incoming DSCP/PREC and impose labels with the corresponding EXP value. But with Pipe model our diffserv domain is transparent to the end user and does not coexist with the end user diffserv model.

In Pipe mode with your Core QOS in place if you do re-coloring of the EXP value in transit through your core for your implemented PHB, then this value is imposed on the top label and not passed on to the lower labels. If this label is popped this value can be lost. But we need this value as in PiPe model we have to do the final egress forwarding based on the EXP value which was received on the top label after recoloring. (Refer the RFC 3270 link for more details on conditions to be met for Pipe)

Hence we can either note the value and pop the label and then write that value on the newly exposed label beneath or dont pop the label but swap it with an explicit null label with same EXP and forward towards the egress.

The configuration guide link with different diffserv modes can be referred for more clarity.

HTH-Cheers,

Swaroop

I am based out of NYC. Used to be in Mumbai 2 yrs before. :-)