> Len Conrad wrote:
> >
> > [EMAIL PROTECTED] tells me their P1200 E1 card, with FreeBSD drive, can't
> > work in channelized mode (like the etinc cards can't). Their LMC150xM
> > cards can do channelized, but don't have a FreeBSD driver, but their
> > FreeBSD guy is looking at it.
> >
> > Any hacker care to explain how a channelized T1/E1 (24 or 30 separate ip
> > streams) would be seen within FreeBSD? ifconfig setup? Would we have to
> > assign 30 fixed ip addresses to these "virtual/channel" ip interfaces?
>
> Fixed, DHCP, PPP-assigned, whatever. Individual addresses would certainly
> be the easiest way to use them, unless you're going to do aggregation at the
> link layer. Sorry, my knowlege of channelized T1 doesn't extend quite that
> far down.
You've got to look at what you're actually getting as a delivered capability.
What you actually have is 24 (or 32 in the case of an E1) 64kb/s bearer
channels. Some of them might be combined with others to provide Nx64kb/s
coherent bearers. Some of them may be dedicated to framing, transport
and signalling (e.g., the "D" channel of a 23B+D ISDN PRI T1).
That these bearer channels happen to be delivered on a T1 (or E1) entrance
facility as the handy carrying case is mostly orthoganal to how you'd treat
each individual bearer channel. There might be configuration associated
with the T1 (e.g., AMI or B8ZS line encoding), but it's mostly invisible
to the bearer channels, other than enclosing them.
So you'd probably end up with 24 network interfaces or devices
(in the case of a T1), one for each 64kb/s channel, unless you combine
them together somehow as Nx64K aggregate.
On the other hand, how the hardware abstraction is presented or exposed
by the OS might mask this. Consider an ISDN BRI; this is a 2B+D channelized
facility, but due to the typical application it's used for, the completely
general abstration may not be necessary.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
