Hi Hubb,

Could you please let me know why we cannot use SDH at higher bit rates(100G) ? Is the FEC limiting factor?

Regards
krishna

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Hubb,

Thanks a lot for the Reply


I understand there are many intentions why we moved from SONET/SDH to OTN. One of the intention I see from many papers/Websites is scalability. "SDH is not designed and optimized to support massive capacity services such as 100GbE, 400G".

So what I am trying to understand is why SDH is incapable to support higher rates? Please clarify. Following are the few reasons I see. let me know if the reasoning is correct.

1.SDH doesn't support FEC. So Optical reach is less in SDH.
2.Complexing multi stage multiplexing nature of SDH compared to single stage multiplexing of OTN?
3.OTN uses fixed frame size but SDH changed the frame size as the bit rate increases.

Please throw some light on point 3 . What is the advantage we are getting because of fixed frame size in OTN compared to SDH.

Thanks
krishna

--
reply to hhelvooort with 2 'o's ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hell Krishna,

You wrote:

Could you please let me know why we cannot use SDH at higher bit
rates(100G) ? Is the FEC limiting factor?

ITU-T G.707 only defines STM-N up to N=256 (40Gbit/s).

STM-1024 would be the next candidate.
But has never been standardised.

The major reasons are that OTN (G.709) was developed and
the client signal bandwidth had grown to ± 1 Gbit/s.
There was no need anymore for VC-4 / 155 Mbit/s.

FEC was not an issue, see G.709, FEC is also used in OTN
at much higher bitrates.

Best regards, Huub.



--
reply to hhelvooort with 2 'o's ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Krishna,

You replied:

Thanks a lot for the Reply

You're welcome.

I understand there are many intentions why we moved from SONET/SDH to
OTN. One of the intention I see from many papers/Websites is
scalability. "SDH is not designed and optimized to support massive
capacity services such as 100GbE, 400G".

Indeed. The next logical steps for SDH would have been 160Gbit/s
STM-1024 and 640Gbit/s STM-4096.

However, in order to transport a 100GbE client signal a VC-4-640v
would have to be used. But that is not possible because VC-4-256v
is the maximum size of virtual concatenation.
There was no possibility to virtually concatenate VC-4-Xc.
The only option would be to use a VC-4-1024c but this will waste too
much bandwidth. (160Gbit/s to transport 100GbE).

So what I am trying to understand is why SDH is incapable to support
higher rates? Please clarify.

See above.

Following are the few reasons I see.
let me know if the reasoning is correct.

1.SDH doesn't support FEC. So Optical reach is less in SDH.

SDH does support FEC already in STM-16, STM-64 and STM-256.
SDh has the same reach as OTN.

2.Complexing multi stage multiplexing nature of SDH compared to
single stage multiplexing of OTN?

The granularity of SDH (VC12 and VC4) was becoming too small,
causing complexity in managing the network.

3.OTN uses fixed frame size but SDH
changed the frame size as the bit rate increases.

From a technical point of view this was not an issue.
The granularity of the containers was a much larger problem.
The smallest container size in OTN is 1.25 Gbit/s (ODU0).

Please throw some light on point 3 . What is the advantage we are
getting because of fixed frame size in OTN compared to SDH.

The main advantage is the "size" of the frame, and not the fact
that is is "fixed".

Mobile base stations used to have E1 interfaces which did fit
in a VC-12. Nowadays, due to the growth in bandwidth demand,
most mobile base stations have 1 GbE interfces, which fit into
an ODU0.

Best regards, Huub.



--
reply to hhelvooort with 2 'o's ================================================================
http://www.van-helvoort.eu/ ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Krishna,

You replied:

However, in order to transport a 100GbE client signal a VC-4-640v
would have to be used. But that is not possible because VC-4-256v
is the maximum size of virtual concatenation.

Yeah. This is my query. why didn't the standard get updated with
new rate of VC4-640v for 100G ?? what is that limiting the max
value to 256??

This would mean that the network manager has to set up 640 links
before the VC-4-640v can be used. This is very complex.

256 is the limit because there is only a single byte available
to identify the X individual members of the VC-n-Xv VCG.

There was no possibility to virtually concatenate VC-4-Xc.

OK

The only option would be to use a VC-4-1024c but this will waste
too much bandwidth. (160Gbit/s to transport 100GbE).

Understood w.r.t continuous concatenation but one basic question
why should the factor be always 4 ?? STM4,STM16,STM256,STM1024.
why not STM640 ??

The only other option would have been STM-512, which was not
useful and too expensive.

A new STM-640 would have resulted in the same problems as
ATM where there was no agreement on cell size of 32 or 64
bytes and finally 48 was chosen, again additional cost and
complexity.

Best regards, Huub.


--
reply to hhelvooort with 2 'o's ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, December 22, 2015 at 4:19:54 PM UTC+5:30, Huub van Helvoort wrote:

Hello Krishna,

You replied:

Thanks a lot for the Reply

You're welcome.

I understand there are many intentions why we moved from SONET/SDH to
OTN. One of the intention I see from many papers/Websites is
scalability. "SDH is not designed and optimized to support massive
capacity services such as 100GbE, 400G".

Indeed. The next logical steps for SDH would have been 160Gbit/s
STM-1024 and 640Gbit/s STM-4096.

However, in order to transport a 100GbE client signal a VC-4-640v
would have to be used. But that is not possible because VC-4-256v
is the maximum size of virtual concatenation.

Yeah. This is my query. why didn't the standard get updated with new rate of VC4-640v for 100G ?? what is that limiting the max value to 256??

There was no possibility to virtually concatenate VC-4-Xc.

OK

The only option would be to use a VC-4-1024c but this will waste too
much bandwidth. (160Gbit/s to transport 100GbE).

Understood w.r.t continuous concatenation but one basic question why should the factor be always 4 ?? STM4,STM16,STM256,STM1024. why not STM640 ??

So what I am trying to understand is why SDH is incapable to support
higher rates? Please clarify.

See above.

Following are the few reasons I see.
let me know if the reasoning is correct.

1.SDH doesn't support FEC. So Optical reach is less in SDH.

SDH does support FEC already in STM-16, STM-64 and STM-256.
SDh has the same reach as OTN.

I think this is valid when both as using same FEC.

2.Complexing multi stage multiplexing nature of SDH compared to
single stage multiplexing of OTN?

The granularity of SDH (VC12 and VC4) was becoming too small,
causing complexity in managing the network.

3.OTN uses fixed frame size but SDH
changed the frame size as the bit rate increases.

From a technical point of view this was not an issue.
The granularity of the containers was a much larger problem.
The smallest container size in OTN is 1.25 Gbit/s (ODU0).

Please throw some light on point 3 . What is the advantage we are
getting because of fixed frame size in OTN compared to SDH.

The main advantage is the "size" of the frame, and not the fact
that is is "fixed".

Mobile base stations used to have E1 interfaces which did fit
in a VC-12. Nowadays, due to the growth in bandwidth demand,
most mobile base stations have 1 GbE interfces, which fit into
an ODU0.

Best regards, Huub.

--
reply to hhelvooort with 2 'o's ================================================================
http://www.van-helvoort.eu/ ================================================================
Always remember that you are unique...just like everyone else...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)