Subject: Re: draft-ietf-pppext-aodi-01.txt

From: James Carlson <[email-masked]>
Date: 06 Nov 1999 00:34:28 -0500

I just recently noticed that this document purports to be headed for
standards track.  With that in mind, here are a few of my own
comments.

>    AO/DI is based on using existing infrastructure of modern central
>    office switches and using The Bandwidth Allocation Control Protocol
>    (RFC 2025).

It's not at all clear in the draft why BACP is needed at all.  If you
are recommending static configuration of the X.121 and/or E.164
addresses, then what role does BACP take?

It appears to me that the two are logically independent.  One could
choose to implement AO/DI.  Or BACP.  Or both.  The fact that you need
to bring up B channels during high demand does not compel the use of
BACP.

>    The basic idea of AO/DI is that an ISDN D-Channel X.25 connection is
>    made from the subscriber to the Internet service provider.  The
>    multilink PPP protocol and TCP/IP protocols are encapsulated within

If you don't actually plan to do MP between B and D channels -- later
in the draft you correctly note that the link is slower when doing MP
with member links of widely disparate bandwidths -- then why even
negotiate it?

It seems that this is not necessary.  A simpler implementation would
signal up a B channel when needed, and begin sending data over it
using ordinary load balancing techniques instead of MP.  Since you're
assuming TCP/IP operation (which also seems unnecessary), a temporary,
non-persistent reordering is harmless.

A side benefit of doing this is that RFC 1990 need not be modified to
allow idle member links.

>    * A European service provider will be delivering an ETSI packet
>    handler protocol link to the ISP (or value add service supplier).
>    This will allow the ISP to terminate any protocol within the LAPD.

What exactly does that mean?  Is PRI over E1 different in some
significant way from PRI over T1?  If so, then what does AO/DI
contribute here?

>    * When additional bandwidth is needed, the appropriate phone numbers
>    are exchanged between the subscriber's equipment and the Internet
>    service provider's equipment to allow additional Bearer channels to
>    be dialed.  The Bearer Channels are routed through the switched
>    fabric directly to the Internet service provider without the use of
>    the packet handlers in the central office.  Subsequent to successful
>    connection, the multilink protocols are resolved to aggregate the
>    additional bandwidth into a single transport connection.

This doesn't appear to be true unless multiple B channels are in use.
Since multiple calls are always a possibility, it doesn't seem
necessary for an AO/DI document to describe the operation of the
already well-established RFC 1990 MP.

>    The IETF provides some guidelines for the use of PPP over X.25 in
>    RFC 1598.  Strictly speaking, RFC 1598 does not apply to AO/DI, but
>    it has been used as a source of many useful concepts.
>
>    The essential difference between AO/DI and RFC 1598 is that AO/DI
>    treats X.25 as another dial-up resource, over which PPP is used to
>    frame the data transmission, whereas RFC 1598 recommends a method to
>    substitute the X.25 header for the PPP header.

Why is this difference introduced?  There's certainly nothing
essential about modifying the Proposed Standard RFC 1598 header format
that enhances AO/DI in any way.  At best, it's an unnecessary
incompatibility.

>    It has been requested ISO/IEC TR 9577 [5] provide a reserved NLPID
>    value of the CUD so that incoming calls X.25 calls can be
>    unambiguously indicated; they have agreed to do this, and the value
>    is expected to be assigned in the near future.

Why?  What significant difference will be signaled here?  If the peers
plan to do something different based on this signaling, then it would
seem important to state what exactly that difference might be.

>    In the interim, AO/DI recommends that until ISO the call originator
>    set the NLPID of the CUD to 0xCF.

I can't parse that.

>    The PPP Protocol field and the following Information and Padding
>    fields are described in RFC 1990.

RFC 1661, perhaps?

>    AO/DI recommends against header substitution by the transmitter.

Why modify an existing Proposed Standard?  It may well be cleaner in
some regard, but so what?

Note that if you change this, then the X.25 document will be out of
step with Frame Relay.  And you can't change the Frame Relay document
without breaking existing ATM interworking functions (FRF.{5,8}).

>Underlying Multilink Protocol Behaviors
>
>    AO/DI uses BACP multilink protocol to negotiate for bandwidth,
>    manage phone number exchange, and to aggregate the bandwidth of
>    subsequent connections.

BACP isn't a multilink protocol, and it's not necessary for multilink
operation.  There doesn't appear to be a need for it here, either.

>    In today's multilink protocols (RFC's 1990 & 1934), the session

RFC 1934 (Ascend's proprietary MP+) isn't a multilink protocol,
either.  Nor, again, is it needed for this draft.

>    In any case, it may be desirable to have a user interface that
>    confirms with the user the request for additional bandwidth, should
>    the users be sensitive to these charges.

This may well be true in some cases.  If it is true, and if BACP
actually solves the problem, then a PPP implementation might include
BACP.  That's no argument, though, that this draft should contain BACP
as a requirement.  It might be useful to some people and not to
others.

>    To increase the overall bandwidth beyond low-bandwidth of  the D-
>    Channel X.25 circuit, BACP messages are used to signal when Bearer
>    Channels should be added to the link bundle.  The B-Channels are

Why not just send *only* Q.931 Connect messages to signal the use of
new B channels?

>    BACP was designed for use over a network with only a single
>    numbering plan; i.e. multiple analog modem lines or multiple B-
>    Channels.  However, X.25 addresses are only E.164 or X.121.

Agreed; the BACP telephone number deltas are a mess.  It's not clear,
though, that this is a problem that needs to be solved here.

>    The following text proposes a method for idling a link of a
>    Multilink PPP (MP-RFC 1990) bundle.

Why run MP between the D channel X.25 connection and anything else?
It seems like it's more trouble than it's worth.  Plus, this false
requirement appears to be leading to an unwarranted modification of a
Draft Standard protocol.

If you're doing this in order to use the MRRU to get around X.25 MRU
limitations (the well-known MP-on-one-link hack), then say so.

>    An explicit "Idle Link" command and response handshake would be the
>    most robust method of performing this idling.  However, this
>    explicit method would also be more complex to implement and would
>    require approval from at least one standards committee. It was
>    agreed that for these reasons, an implicit idling method is
>    preferred at this time.

This document itself, if it really is headed for standards track,
requires approval from at least one standards committee.  It's not at
all clear that this "idle link" mechanism is needed at all, but it's
certainly clear that this reasoning is insufficient.

>    For a longer term solution, we may want to consider an extension to
>    MP or BAP that would include "Idle-Link" and "Idle-Link-Ack"
>    primitives.

Such a mechanism exists.  You can use LCP Echo-Request to determine
when the X.25 connection has drained, if this is important.

>    After completing the data transfer that required invocation of the
>    additional B-Channel(s), the B-Channels need to be disconnected so
>    the circuit-switched resources can be returned to the trunk pool.
>    BACP supports such requests.

As does Q.931 -- clearing the call should have this effect.

>    A more sophisticated method would look at the application that
>    generated the request to guide the use of BACP.  For example:

This seems to assume that a single human user sits behind the
connection.  This may be true with some PCs, but is generally false
elsewhere.

>    First, the concern implies that these users are willing to forebear
>    low throughput.  Were they really willing to do so, they would have

I think you mean 'forbear' not 'forebear,' unless you're saying
something about the users' ancestors.  ;-}

>    * reverse charging accepted @ router

Does 'router' here mean 'peer?'  It's a bit surprising to see that the
nominal ISP should be accepting charges from users.

>    Informational Note: IP frame size default is 1024 octets. By
>    default, the X.25 window size is limited to 2, with a frame size of
>    128 octets.  (BACP allows for different fragmentation of the MRRU on
>    the links comprising the bundle, so this should not be a major
>    concern for multilink operation.  However, it should be studied
>    further whether negotiating a larger X.25 window size and frame size
>    will be useful.)

BACP has nothing to do with this.  MP itself does *not* allow the MRRU
to be different on member links.  The MRU, however, certainly may be
different.

>    through put becomes unacceptable, an attempt to add a B-Channel will
>    be made; this could be the result of delays in packet acknowledgment
>    or even packet rejection at the packet handler.

Does this mean that sequenced, flow-controlled X.25 traffic can be
discarded by X.25 for anything other than catastrophic failures?  I
suspect that what was meant here was that forcing too much data
through this X.25 connection will cause X.25 itself to suffer
congestion and delays due to internal retransmissions.  The PPP
packets aren't lost or rejected.

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp