Multilink PPP & RFC 1717
Dale E. Reed Jr.
cle...@marshallnet.com wrote:
>
> Apparently even they are confused. With the b20 version I do have
> users connecting to it at 33.6 and that's with line side channelized
> T-1's. I always get 31200 myself.
We have several "Connect-Info = 33600" in our logs for our PM3
as well. This is on a PRI.
--
Dale E. Reed Jr. (da...@iea.com)
_________________________________________________________________
IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs
Internet Solutions for Today | http://www.emerald.iea.com
David Matthews
Megazone wrote:
>I've read 1717 and 1990, and I just skimmed them again - maybe I missed
it.
>Can you post the fragment to which you are referring?
>
>The closest thing I found is this in RFC 1717:
> The goal of multilink operation is to coordinate multiple independent
> links between a fixed pair of systems, providing a virtual link with
> greater bandwidth than any of the constituent members. The aggregate
> link, or bundle, is named by the pair of identifiers for two systems
> connected by the multiple links. A system identifier may include
> information provided by PPP Authentication [3] and information
> provided by LCP negotiation. The bundled links can be different
> physical links, as in multiple async lines, but may also be instances
> of multiplexed links, such as ISDN, X.25 or Frame Relay. The links
> may also be of different kinds, such as pairing dialup async links
> with leased synchronous links.
>
>And I don't see how you can get what you are claiming from this paragraph.
>It does not indicate any requirements to support the different port types,
>merely that it is possible.
>
>But, as I said, I just skimmed it now to see if I could find what you were
>referring to - please let me know.
>
>>misrepresention we encountered (with Livingston sales people and techs
and
>>the online PM3 faq) is the claim that the PM3 supports 33.6's. To date,
it
>
>The datasheet online says 28.8 - I'll look for any other 33.6 references.
>Officially, at the moment, we support 28.8K.
I don't want to start a flame over semantics of RFC's, only to further
explain what I meant. What you quote above doesn't quite tell the whole
story nor does it convey the context of the General Overview section of any
RFC for those who are not familiar with reading them.
Section 1.2 Functional Description (this section describes the requirements
for compliance) states:
. . . .
1. The system offering the option is capable of combining multiple physical
links into one logical link;
. . . .
A physical link is defined implicitly later in the paragraph you quoted
above (which was part of the General Overview section of the RFC), which
effectively says that the physical link itself need not be limited to any
specific type or speed provided it can support PPP. Without getting into
the guts of the MPPP definition, suffice it to say that it goes on to
describe exactly how to implement the protocol in both synchronous and
asynchronous situations (more specifically, how to implement things without
regard to whether the bonded physical links are synchronous or
asynchronous). In other words, "The system offering the option . . ."
should offer it without regard to the supported physical links. More
clearly, if you sell a box (system) that supports multiple types of
physical links, then you say that it's RFC 1717 compliant (I've counted 4
occurances of this statement in the manuals without any reference to the
fact that it's only for ISDN), then the implementation of the protocol
should be according to the RFC. It's like saying that the box supports PPP
negotiation over a TCP/IP connection but only if the packets come in order
and none of them are missing.
About the 33.6 support issue, I concede that the newer revs of the ComOS
may allow for a partially 33.6 connection (although we rarely see even as a
good as a 28.8 over our US West provided Channelized T1 and we've never
seen a 33.6, but I digress). My point was, that we were told that it
supported 33.6 before we bought it (which was way back at the beginning of
this year). Anyway, here's the reference to the PM3 FAQ that states that
the PM3 supports 33.6's. Megazone, if you have any influence over the
changing of this misleading online information, can you see what you can
do?
http://www.livingston.com/Marketing/Products/pm3qa.shtml#13
. . . .
Q. Does the PM3 support 33.6Kbps modem?
A. Yes.
. . . .
David Matthews
Webmaster--Internet Technology Systems
webm...@itsnet.com
John Storms
At 05:52 PM 7/24/97 -0600, you wrote:
>I'm beginning to wonder if anyone at Livingston (especially those
>involved in putting together the manuals) has ever actually read the RFC.
Not only do we read them, we write them. In fact half of the listed
authors for RFC 1717 work for Livingston. Livingston has always been
active in developing new technology.
>---- To say that the PM3 complies to RFC 1717, but only for ISDN is to say
>that it's NOT RFC 1717 compliant at all!!! It is more correct to say that
>it complies with the portion of RFC 1717 dealing with synchronous ports.
Actually, we are complient. The idea behind RFC 1717 is to provide a
standard for the operation of splitting packets, sending them down multiple
data links, and putting them together. To say we are complient means that
we implement all the "must"'s, "shall"'s and "Mandatory"'s in the document.
All RFC's (at least the well written ones) will provide options and good
ideas to improve the implementation and so does RFC 1717.
>---- To say that the PM3 complies to RFC 1717, but only for ISDN is to say
>that it's NOT RFC 1717 compliant at all!!! It is more correct to say that
>it complies with the portion of RFC 1717 dealing with synchronous ports.
>From reading the RFC I have not identified a sync portion or an async portion.
To be complient we don't 'have' to apply multilink on various types of data
links, though we plan to. One step at a time.
>(by the way,
>at least two techs at Livingston, upon direct inquiry on the subject, still
>maintain that it is RFC 1717 compliant).
Three.
>So, Livingston, please stop saying that the PM3 and PM2E are compliant with
>RFC 1717 until they are. Luckily, some day, the PM3 will actually live up
>to RFC 1717. On the other hand, the PM2E won't ever be compliant due to
>overwhelming hardware issues involved with its buffers.
?hardware issues involved with its buffers?
Huh?
---
jst...@livingston.com
Diplomacy: The art of saying good doggie
while seaching for a big rock.
David Matthews
John Storms wrote:
>>I'm beginning to wonder if anyone at Livingston (especially those
>>involved in putting together the manuals) has ever actually read the RFC.
>
>Not only do we read them, we write them. In fact half of the listed
>authors for RFC 1717 work for Livingston. Livingston has always been
>active in developing new technology
OK, OK last post from me on this issue (by the way, nice to hear from you
John -- Kent & Parker say hi :) )
I'm not ignorant of the fact that you guys write some of the RFC's (I've
been grappling with the RADIUS RFC's in an effort to do our own integrated
NT/web based signup/accounting/logging/RADIUS implementation). I apologize
for the low blow -- I didn't mean to insult the developers (a group to
which I belong). It's just that I've worked on implementations of other
protocol-based RFC's and have run into similar language which is
interpreted as a must even when it doesn't explicitly state it as such
within the RFC. Regardless of the interpretation of the language of the
RFC (I certainly admit fault on my part if my interpretation of RFC 1717 is
not what the actual writers intended), I guess I still have a real problem
with calling a box RFC compliant and not including the fact that the RFC's
implementation is conditional. The only place I've been able to find the
conditional to the RFC 1717 implementation (that it only works for ISDN) is
here in this users group -- not from the sales guy, not from the release
notes for any of the ComOS's (I admit that I haven't thoroughly read every
release note in search of this information), nor from any of the techs I
talked to (until I cornered one of them after I had already spent the
better part of a weekend trying to make it work). I'm just frustrated by
the lack of continuity in the various information channels provided us as
customers, not just about this issue, but others as well. I shouldn't have
to find out gotcha's like this after convincing my boss that we should make
$17,000/unit upgrades and having them installed only to find out that the
info we got originally doesn't quite live up to what we get in the product
(I already deal with enough of that from USWorst). It makes you guys look
bad to us, it makes me look bad to my boss, and it makes us look bad to our
customers. I suppose I'm just too used to getting more than what I expect
from Livingston products instead of the other way around. My intention is
not to offend, just to relay my experience thus far regarding the PM3.
>>On the other hand, the PM2E won't ever be compliant due to
>>overwhelming hardware issues involved with its buffers.
>
>?hardware issues involved with its buffers?
>
>Huh?
I was referring to two earlier posts by Megazone (this one's from Thu, 27
Feb 1997 to be exact) regarding the fact that there were no plans to
implement MPPP on the serial ports of PM2E's due to it's buffering
capability not being up to snuff. (I suppose I should have said
"buffering" instead of "buffers" -- semantics again :) )
Megazone wrote:
>Once upon a time Timothy Deem shaped the electrons to say...
>>What would it take (technologically and politically) to get this
offerring
>>in a PM?
>
>Technologically it may take replacing the PM.
>
>As I've said, MP is heavy on buffering. The 5BRI cards were designed for
>this, the rest of the PM-2 hardware is not.
>
>It may be possible, but it isn't likely.
>
>As has been said, the PM-2 came out in 1993. MP didn't exist then, it
>wasn't a consideration. As new standards come out it isn't always
possible
>to do them in existing HW.
>
>-MZ
Don't get me wrong, the PM3 IS the coolest thing around right now (for the
price) -- just a few comparitively little things remain to be fixed which
will hopefully be cleaned up by the new Lucent DSP's.