QoS vs CoS in Metro Ethernet environment

[worldnews7]

Guys, 

I've been doing this for a little while, however my conscience is nagging me about a few concepts I feel I should have mastery over in the Metro Ethernet environment. 

The crux of the matter is that no matter how many times I read lengthy CoS vs QoS literature, I still seem to be having trouble grasping the context in --- let's say a Metro Ethernet environment, hub and spoke, where the ISP handles the core (like VPLS), and just gives a L2 hand-off at each site. 

I understand that to achieve QoS, the traffic needs to first be classified, hence CoS. What I don't know is what is being used when (for example) a frame from our L3 switch hits the Service Provider's switch (at L2 handoff). Seeing how the SP switch has to reference the VLAN tag of the frame to classify ---- let's say for voice priority --- how does that process go ... step by step?

Does a voice frame hit the SP switch, the SP switch analyze 802.1q strip the MACs and forward, or since the SP is probably using MPLS, does it maintain the tag, and shoot it through the Metro the other (destination) site ... then ... what does the other side do? 

It seems like the only context for QoS/CoS is sending the packet/frame out with priority ... I don't see anything special occurring on the recipient switch ... just normal 802.1q and inter-vlan routing. 

I understand the above is a bit scattered, but so is my brain on this topic. I appreciate your patience in advance, and please explain in a practical/elementary sense ... using the Metro Ethernet topology/model. 

Thanks!

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

For starters a frame or packet doesn't need a (CoS/QoS) tag for special treatment.  Other contents of the frame or packet might be used.  The purpose of tagging a frame or packet, is it reduces the need to "deeply" analyze a frame or packet at subsequent "hops".  I.e. special treatment can be based on the tag; it's done for processing efficiency.

You appear to be aware that VLAN headers support tags, and so do IP packet headers, but you might not be aware, MPLS headers also support their own service treatment tags.

Basically, generally some process, which can be the source, tags the frame/packet for desired service treatment.  "Hardware" at each hop, might use that tag, to treat frames/packets differently.  Some hops will strip the header that contains the tag, because of the nature of the tag.  E.g. L2 VLAN tagged frame making a L3 jump.  Such hops, may, or may not, generate a similar tag on the other side of the hop.  Some hops might also just generate a lower protocol header tag based on at higher level protocol header tag.  For example, an IP packet with a DSCP EF tag, might generate a VLAN CoS 5 tag.

The forgoing is generic.  MetroE, as it uses Ethernet, tends to use Ethernet VLAN header CoS tags.  Again, it doesn't have to.  Also, with any CoS/QoS, it's all network dependent for any actual different service treatment.  Service treatment is usually dependent on what the MetroE hardware can support.  I.e. "what it does", is a "it depends" answer.

[worldnews7]

There's some good info above, and I appreciate you replying. Maybe I can be a bit more specific about scenario to bring greater context:

• Comcast "ENS" (Ethernet Network Service)

http://business.comcast.com/ethernet/products/network-services-technical-specifications

• Boasts of VLAN transparency, and allowing for 3 different CoS options, CoS 5 being the "Premium" option. 
• State they preserve the VLAN/CoS values from end-to-end (aka between Metro sites)

• At the edge of sites, Comcast uses a Ciena device for L2 handoff, we on the other hand use a legacy Catalyst 3560G with inter-vlan routing, multi-vlan access ports/voice vlan for phones, etc, pretty typical.

Now that I've given a little more context, my question is simple: 

I don't hear mention of anything QoS related in Comcast's Metro description, but only mention of preserving the CoS. It's the mechanics that are confusing me a bit ... that is, how (step by step) the frame will get treated with priority between our two sites. I'm not as interested (at least in this dialog) in the MPLS action at ISP level, as much as I am understanding the basic mechanics of QoS/CoS in this scenario. 

Scenario:  

3560G (Client Site A)       (ISP Ciena A)                            (ISP Ciena B)       3560G (Client Site B)

10.11.2.2 <--------------------> 10.11.2.1 --------METRO------10.12.2.1-----------10.12.2.2

So here comes the flurry of questions:

• In the realm of Cisco how would voice vlan traffic from Client Site A to Client Site B ... with only CoS preserved as stated by Comcast?

• Doesn't QoS actually do the prioritizing and need to be configured on both sides (3560G's)???

• I've read about QoS stripping CoS value in general literature, so now I'm confused how Comcast would use CoS, if our 3560g is forwarding frames only with QoS/DSCP in the packet headers to the Ciena device???

• ... or by virtue of having the Ciena device as our 3560g's default gateway, does it learn that (MAC) and forward the frames with the CoS header in tact, which is subsequently forwarded (transparently) through the Metro ---- to other side, aka Client Site B for example???

Apologies for lack of clarity, but I'd rather express my confusion on this topic, because I really want to nail this concept before considering myself a campus engineer. I guess rites of passage :)

Thanks!

[Joseph W. Doherty · Accepted solution]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I haven't actually used the Comcast MetroE offering, but I been reviewing it, for possible usage, so I can comment a bit on how I understand its QoS support.

What I understand, Comcast's MetroE can optionally support QoS via 3 CoS classes.  For a MetroE circuit, you would "buy" a certain amount of bandwidth, for each of those 3 CoS classes.  Each class has its own SLAs, which comprise latency and maximum packet drops.  (Better classes are "guaranteed" lower latency maximums and lower maximum drop percentages.)

How Comcast determines, which of its three CoS service levels you intend a frame to obtain, depends on the frame's VLAN CoS tag marking (as you provide it to Comcast).

Comcast shouldn't change your frame's CoS tag and/or the packet's ToS tag.

To your questions:

#1 not really any differently from how you might pass VLAN CoS tagged packets within your own LAN.  Every physical hop/interface has the option to provide different service levels based on the CoS tag.  Since I believe Comcast's MetroE runs over a MPLS infrastructure, they probably map a frame's CoS tag into a MPLS QoS tag (and/or IP ToS tag), so they can treat different CoS classes, differently, if they hit a congested interface.

#2 "It depends".  Some VoIP phones can directly generate VLAN headers with CoS markings.  If so, all your network needs to do, if those marking conform to how Comcast's MetroE will treat them, is pass them along, as is.  No additional "QoS" is required, although you may want your network to also provide better treatment to VoIP packets.

#3 Yea, older Cisco switches, by default, pass along QoS markings as is, if the switch doesn't enable "QoS".  On those switches, if "QoS" is enabled, they will clear QoS tags unless you explicitly configure the devices to "trust" them.  (Reassignment is possible too.)  Again, as the Comcast MetroE service is looking for certain CoS tags (if so provisioned), you would need to insure the "correct" marking are contained by the VLAN tagged frames as they are handed off to Comcast.

#4 I'm unsure, as I would expect the Comcast device to "trunk" to your device.