Re: Question on HDLC and raw access to T1/E1 serial streams.

[Krzysztof Halasa <khc@pm.waw.pl>]

Ben Greear <greearb@candelatech.com> writes:

> I think if I could support these scenarios below, I would have
> everything I need:
>
> *  Configure T1 as unchannelized bitstream, bridge entire thing to
> second T1.

I think it should be easy with such card, though I think the drivers
can't currently do that.

> *  Configure channels 1-5 as a bitstream and bridge that to channels
> 1-5
> of a second T1.  (random proprietary bit-streaming protocol,

I think the hardware would permit that. Probably needs additional
driver support and I'm not sure about timeslot synchronization (for
HDLC, sync doesn't matter).

>                     would probably bridge HDLC just fine, but handling
> HDLC as frames would be more efficient I think.)

Not sure, maybe yes (less data to bridge due to bit stuffing, flags etc.),
maybe not (variable length of HDLC frame).

>    channels 6-10 configured as an HDLC interface, bridged as HDLC
> frames to channels 6-10 of a second T1. (PPP & other protocols over
> HDLC)
>    channels 10-24 each configured as a separate bit-stream, bridged to
> channels 10-24 on the second T1. (Voice)

I think the above could be a problem - I think common T1/E1 cards
can do only one stream at once.

I wonder if it can be done in software - the hardware framer would
have to pass all data transparently, and it would be demultiplexed,
processed and then multiplexed by the driver. Quite complicated,
but I think at 2 Mbps it wouldn't be a CPU performance problem.

> *  Configure entire T1 as HDLC transport, bridge HDLC frames from one
> T1 to the other.

Easy even with existing drivers I think (no bridge support but it's
trivial).
-- 
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/