PPP over WDM - PPP

This is a discussion on PPP over WDM - PPP ; Bonjour, A colleague told me yesterday we can transport PPP over WDM without SDH / PDH / OTN, and for me it's very curious. I know PPP over Modem protocols, PPP over Ethernet, but not PPP directly over WDM! Perhaps, ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: PPP over WDM

  1. PPP over WDM

    Bonjour,

    A colleague told me yesterday we can transport PPP over WDM without SDH
    / PDH / OTN, and for me it's very curious.

    I know PPP over Modem protocols, PPP over Ethernet, but not PPP
    directly over WDM!

    Perhaps, it is PPP over 10G over WDM, in the metro Ethernet style.

    Someone has an opinion about that?
    I'm afraid that my colleague, as much people, consider WDM as a
    protocol and not as an optical modulation.

    Regards,
    Michelot


  2. Re: PPP over WDM

    "Michelot" writes:
    > A colleague told me yesterday we can transport PPP over WDM without SDH
    > / PDH / OTN, and for me it's very curious.
    >
    > I know PPP over Modem protocols, PPP over Ethernet, but not PPP
    > directly over WDM!
    >
    > Perhaps, it is PPP over 10G over WDM, in the metro Ethernet style.
    >
    > Someone has an opinion about that?
    > I'm afraid that my colleague, as much people, consider WDM as a
    > protocol and not as an optical modulation.


    Most likely, he means PPP in RFC 1662 HDLC-like encoding directly on
    an optical channel within WDM. For a point-to-point connection,
    there's no particular reason to use any channelization scheme (such as
    SONET/SDH or any of the PDH mechanisms) unless you really need it.

    But instead of asking us, why not ask him what he meant ... ?

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  3. Re: PPP over WDM

    Bonjour James,

    Thanks for your interesting reply

    > But instead of asking us, why not ask him what he meant ... ?


    You're right, but he is not a low layer expert. So, I would be very
    happy to discuss this with you if you were to agree.

    > Most likely, he means PPP in RFC 1662 HDLC-like encoding directly on
    > an optical channel within WDM.


    The question is that RFC 1662 specify the layer 2 and not the physical
    layer. And to convey HDLC frames on an optical channel, I imagine you
    have at least to be sure that the transition density of 1->0 or 0->1 is
    sufficient to recover the clock at the receive side.

    For that, we can for example use a special line coding (as 8B/10B) or
    scramble the bits (as it is done in SDH). So, it seems we have to
    define in fact an intermediate transport procedure between HDLC and
    WDM.

    Have you heard something like that (for PPP/HDLC)?

    Regards,
    Michelot


  4. Re: PPP over WDM

    "Michelot" writes:
    > > Most likely, he means PPP in RFC 1662 HDLC-like encoding directly on
    > > an optical channel within WDM.

    >
    > The question is that RFC 1662 specify the layer 2 and not the physical
    > layer.


    Right.

    > And to convey HDLC frames on an optical channel, I imagine you
    > have at least to be sure that the transition density of 1->0 or 0->1 is
    > sufficient to recover the clock at the receive side.


    True. But it's certainly not impossible to use the SONET line (SDH
    RS) layer scrambler with a raw HDLC bit stream.

    There are other plausible options as well. SDL (RFC 2823) can be used
    on raw fiber, includes its own scrambler, and doesn't need SONET/SDH.

    There's also the ITU-T's "Generic Framing Procedure," which can be
    used in place of SONET/SDH.

    There are probably other options here as well. It's been quite a few
    years since I've worked in this area.

    > For that, we can for example use a special line coding (as 8B/10B) or
    > scramble the bits (as it is done in SDH). So, it seems we have to
    > define in fact an intermediate transport procedure between HDLC and
    > WDM.


    Yes. Not _much_, but I agree that it's not zero work.

    > Have you heard something like that (for PPP/HDLC)?


    I've read innumerable research papers on various schemes. You can
    turn up quite a few with google.

    I don't know of any products in the field that do this, but nothing
    like that would surprise me.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  5. Re: PPP over WDM

    Bonsoir James,

    > There's also the ITU-T's "Generic Framing Procedure," which can be
    > used in place of SONET/SDH.


    Normally, GFP is a client of octet-synchronous paths as SDH, OTH, PDH.
    There is not yet ITU-T descriptions or signs for using GFP directly on
    a raw fiber, like the pure ATM.

    > Yes. Not _much_, but I agree that it's not zero work.


    A good statement


    Thanks James for that exploration, grateful to have that discussion
    with you.
    Regards,
    Michelot


  6. Re: PPP over WDM

    "Michelot" writes:
    > > There's also the ITU-T's "Generic Framing Procedure," which can be
    > > used in place of SONET/SDH.

    >
    > Normally, GFP is a client of octet-synchronous paths as SDH, OTH, PDH.
    > There is not yet ITU-T descriptions or signs for using GFP directly on
    > a raw fiber, like the pure ATM.


    "Can be" -- at least in some of the research reports I've read.

    Also, RPR/SRP can work on raw fiber (as well as within a SONET/SDH
    mapping).

    The underlying point is that if, for a particular application, you
    don't care about the features that come from SONET/SDH cross-connects,
    it's possible to discard some of those middle layers. Given the great
    expense that high speed links tend to represent, I can see why some
    people will go to just about any length to squeeze out a little more
    performance.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  7. Re: PPP over WDM

    Bonjour James,

    > The underlying point is that if, for a particular application, you
    > don't care about the features that come from SONET/SDH cross-connects,
    > it's possible to discard some of those middle layers.


    Yes, SONET/SDH make easier client payload cross-connections. But, we
    have also SONET/SDH features such as automatic protection less than 50
    ms, alarm control, trail performance monitoring, low latency, automatic
    bandwidth adaptation, transport of all client types (PDU or stream of
    characters).

    > Given the great expense that high speed links tend to represent, I can see why some
    > people will go to just about any length to squeeze out a little more
    > performance.


    Yes, it's very new in the technology countries. Customers are ready to
    loose a little bit of quality in the condition they have a useful
    service, practical and low cost. We have now phones that sizzle when we
    are under tunnels, bridges, away from the antenna sight, and very glad
    to use that mobile service. The perfect POTS in the past is vanished.

    Regards,
    Michelot


  8. Re: PPP over WDM

    "Michelot" writes:
    > Bonjour James,
    >
    > > The underlying point is that if, for a particular application, you
    > > don't care about the features that come from SONET/SDH cross-connects,
    > > it's possible to discard some of those middle layers.

    >
    > Yes, SONET/SDH make easier client payload cross-connections. But, we
    > have also SONET/SDH features such as automatic protection less than 50
    > ms, alarm control, trail performance monitoring, low latency, automatic
    > bandwidth adaptation, transport of all client types (PDU or stream of
    > characters).


    Many of those things have parallels in other technologies. They're
    certainly not exclusive to SONET/SDH.

    > > Given the great expense that high speed links tend to represent, I can see why some
    > > people will go to just about any length to squeeze out a little more
    > > performance.

    >
    > Yes, it's very new in the technology countries. Customers are ready to
    > loose a little bit of quality in the condition they have a useful
    > service, practical and low cost. We have now phones that sizzle when we
    > are under tunnels, bridges, away from the antenna sight, and very glad
    > to use that mobile service. The perfect POTS in the past is vanished.


    I don't really think it's a matter of quality at all. That, I think,
    is a rather bald assertion, and the analogy to mobile service is quite
    inapt.

    Instead, it's a matter of fitting solutions to the problem domains at
    hand, and discarding or avoiding things that aren't needed or wanted.

    The distinction between these is why (in my opinion at least) ATM to
    the desktop was essentially a fantasy. It's not just that it was too
    expensive or not good enough or lacked applications or that those evil
    Internet people killed it, it was that it didn't really fit the
    demands of the task at hand, while the comparatively feature-poor and
    "simple" Ethernet technology did fit.

    Anyway, I think you're now approaching the realm of politics rather
    than technical matters, so it's probably best to leave
    comp.protocols.ppp out of it, as this newsgroup has nothing much to do
    with any of those issues.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

+ Reply to Thread