The requirement is more judicial than technical, so lawyers require compliance.
An interleaving mechanism that limits jitter has to be in place.
My idea was to divide PPP frames into cells, prioritize them at the ATM level, let DSLAM's SAR to reassemble them and send them to the WAN. that way there would be no PPP fragmentation (and therefore defrag at BRAS is not required) and very much controlled jitter.
How about one multipoint ATM subinterface with two PVC's for one dialer? Any ideas/suggestions?
If you need to separate traffic under a legal point of view, why don't you consider two encrypted tunnels, these would be separated and I don't that in any law book you will find that an ATM VC separation is accpetable and a VPN one is not.
I know of designs on ADSL with separate PVCs for data and voice, but the latter was usually AAL2 for the few telcos that still do that.
PPPoE on the other hand I'm almost sure it can work on a single PVC only.
The legal point of view are bunch of documents that govern the service, that is the jitter must be maintained below recommended ITU value. It is critical to fragment and interleave between modem and DSLAM because of slow uplink.
The problem is with isp "cooperation" in this particular case - BRAS is not ours and PPPoE profile is predefined, without a chance to change it due to competition.
That is why it is a problem. I need to solve it without modifying PPPoE behaviour, and I don't want to resort to IP fragmentation, which of course works.
Because of the complications I do not see other possibilities than solving the problem with PVCs and DSLAM or IPfragmentation.
If BRAS would be in our control, all I had to do then is type in "ppp multilink" command so MRRU can be negotiated. Then I would fragment and interleave at MPPP level.
Thanks for explaining, but what is the upstream speed? Eg 256K introduces a maximum of 50 ms latency when a voice packet is queued after a max mtu one. That is easily in the domain of jitter buffer and because of that I said voice works on adsl without need for fragmentation.
And believe me, if it was for the ITU, we would be still doing X.25 now.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...