Synchronization in carrier class Ethernet

That would be a fair statement. There has been some work on the support of circuit emulation services over Ethernet which addresses some of the issues around providing support for synchronous services over an asynchronous infrastructure.

Bonsoir anoop,

Thanks to recall me that interesting white paper. I just read it once, and I probably have to read it several times... because of the age.

Perhaps we will see soon VoE (voice over Ethernet).

Regards, Michelot

Bonsoir Michelot. The paper Annop pointed out,

states requirements but not how they're going to be met. It seems to me that if the Ethernet underlying service is much faster than the TDM or otherwise synchronous service layered over it, this TDM over metro Ethernet can be made to work. In the extreme, you could use GPS at the source and at the destination, to regenerate clock. That would be a true isochronous system (same clock through the net). If the Ethernet is fast enough compared to what you're sending over it, the slack could be used just like those stuffed bytes (whatever they're called) in SONET/SDH.

Albert

Yes. AFAIR the clock variation allowed for Gig Ethernet is +/- 100 ppm

however - there is a standard(s) for Ethernet across SDH (part of generic framing procedure)

this is used at work since the current network is SDH......

Because there is a mismatch in the Ethernet and SDH system designs, there is

1 timing issue - gfp seems to have outbound packets from a mux effectively clocked from the internal SDH clock (so the 1st hop becomes sort of synchronous). Inputs are clocked by whatever device is driving the link.

So you can have a "wire speed" link where the incoming packets are clocked a bit faster than a notional Gig Ethernet, but the output is 1000 Mbps more or less exactly and at some point you lose packets within the emulated wire.

this is what must happen within an ordinary Ethernet switch as well - but it threw me the 1st time we found it.

Bonjour Albert,

Albert Manfredi a =E9crit :

There are other documents more practical.

The Y.1413 (03/2004) recommendation from ITU-T explains how to transmit TDM signals through MPLS networks not done for that.

RFC3985 dicuss how to emulate TDM services over packet switched networks.

Even with rapid spanning tree, SDH with GFP will remain always faster than Ethernet. The TDM signals are not only PDH or n x 16 kbit/s, but also SDH and OTN.

You're right, it is one of the four solutions explained in figure

10-2/Y.1413. You can have a same reference clock (e.g. GPS) at the interworking function between the asynchronous network and TDM synchronous network. And, by this way, to have a hierarchically distributed and precise timing between the both TDM domains separated by an asynchronous network.

Ok

You want to define another SDH. And this case could be 10Gbase-W, with SDH framing.

Best regards, Michelot

Bonjour Stephen,

And, for 10GBase-W, accuracy is +/- 20 ppm. Asynchronous clock concept is different from accuracy.

Yes, G.707 and IEEE 802.3 (12/2005) for 10GBase-W G.7041 for other rates through GFP adaptation.

Are you working in a service provider compagny?

The mismatch is only for 10GE, not for 1GE.

And, you have 2 solutions, either improve the 10GE interface timing to

+/- 4.6 ppm, either let GFP source dropping sometimes characters between frames and, at the sink end, adding them to get back the original flow. Classical SDH is done to adapte this interface.

GFP is fully adapted to treat 8B/10B 1000 Mbps over VC-4-7v, without packet loosing.

Best regards, Michelot

My guess is that as VOIP services become more and more prevelant, CESoE will become less important. WE sank a small amount of money into boxes from RAD to do DS1 over ethernet for our PBX networking trunks, only to have the vendor release support for native IP network trunking before we completed our deployment. Simplified things so much that it made sense to go back and pull what we had already deployed and replace it with pure ethernet/IP capable systems (which simply meant buying a licsense and a software upgrade). Anyone in the market for a set of RAD IPMUXen?

I pray for the day when the telecoms shift towards ethernet away from ATM, SOMET, TDM, etc. If it hapopens (I can dream, can't I?) then CESoE

*WILL* be important for supporting "legacy" stuff over the new infrastructure, of course. And my life will be simpler.

Um, wouldn't VoIP qualify as that, since IP can run over ethernet quite well?

Bonsoir Snertking,

CESoE is e.g. to link TDM islands through the Ethernet networks.

I'm not sure you will find Ethernet in submarine cables, in long haul networks.

Best regards, Michelot

Bonsoir Snertking,

Do you want something like that?

(1) Classical VoEth (VoIP over 802.3 Ethernet) and, (2) VoEth NG (new generation, voice directly over 802.3 Ethernet through MPLS stack, and MACsec)

Best regards, Michelot

Yes.

the issue is that an outbound Ethernet Gig Eport is locked to the SDH clock of the final hop mux

inbound GigE is locked to the transmit clock of the last Gig E device - in our case a Cisco or other layer 3 switch. The 2 clocks dont run at the same speed, so at some point the pipe may have to drop packets.

it might be an issue with the kit we are using (Marconi OMS1684).

yes - we are using 7 * VC-4, which gives around 1050 Mbps thru the SDH network.

But if the inbound traffic is clocked at 1000 Mbps + 100 ppm, and the outbound is very close to 1000 Mbps, something has to give at sustained 100% load....

Submarine cables normally carry WDM channels. I don't know if there are such cables today carrying 10 Gbps Ethernet over WDM channels - but I certainly expect this to happen soon if it hasn't already. On the other hand, SDH definitely has its advantages still (rapid failure detection being one of the things I miss the most in Ethernet at the moment - BFD is *not* a sufficient replacement).

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

No reason you couldn't. OK, STANDARDS are a bit of a barrier - 10Gig ethernet ER is what, 40 kilometres? Extreme makes some stuff that will do 80 Kilometres. Still to short, but I see no technical reason why one couldn't make fiber optic tranceivers to drive the signal further.

Yup. But TDM is becoming irrelevant. To slowly for my tastes, but it

*is* happening. Hopefully happening with circuit swicthed networks as well.

The CPE side of the world is moving towards ethernet for voice, and has in fact prefered it for data from the start. Why go through the trouble of taking the customers ethernet and encapsulating into DSx and/or SONET and running it through ATM switches?

Already have something like that. Works quite well.

Forgive my ignorance, but:

I just don't get MPLS. Except for use with circuit switching stuff where it is bridged with packet swicthing stuff. Which is my whole point - circuit switching technology is the wrong way to go long run. Nortel seemed to realize that awhile back when they EOL'ed most of their ATM switching gear.

At the backbone, I see no reason why swicthing should not occur at layer three. Properly desgined IP internetworks with a decent link state protocol to provide fast failover work quite well IME. The MAN I managed at $dayjob fails over fast enough (using OSPF) when a link fails that you can't tell at all when your voice call is re-routed. Not to mention the fact that OSPF will load balance over multiple paths (not just over multiple links).

This is all IP, mostly done over ethernet, with a few pt to pt ds1's doing IP over PPP.

I'd just as soon replace these with ethernet fiber - and I am in the process of doing so. Local Ilec wants an order of magnitude more $$$ to do this than the fiber provider we found to do the job. $5000.00 a month to get a fiber ethernet into the telco's ATM backbone (they refuse to supply dark) vs about $300 a month for us to have pt to pt dark fiber from the folks we went with. $300 a month is what our ILEC charges a month for an intraoffice pt to pt ds1! 750X the bandwidth for the same money! What *IS* SBC smoking? They are teed off they are losing our business, but what did they expect given their pricing models? And to top it all off, they have the odacity to INSIST that linking our sites via their ATM backbone at 1 GIG is going to be faster than pt to pt fiber gig ethernet runs?!?!

The telco's just don't seem to "get it".

Some of the reasons why the service provider I work for uses MPLS:

- The ability to deliver L2 point to point (essentially, leased line replacement).

- The ability to deliver L3 VPNs.

- Well defined traffic engineering facilities.

We could probably have done this using other techniques also (for instance L2TPv3), but MPLS seemed to us to be the most logical choice for our requirements. Other providers have reached different conclusions.

Steinar Haug, Nethelp consulting, snipped-for-privacy@nethelp.no

Bonjour Steinar,

We have to take care ro the difference beween both concepts: physical Ethernet (as specified in IEEE 802.3), and Ethernet over transport network (as specified e.g. in ITU-T G.8012).

We never found in submarine cable physical Ethernet with 10 Gbps wavelengths. And the 10GBase-W (with SDH framing) is not done to connect two MSSP platforms, it's a router interface through UNI.

But, perhaps, we can find Ethernet over an OTN network (i.e. MAC mapped in ODUk), instead of a SDH network. In this case, we have a WDM group fully managed. The possibilty of OTN is 10 Tbps, with a group of 256 wavelengths of 40 Gbps.

The BFD generic application draft expires this month. I'm not an expert of that, I just understand that it is a service which can run over any protocol.

In other time, we thought that RPR could also replace SDH. Today, nobody has deployed it in large networks, and it is dropped.

Regards, Michelot

snertking a =E9crit :

Refer Steinar comments and reply

It's not to short. For STM-64 (10 Gbps) you have V-64.2 and V-64.3 optical interfaces, with 120 km length of G.652 or G.653 fibre. The reason is not length, but OAM.

Regards, Michelot

Bonjour Stephen,

You want to have synchronous Ethernet with SDH, why? The GFP procedure is made to support the asynchronous timing of Ethernet.

Regards, Michelot