Publisher:
Telstra Wholesale
Name:
Lost in the Ether(net)
Copyright Date:
01/03/2024
Copyrighted By:
Telstra Wholesale
Family Friendly:
Yes
Language:
English
Categories:

Lost in the Ether(net)


Lost in the Ether(net)

If you are tourist driving in South Africa, and happen to get lost you'll probably ask a local person for directions. There's a good chance you will be guided with the words "Turn left at the next robot, then…"  because your guide assumes you also know what a "robot" is. Now if you envisage an Asimov-style entity directing traffic at the junction, you'd be disappointed to find that it refers to the same green-amber-red device that the rest of the world calls a traffic light: that is, the same thing, but with a different name.


Similarly, in the Ethernet world some "lost in translation" opportunities present regularly because of assumptions, perhaps none more than around the classic question: "Does your product support Q-in-Q?"

In one scenario, an Ethernet service may support Q-in-Q simply by being able to transit a Q-in-Q frame. So if a double-tagged frame ingresses the local-end of the service, the same double-tagged frame egresses the remote end (call that scenario 1).

However, by asking about support, the inquirer might want to understand whether a single-tagged frame ingressing the local-end of the service egresses the remote-end as double-tagged (scenario 2). Both answers lead to further support questions because Q-in-Q means the outer-tag TPID (Tag Protocol Identifier) may be 0x8100, 0x9100 or 0x88A8. So unless all details are qualified, any answer is fraught with technical and commercial risk.

The optimal way to solve such lost-in-translation issues is by having agreed definitions around a shared understanding. In my view, this is where the hidden economic benefit of the MEF Forum's immense body of work becomes clear. By having an internationally agreed lexicon and well-defined Ethernet service-oriented specifications, there is no confusion. Much less chance of things going wrong means less time and money wasted.

So, in seeking an answer to the second scenario, someone fluent in MEF parlance would ask the question Does your product support the MEF-defined E-Access service type?. The MEF-informed answer would be a definitive "yes" or "no", with details like TPID already included around the agreed shared understanding and lexicon in the MEF specifications.

Telstra currently has 137 staff that are certified Carrier Ethernet Certified Professionals (CECP), which means they are MEF-literate. In regard to supporting Q-in-Q, Telstra Wholesale has recently augmented its current CE 2.0 certified MEF-defined E-Line services with the MEF-defined E-Access service type. And on the assumption that you've learned some MEF-speak by reading this, you now have an idea what that means. If you'd like to know more, check out the MEF 33 specification, read the MEF’s white paper on Ethernet Access Services or talk to one of Telstra's certified Ethernet professionals!

Mark Whalley
The Author Mark Whalley

Mark is a high-EQ senior technology-marketing manager with a results-plus-people outlook polished over 20+ years of industry experience. This acumen has been acquired via multiple diverse business-to-business (B2B) roles across the telecom space, in Australia, New Zealand and South Africa.

See all of Mark Whalley's posts


Related Articles

Recent Articles