EoMPLS Service provider QoS remarking

[siddiqirf]

Can a service provider remark CoS on customer traffic in a Point to point Layer 2 EoMPLS link ? Specially as we are going to encrypt the link via L2 encryptors on both ends, the service provider will have no visibility of our original frame until frame gets decrypted at each end.

Is this correct what i am thinking?

Can a service provider remark CoS on customer traffic in a Point to point Layer 2 EoMPLS link ? Specially as we are going to encrypt the link via L2 encryptors on both ends, the service provider will have no visibility of our original frame until frame gets decrypted at each end.

Is this correct what i am thinking?

[yashfaqu]

Hi,

SP can forward your traffic in MPLS-TE, and can do any kind of traffic engineering on this tunnel.

thats an easy way to do this.

Yasir

Message was edited by: Yasir Ashfaque

[Ivan Krimmel]

Hi there!

If I got it correctly, the setup is like this:

---data----CE----encryption----PE-------MPLS Cloud-------PE----encryption----CE----data----

so PEs will receive already encrypted L2 chunks, correct? In that's the case, original COS fields will be inaccesible and hence no remarking is possible. If, however, your concern is to somehow provide expedited forwarding across the MPLS core, then your SP will have to deal with L2/L3 marking of your xconnects.

I hope that clarifies, feel free to raise your other conserns if any.

Cheers!

[siddiqirf]

Thanks Ivan, this is exactly the setup and yes the PE's will recieve encypted L2 Chunks as you mentioned

The SP are providing us with a 10MB point to point link over the MPLS cloud. The thing is because the Frames will be encrypted, which means our DSCP and COS values will be encrypted when the PE recieves them, it will not be able to classify and queue them based on our marking. It can remark them, but then since the packet is encrypted there is no criteria it can use to classify them again.

In this case I dont think the SP will be able to deal with L2/L3 marking of our xconnects, or is there still a way to do it.

Hope this makes sense....

[Ivan Krimmel]

Hi Siddiqirf,

thanks for clarification.

Since 'your' xconnects will technically become their xconnects(SP's), I don't see any obstacles for an ISP to provide expedited forwarding for those packets.

Does that help or there is something unclear for you?

Cheers,

Ivan.

[siddiqirf]

But when the SP receives the frame on the xconnect on their PE, it will be encrypted. ie. they wont be able to see our qos (Cos or DSCP) markings.  So in this case how can they do any QoS treatment to our traffic...

[Ivan Krimmel]

it is easy, they do treat the xconnects in a preferred way.

Cheers.

[siddiqirf]

Yes but my point is that they cant treat our specific traffic anymore, for example voice, video, signalling, data, etc.. as that traffic will have no marking visibility.

The xconnect is a single point to point psuedowire link, so they can mark as traffic enters the xconnect, but because its all encrtyped data they wont be able to treat it in different classes...

Hope this makes sense..

[Ivan Krimmel]

I've got your point - your intension is to classify first, then treat accordingly. Then yes, it is tricky. I'm wondering - how does the L2 encryptor works - is it capable of doing a feature like 'QoS Pre-classify' in IOS? if it scrubs all the data, then I don't see a suitable workaround.

Cheers,

Ivan.

[siddiqirf]

Thats a good point. I will look into this. The other option is to run the L2 encryptor in Clear vlan header mode, which preserves the vlan tag information. But is less secure.

[Ivan Krimmel]

I am not big in Security, just thinking that exposing vlan headers to an ISP shouldn't be a big risk.

Cheers!