• SDH mapping over OTN

    From krishna G@21:1/5 to All on Tue Dec 22 00:14:16 2015
    Hi Hubb,

    I think it is possible to change the ODUFlex container size as per G.7044 [G.HAO or Hitless adjustment of ODUflex(GFP)].

    So can you please explain how how clock synchronisation is maintained during bandwidth resizing in the middle OTN nodes.

    Thanks
    krishna

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Huub van Helvoort@21:1/5 to This time you on Tue Dec 22 11:54:45 2015
    Hello again Krishna,

    This time you write:


    I think it is possible to change the ODUFlex container size as per
    G.7044 [G.HAO or Hitless adjustment of ODUflex(GFP)].

    Correct.

    So can you please explain how how clock synchronisation is maintained
    during bandwidth resizing in the middle OTN nodes.

    Intermediate nodes are not aware of the ODUflex, they do not know
    wich ODU0 belongs to an ODUflex, or which ODUflex.
    The resizing of the ODUflex is using a protocol that is using the
    overhead of the ODUflex. Only the end points are aware of the change.
    The timing information is part of the client signal, so it will
    not be aware of any bandwidth resizing.

    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)
  • From khrbji@gmail.com@21:1/5 to Huub van Helvoort on Thu Feb 1 02:10:51 2018
    On Tuesday, December 22, 2015 at 2:54:46 PM UTC+4, Huub van Helvoort wrote:
    Hello again Krishna,

    This time you write:


    I think it is possible to change the ODUFlex container size as per
    G.7044 [G.HAO or Hitless adjustment of ODUflex(GFP)].

    Correct.

    So can you please explain how how clock synchronisation is maintained during bandwidth resizing in the middle OTN nodes.

    Intermediate nodes are not aware of the ODUflex, they do not know
    wich ODU0 belongs to an ODUflex, or which ODUflex.
    The resizing of the ODUflex is using a protocol that is using the
    overhead of the ODUflex. Only the end points are aware of the change.
    The timing information is part of the client signal, so it will
    not be aware of any bandwidth resizing.

    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...

    Hi Huub ,
    is there any case that SDH clocking Can't be transparent over OTN?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Huub van Helvoort@21:1/5 to All on Fri Feb 2 16:02:43 2018
    Hello again Krishna,

    You ask:

    is there any case that SDH clocking Can't be transparent over OTN?

    I am not aware of such a case.
    SDH STM-N is asynchronous mapped AMP, or bit-synchronous mapped
    BMP. Both are transparent for timing.

    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)