Re: IP over SONET considered harmful?

[Vadim Antonov <avg () pluris com>]

Sean M. Doran wrote:

> | There's LQM in PPP.
>
> I would prefer to eliminate PPP.

 Why?  PPP is a fairly generic option negotiation mechanism.
 The  HDLC framing can be omitted, though.  In any case, nothing
 prevents using of some simple LQM/keepalive protocol.

> | Better yet,
> | what i do with splicing traffic into many channels effectively
> | provides IP-invisible restoration w/o loss of useful capacity.
> | Just route those channels into diverse physical paths :)
>
> Um, unfortunately I missed your presentation at NANOG and
> there is as yet no sign of the real video archives that
> I can find, so going by memory and your web pages,
> what I remember is that you are planning on using interfaces
> roughly comparable to STS-1 and STS-3c, and using
> telco WAN gear to do the work of add/drop multiplexing.
>
> I thought this was rather clever, actually, particularly
> given the accuracy of the prediction that non-facilities-owners
> would have trouble getting access to anything faster than DS3s
> in the near run.

 We're moving beyond that, though DS-3 and OC-3c interfaces
 will be available.   We're quite keen on getting into space where
 J*r and C*o are no longer competitors; and that means going way
 beyond OC-48.

> If you have changed your mind and are building your own
> fibre muxes, that would be neat to know. :)

 There's no need; we have good relationships with WDM vendors. They realize perfectly well that ours is the only 
approach which
 can actually make larger configurations of their gear useful.
 Huge capacity is useless unless there's a way to switch it.

> | ? SDH/SONET is also a really keen way of sharing a network
> | ? among IP and other things on the wide-area side, and
> | ? an even keener way of having access to relatively low-speed
> | ? customer data on the more local side.
> |
> | On customer-access side even ATM seems to be fine :)   It
> | definitely is a huge lot cheaper than SONET gear.
>
> It is pretty easy to pluck out VCs/SPEs from SDH/SONET.
> The general thought was to have the equivalent of a CT3
> (cisco device, takes T3 in on BNC pair, pulls out DS1s)
> that can extract from, say, an OC3 or OC12, DS3s, SPEs
> containing T1s and E1s, and perhaps even individual DS0s.
> (DS0s would be neat as with clever load-balancing
> that gives you a granularity that is competitive with the
> use of ATM as a fine-grained TDM system).
>
> Essentially, an ADM on a card.   I don't see that as
> being prohibitively expensive to engineer, and ironically
> I think it would be easier for you than for some of
> your competitors to make switching work, since they
> may be forced to simulate a hierarchy of routers on the card.

 The reason for doing ATM on customer-access side is simple: it's
 dirt cheap.  There's a bunch of vendors selling OC-3 SARs.  Of course,
 Fast Ethernet is cheaper yet, but it doesn't mix well with telco
 transmission facilities.

> | I also expect it :)  My current favourite for framing is
> | 32-to-33 bit encoding, with flag being one of "malformed words",
> | one word header (2 bytes for payload length, 2 bytes for tag), and
> | 32-bit CRC at the end.  I.e. the per-packet overhead is 12 bytes + 3.1% +
> | rounding to 4 bytes for odd-sized packets. Make all 1s and all 0s
> | and chess patterns to be invalid words, and loss-of-carrier becomes
> | easy to detect.
>
> Well, I still prefer the idea of a synchronous byte stream
> to a clever HDLC on steroids... :)


Well, it is _not_ HDLC since it doesn't do any bit or byte stuffing.  You
 have to have some "flags" to locate beginning of a frame; but at high speed
 you also want to have longer "bytes", and have those "bytes" arrive at a
 steady rate (w/o skips), so you can easily lump them into bursts.  Having an
 explicit length at the beginning also makes h/w implementation easier.

--vadim