Subject: AODI to Informational Standard

From: Karl Fox <[email-masked]>
Date: Tue, 27 Mar 2001 08:44:08 -0500

Thomas and Erik,

The PPPEXT Working Group recommends that Always On Dynamic ISDN (AODI), 
draft-ietf-pppext-aodi-02.txt (attached, as it has expired) be advanced to 
Informational Standard.

PPPEXT Working Group                                       Matt Holdrege
Internet Draft                                      Lucent Technologies
Category: Standard March 2000

                     Always On Dynamic ISDN (AODI).
                    <draft-ietf-pppext-aodi-02.txt>

Status of this Memo

     This document is an Internet-Draft and is in full conformance
     with all provisions of Section 10 of RFC2026.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its
   areas, and its working groups. Note that other groups may also
   distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other
   documents at any time.  It is inappropriate to use Internet-
   Drafts as reference material or to cite them other than as
   "work in progress."

   To view the entire list of current Internet-Drafts, please check
   the "1id-abstracts.txt" listing contained in the Internet-Drafts
   Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Copyright Notice

Copyright  (C) The Internet Society (2000).  All Rights Reserved.

Introduction:
    Always On/Dynamic ISDN (AO/DI) is a networking service that provides
    an always-available connection to TCP/IP-based services through a
    specific wide area connection. This service provides several
    advantages over current practices for dial-up access to Internet
    services.

    * For the end-user, there is no need to dial-up the service each
    time access is desired.

    * For the Internet service provider, it is possible to give the end-
    user a notification, such as the arrival of new mail.

    * For the Local Exchange Carrier, the switched circuit trunk
    utilization is more efficient.

    It should be understood that TCP/IP is the network protocol of
    choice for public data networks (Internet), and private data
    networks (Intranet) typically used for businesses. AO/DI does not

Holdrege                                                        [Page 1]

I-D                      Always On Dynamic ISDN               March 2000

    differentiate whether the user is connected to either the Internet
    or an Intranet, or both simultaneously.  Further, the issues
    involved in either case are very similar as far as client behaviors
    and impact on the public telephony networks.

    The potential impact of Internet access is quite large.  According
    to a recent survey, only 24% of US households have a computer with a
    modem.  It's likely that most of these systems are not used on a
    regular basis for anything, much less Internet access.  But this is
    changing quickly and already the relatively small number of users
    are having an impact on the network. There are similar predictions
    for other countries.

Description of AO/DI Operation

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

    * Modern central offices are capable of supplying ISDN, and many of
    these central office switches are configured with X.25 packet
    handlers.

    * BACP is available in many remote access products.

    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
    the X.25 logical circuit carried by the D-Channel.  The Bearer
    Channels are invoked as additional bandwidth is needed.  The Bearer
    Channels use the multilink protocol without the Q.922 and X.25
    encapsulation used on the D-Channel.  I.e., a circuit-switched
    connection between the ISP and the client is established over the B-
    Channels over which IP packets are sent through PPP encapsulation.

    It is possible to offer a full-duplex, always-available services
    based on the fact that Because the ISDN physical-layer signalling
    (2B1Q synchronous modulation) and the  Q.922 link layer are kept
    running at all times, even when there are no Q.931 messages being
    transceived.  The physical and link layers allow for packets to be
    sent across a connection-oriented X.25 virtual circuit to be
    established between the Internet Service Provider and the
    subscriber.

    Further, because the D-Channel X.25 packets are handled at the
    central office by the X.25 packet handler, it is possible to route
    these packets without first crossing the time-division circuit-
    switched fabric of the switch, which reduces the impact to the
    telephony network.

    X.25 provides for two call types: a switched virtual circuit (SVC)
    and a permanent virtual circuit (PVC).   Considerations are:

    * Not all the worlds Packet Handler implementations can be

Holdrege                                                        [Page 2]

I-D                      Always On Dynamic ISDN               March 2000

    guaranteed to support PVCs.

    * Some service providers that own the ISDN infrastructure may not be
    an ISP in their own right and may be providing ISPs with a standard
    X.31/X.75 delivery of D-Channel traffic.  If this is the case, there
    is a need to use (and change) X.121 addresses in order for a user
    (of the CPE) to be able to change ISPs easily.  I.e., using an SVC
    makes is simpler for the users to move to other ISPs, or to
    establish a connection to a corporate Intranet, as is required for
    telecommuters.

    * An SVC can be treated as a "permanent" connection.  Once the call
    is established it does need not to be cleared and can remain in the
    data state in a similar manner to a PVC.

    * The success of X.25 networks was due in part to the use of SVCs
    and the ease of provisioning.  Frame Relay, although successful, is
    extremely complex to provision because of its PVC implementation and
    the same would apply to a managed service provider solution.

    Given these considerations, AO/DI uses SVCs.

Response to the Loss of an SVC

    Under certain conditions, the X.25 SVC may be cleared
    (disconnected).

    Conditions under the SVC could be cleared include, but are not
    limited to:

    * Inability to contact the subscriber.  This could be due to the
    user terminal being turned off, an equipment problem due to hardware
    or software in the network or the user terminal, etc.

    * The result of the ISP clearing the call to redistribute the X.25
    SVC across other LEC facilities due to traffic congestion.  This
    action might be undertaken by an ISP to help distribute network
    loads across facilities.

    * An equipment problem in the network.

    While X.25 disconnects are considered highly unlikely, it is a
    matter of further study to control the frequency at which the user
    terminal attempts to re-establish the SVC. As certain failures (e.g.
    other than a user terminal problem) have a remote possibility to
    result in hundreds of endpoints simultaneously attempting to re-
    establish their connections which could be a substantial burden on
    the switch.

    When the X.25 SVC is disconnected, the terminal should attempt to
    re-establish the SVC at the earliest convenient time.  It is
    suggested that the rate of re-establishments attempts within be
    limited to avoid excessive setup requests sent to the network.

Holdrege                                                        [Page 3]

I-D                      Always On Dynamic ISDN               March 2000

Network Connection Sequence

    An example of the calling sequence is shown below:

    * The subscriber makes an X.25 connection to the Internet Service
    Provider (or Intranet Service Provider)

    * 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.

    * The X.25 SVC will stop sending PPP payload when one or more B
    channels are in use. However, BACP messages may still be sent over
    the X.25 circuit.

The Use of IETF RFC 1598

    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 describes a way to
    replace the default HDLC header with an X.25 expanded HDLC header.

Physical Layer Requirements

    From RFC 1598: PPP treats X.25 framing as a bit synchronous link.
    The link MUST be full-duplex, but MAY be either dedicated
    (permanent) or switched.

    AO/DI uses the X.25 as a synchronous transport; i.e., there are not
    character-based escape codes.  The connection type is Switched
    Virtual Circuit, as previously discussed.

Call User Data (CUD) Field

    From RFC 1598: When the link is configured as a Switched Virtual
    Circuit (SVC), the first octet in the Call User Data (CUD) Field
    (the first data octet in the Call Request packet) is used for
    protocol de-multiplexing, in accordance with the Subsequent Protocol
    Identifier (SPI) in ISO/IEC TR 9577 [5].  This field contains a one
    octet Network Layer Protocol Identifier (NLPID), which identifies
    the encapsulation in use over the X.25 virtual circuit.  The CUD
    field MAY contain more than one octet of information.

    The PPP encapsulation MUST be indicated by the PPP NLPID value (CF

Holdrege                                                        [Page 4]

I-D                      Always On Dynamic ISDN               March 2000

    hex).  Any subsequent octet in this CUD is extraneous and MUST be
    ignored.

    The call originator MUST set the NLPID of the CUD to 0xCF.

The Data Link Layer

    From RFC 1598: Since both "PPP in HDLC Framing" [3] and X.25 use ISO
    3309 as a basis for framing, the X.25 header is easily substituted
    for the smaller HDLC header.

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

    AO/DI recommends against header substitution by the transmitter.
    AO/DI uses the X.25 as a virtual PPP dial-up connection, so we
    recommend that the PPP header be part of the X.25 payload. This
    approach better isolates the protocol layers.

    It is desirable that X.25 receivers that expect the header
    substitution, also be able to properly function when the PPP header
    is included the X.25 payload.

    The PPP FCS MUST not be used in the X.25 PPP encapsulation on the D
    channel.

Underlying Multilink Protocol Behaviors

    AO/DI MAY use the BACP multilink protocol to negotiate for
    bandwidth, manage phone number exchange, and to aggregate the
    bandwidth of subsequent connections.

    In today's multilink protocols (RFC's 1990 & 1934), the session
    originator (the end that placed the first call) is required to add
    the following call, thus incurring the additional charges, hence
    they are not symmetric in the sense that the session originator is
    obliged to add bandwidth.  This is an acceptable model to many
    people, but not universally so. BACP, being a symmetric control
    protocol, allows either end of the Internet service to place a phone
    call to the other so that additional bandwidth can be added to the
    connection. Either side may request the other to originate the call
    or may refuse the request to originate the call, and may terminate a
    link in a bundle.

    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.

    Strictly speaking, client (CPE) behavior is left to vendor-specific
    implementation.  A vendor may choose to provide differentiation in
    the features, behaviors, and look-and-feel of the dialer (the
    software that controls the addition/subtraction of B-Channels) to

Holdrege                                                        [Page 5]

I-D                      Always On Dynamic ISDN               March 2000

    meet customer requirements for a specific business environment.  For
    example:

    * for a voice call, the dialer would need to grant exclusive access
    of one of the B-Channels.

    * for requests to add B-Channels, the dialer may query the user to
    grant permission depending on the requester; a remote corporate
    access request might be granted automatically, whereas an unknown
    source would require manual intervention.

Invoking Additional Bandwidth

    Given the relatively low net bandwidth of the Internet service due
    to the low bandwidth of the D-Channel (16 kbps total with 9600 bps
    guaranteed X.25 frame throughput) and the protocol encapsulation,
    TCP/IP over the D-Channel X.25 has limited applications.  However,
    there are significant application domains where the low-bandwidth,
    always-available are useful such as

    * basic ASCII email services,

    * news feeds, and

    * automated data collection.

Using BACP to Increase Bandwidth

    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
    invoked to temporarily boost data throughput, then the B-Channels
    are disconnected.  This mode of operation statistically multiplexes
    the switch fabric and inter-office trunk lines across more users,
    thus reducing the traffic impact to the wide area network.  Using
    the B-Channels for bandwidth-on-demand is good for both the Local
    Exchange Carrier and the Internet service provider as compared to
    having users "camp on" a Bearer Channel.

    AO/DI discourages X.25 spoofing (similar to the current method for
    spoofing ISDN B-Channel and modem dial-up connections) because 1)
    this is contrary to the design goals for AO/DI to provide constant
    connectivity without further intervention of the applications or the
    operating system, 2) X.25 spoofing is likely to create excessive
    numbers of X.25 setup messages which can degrade the network and
    increase the costs to the user, and 3) as distributed applications
    become more common, spoofing will become much less useful as
    connections will tend to last longer.

    This recommendation makes it possible for users to operate AO/DI
    capable protocol stacks even when the user's ISDN network interface
    card does not support AO/DI, or if the user does not have an AO/DI
    service due either to lack of facilities at the users ISP and/or at
    the LEC.

Holdrege                                                        [Page 6]

I-D                      Always On Dynamic ISDN               March 2000

BACP Phone Deltas

    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.
    Further, special dialing sequences, such as '9' to access an outside
    line may not be applicable to X.25 calls.

    Additional numbers are exchanged in BACP using the concept of
    "deltas" whereby only the shortest string of digits needed to convey
    the change are sent.  Since this is not guaranteed to work due to
    the differing numbering plans, AO/DI has a set of recommendations:

    * Separate X.25 Dial-up setup (likely different than E.164)

    * Don't use X.25 as base for first B-Channel delta; i.e. send first
    B-Channel in its entirety

    * Second B-Channel also sent to client in its entirety

    * Phone #s are national format only (e.g. N.A. 10 digits: area
    code+prefix+# )

    * Local dialing exceptions are configured at the client (e.g.
    leading 9 to get outside line, or dialing codes for international
    access)

    * The technical subcommittee suggests the software provide an
    ability to have user-entered defaults.

D-Channel Idling

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

    Motivation

    An AO/DI ISDN MP bundle consists of one or two B-channel links, each
    running at either 56Kbps or 64Kbps, and an X.25 D-channel link
    running at 9600bps. To improve throughput and reduce connection
    costs, it is desirable to stop transferring data over the D-channel
    whenever at least one B-channel is in the bundle.

    Idling an MP link, however, causes a problem with the algorithm for
    detecting lost fragments. This algorithm depends on the value M;
    only fragments with sequence numbers less than M will be detected as
    lost. Since M is never incremented if a link is idle, the MP
    receiver could stall indefinitely (or until a timer expires) if a
    fragment is lost while one of the links is idle.

    What this all means is that if one side of an MP connection decides
    to stop transmitting data on one of the links, the receiver must be
    able to adapt its receiving algorithm accordingly. Idling a member
    link, therefore, must occur by mutual agreement between the sender

Holdrege                                                        [Page 7]

I-D                      Always On Dynamic ISDN               March 2000

    and the receiver.

Recommended Behavior

    For AO/DI-compatible systems, the implicit algorithm for idling the
    D-channel shall be as follows:

    * When a link of 56Kbps or faster is added to an MP bundle that
    contains a link of 9600bps or slower:

    1. Both transmitters should immediately cease transmitting all "re-
    directable" packets on the slow link and instead transmit all such
    packets over the faster link(s). A packet is deemed re-directable if
    it is able to be transmitted using the multilink procedure, as
    described in RFC 1990. The only packets currently NOT able to be
    redirected are LCP Configure-Request, -Reject, -Ack, -Nak,
    Terminate-Request, or -Ack packets. Also BAP packets should remain
    on the X.25 link.

    2. Both receivers should exclude the slow link from the calculation
    of M.  For simpler implementations, this exclusion could be
    immediate, but this increases the chances of losing any fragments
    currently being sent on the slow link. For more robust
    implementations, the exclusion could be started after a certain
    (short) time has elapsed. This would give any fragments currently on
    the slow link a chance to be received successfully.

    * A robust receiver should:

    * Receive and process successfully any fragments received on the
    slow link, as long as the sequence number is greater than M.

    * Discard any fragments received on the slow link that have a
    sequence number less than M.

    Note that this approach requires that both peers adhere to the rules
    described above. This should be acceptable since we may specifically
    NOT want to work with equipment that continues to load the D-
    channel.

    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.

Traffic Estimates

    Based on these estimates, the following triggers can be used as a
    stimulus for requesting additional bandwidth.

    Triggers for Requesting Additional Bandwidth

    Bearer channels are added if the traffic will take more that 5
    seconds to transmit through the D-Channel X.25, or if the pending
    data is larger than 7500 bytes.

Holdrege                                                        [Page 8]

I-D                      Always On Dynamic ISDN               March 2000

    When the amount of data is larger than 7500 bytes, we invoke a B-
    channel; further, this B-channel establishment, negotiation, and
    initialization for data takes 3 seconds, meaning the D-Channel X.25
    is active for only 3 seconds, or approximately 4500 bytes, before
    data is no longer sent across it.   Thereafter, as long as the B-
    Channel(s) is active, the X.25 is active-idle; i.e., the connection
    is maintained, but no data is transceived.

    Note: AO/DI receivers should be capable of continuing to receive
    data on the X.25 link as well as B-Channels.  This allows simplistic
    MLPPP-based systems to be used.  (Experience has shown that this
    simplistic approach is actually slower than the recommended D-
    Channel Idling, and more susceptible to error conditions.)

An Example Heuristic for Adding Bearer Channels

    One method for determining when additional bandwidth needs to be
    added is described below.

    * Is the packet service outbound queue getting full?  Where full
    means that at current throughput, will it take longer than 5 seconds
    to empty?  Will it take longer than 10 seconds?

    * If the time to empty the queue is less than 5 seconds, use D-
    Channel X.25 without invoking a B-Channel.

    * If the time to empty the queue is more than 5 second, but less
    than 10,  use the D-Channel X.25 to convey a BAP request for a B-
    Channel.

    * If a B-Channel is available, use the multilink protocol to augment
    the packet service connection.

    * If a B-Channel is not available, continue to empty the queue and
    monitor for queue fullness and B-Channel availability.

    * If the time to empty the queue is more than 10 seconds, request
    two B-Channels.

    * If two B-Channels are available, use the multilink protocol to
    augment the packet service connection.

    * If only one B-Channel is available, augment the connection with
    the single B-Channel.  Continue to empty the queue and monitor for
    queue fullness and B-Channel availability.

    * If a B-Channel is not available, continue to empty the queue and
    monitor for queue fullness and B-Channel(s) availability.

    Following this heuristic allows the user the freedom to use the ISDN
    resources in multiple methods without affecting the ability to
    augment bandwidth when available. For example, the user may be
    having an ISDN-voice call simultaneously with the use of the AO/DI.

Holdrege                                                        [Page 9]

I-D                      Always On Dynamic ISDN               March 2000

De-allocating Bandwidth

    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.

An Example Heuristic for De-allocating Bearer Channels

    An activity timer is a simple method for deciding when BACP should
    be used to release the B-Channels.  If no activity is seen within 5
    seconds of the end of the transfer, the channels should be releases.

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

    * When looking at Web pages, a good activity timer is 5-10 seconds.
    After suchtime it probably means the users is studying the received
    materials and will be absorbed for several tens of seconds longer.

    * For email, once messages have been exchanged between the client
    and the post office server, release the B-Channels.

De-allocating Bearer Channels for Other Applications

    A reason to de-allocate a B-Channel is to allow the user access to a
    voice call, either incoming or outgoing.

    The CPE is notified of an incoming call through the Q.931 messages.
    In response, the CPE can surrender a B-Channel, if necessary, or
    optionally forward the call to another number (such as an answering
    service), or decide to ignore the incoming call.

    If the CPE is at the S/T interface, it can monitor for other ISDN
    devices seeking to place outgoing voice calls.  When it detects an
    outbound call, it can surrender a B-Channel to the other device. The
    exact behavior of the CPE regarding bandwidth deallocation is
    vendor-dependent.

    Network Architecture from the Switch to the Internet Service
    Provider

    The network architecture is an important consideration to understand
    the potential impact of services - in fact the reason to use AO/DI
    is to help alleviate network congestion associated with the trend
    towards more data networking.

X.25 Network Utilization

    When an X.25 call is made, the packets are assigned to a specific
    trunk group and are not changed while the X.25 call is active; in
    other words, the logical X.25 circuit is bound to a physical
    channel.  The binding of a subscriber's X.25 packet traffic to a
    specific aggregation channel depends on the type of connection made.

Holdrege                                                       [Page 10]

I-D                      Always On Dynamic ISDN               March 2000

    For the PVC this binding is permanent, whereas for the SVC the
    binding lasts as long as the circuit as active.

    For example, an ISP may subscribe to a X.25 service carried within
    one of the B-Channels of a PRI.  This B-Channel can multiplex up to
    64 X.25 circuits (users) simultaneously.  Typically, this binding is
    not problematic.  However, because the physical channel is
    statistically multiplexed over many users, then under certain
    circumstances it is possible that the users whose X.25 traffic is
    bound to this B-Channel will not get sufficient throughput.

    The concern is that a few users could opt to use only D-Channel X.25
    for all data exchange in the hope that this could lead to lower
    bills.  The attendant worry these users could consume all the
    available bandwidth, thus "starving" the other users for bandwidth.

    This concern is somewhat unrealistic because:

    First, the concern implies that these users are willing to forebear
    low throughput.  Were they really willing to do so, they would have
    opted to use a lower-speed analog modem with a flat-rate tariff.  We
    assume that (1) users are attracted to access the Internet through
    ISDN for its higher throughput, and (2)choose AO/DI because it is a
    more compelling user model and is more cost effective than a purely
    switched-circuit access.

    Second, as multiple logical circuits are crowded into the same
    physical channel, the throughput of all the users will decrease as
    the protocol windowing and acknowledgments impose delays.

    Third, this problem degenerates gracefully under AO/DI.  If the D-
    Channel X.25 throughput to too small, the B-Channel(s) are added.

SVC Lifetimes

    A concern voiced about the duration of an SVC being used for AO/DI.
    The concerns are based on several factors:

    * The "binding" issue discussed in the section above.

    * A desire to be able to rebalance the load should "binding" become
    a problem.

    * The number of SVCs that a modern central office can host
    simultaneously due to memory and processing constraints in the
    Packet Handlers.

    To allay these concerns, it has been suggested that AO/DI be
    recommended with an option to use inactivity timers in conjunction
    with SVCs.  The notion being that when no traffic is detected within
    some interval, such 5 minutes, that the SVC be disconnected.  When
    the user (or more likely the user application) attempts to query the
    ISP (such as for email) the SVC would be re-established, typically
    without the user becoming aware of the dial-up delay.

Holdrege                                                       [Page 11]

I-D                      Always On Dynamic ISDN               March 2000

    Short-lived SVCs seem unnecessary for several reasons:

    * As proposed, AO/DI is symmetric in that both the ISP and the
    client can be used as servers while retaining the model that the ISP
    subscriber originates calls to the ISP.  Switching to an inactivity
    timer would cause the ISP to originate the packet SVC to the
    subscriber.  While this model could work, given the current business
    practices of the ISPs, they will not readily adopt this method.

    * While, the above point seems negative, it should be contrasted
    with the current practice of long-duration calls (both analog and
    ISDN) and the adverse impact of this behavior on the public
    telephony network.

    * As LECs become ISPs in their own right, they may wish to retain
    the current ISP networking practices with respect to call
    origination.

    * As applications become more distributed, such as downloaded Java
    applets, it becomes very likely that the SVC inactivity timer would
    never be exceeded, hence the SVC would not be disconnected.

    The ideal way to resolve these issues is through real-world
    experience through trial deployments.  It should be clear that there
    are complex interactions between user behaviors, network impacts,
    and tariffs that are difficult to predict - much the same as the
    Internet phenomena itself.

X.25 Parameters

    * Packet size default = 128

    * Window size = 2 (mod 8)

    * Call type = SVC

    * (PVCs are not in AO/DI, but may exist at CPE Termination. Assigned
    PVCs start at LCN 01 and increment)

    * TEI = 21

    * # of logical channels (LCN) = 4 (01,02,03,04 starting with 01)

    * Throughput class = 9600 bps

    * X.25 flow control negotiation  = enabled

    * client must be able to negotiate at least to default reverse
    charging allowed @ client

    * reverse charging accepted @ router

    * 1988 blue book X.25

Holdrege                                                       [Page 12]

I-D                      Always On Dynamic ISDN               March 2000

    * no d-bit modification

    * q-bit should be ignored and the sender should set it to zero

    * CUD up to 16 octets in length

    * no fast select

    * ability for the client to handle separate DN for D X.25  (for
    local # portability)

Use of Call User Data field in X.25 Call Request packet for AO/DI

    Octet 1: Protocol Identifier for AO/DI to be selected from reserved
    values in ISO/IEC TR 9577

    Octets 2-4: Reserved for future AO/DI use.  Optional.  If these
    octets are present, then: *  these octets must be filled in all
    zeros (0).  *  octet must be present in its entirety

    The absence of Octet 2 or the presence of all zeros in Octet 2
    represents that AO/DI Version 1 is operating.

    Octets 5 - 16:  Optional.  Available for supplier-
    specific/application-specific use.  If present, then an integral
    number of octets must be present.

    Octet 2 must be present in order for Octets 3 to 16 to be utilized.
    If AO/DI Version 1 is operating and Octets 3 to 16 are not utilized,
    then: Octet 2 may or may not be inserted into the Call User Data
    field.  (That is, equipment that originates AO/DI SVCs has the
    option as to whether it will utilize Octet 2.  Equipment that
    terminates AO/DI SVCs must be capable of accepted CUDs with and
    without Octet 2.)

Connections to the ISP

    Routing D-Channel X.25 packet calls to the Internet service provider
    can be done more efficiently without over-loading the  switch trunk
    lines and the switching fabric.   For efficiencies, the X.25 can be
    concentrated into standard WAN connections (e.g., T1 or PRI)
    between the central office and the Internet service provider;
    several  central office-to-Internet service provider options are
    available and can be decided on their own merits between the Local
    Exchange Carrier and the Internet service provider.

X.25 Translations

    The general goals for the translations are that they be 1.) user-
    friendly, 2.) network-friendly, and 3.) switch-specific.

X.25 Translation Caveats:

Holdrege                                                       [Page 13]

I-D                      Always On Dynamic ISDN               March 2000

    1. These translations are for the client, not for the router.

    2. The reverse charging parameter, which is set to No in the
    translations, refers to Reverse Charging Acceptance.  This parameter
    does not prohibit Reverse Charging Allowed  (Reverse Charging
    Allowed gives the client the ability to originate calls containing
    the Reverse Charging facility).

    3. The Directory Numbers assigned for D-channel packet are different
    from the other Directory Numbers assigned to the terminal for voice
    or circuit-mode data.

AO/DI Stability and Robustness

    It should also be recognized that AO/DI is inherently stable in
    these regards.  This is achieved through the following behaviors:

    When bandwidth becomes insufficient, AO/DI attempts to augment the
    bandwidth.  Failure to augment bandwidth results in continuing with
    a slower-than-desired throughput, but no damage.  If the D-Channel
    throughput 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.

    Given the discussions above regarding the use of SVCs and network
    congestion, it is clear that some behaviors can be incorporated into
    AO/DI to help overall robustness.   One possiblel behavior is to put
    a "bandwidth limiter" on the D-Channel that slows the transmission
    of packets through the D-Channel when a threshold is exceeded over
    some relatively short time interval.

    Kudos: The authors wish to thank Joe Boucher for his contribution on
    the D-Channel Idling, Scott Stamp for his contributions on X.25
    translations, and Pierre-Luc Provencal for his contribution on the
    BACP phone deltas and efforts to register an NLPID for X.25 specific
    to AO/DI.

    This work came from the Vendors ISDN Association members (especially
    those on the AO/DI technical subcommittee) and thanks to the
    National ISDN Council for their enthusiasm and persistence.

References

    K. Sklower, B. Lloyd, G. McGregor, D. Carr, "The PPP Multilink
    Protocol" RFC 1990

    Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD  51,
    RFC 1661

    K. Smith, "Ascend's Multilink Plus (MP+)," RFC 1934

    C. Richards, K. Smith, "The PPP Bandwidth Allocation Protocol (BAP),
    The PPP Bandwidth  Allocation Control Protocol (BACP)" RFC 2125

Holdrege                                                       [Page 14]

I-D                      Always On Dynamic ISDN               March 2000

    A. Kuzma, et al, "AO/DI Network Architecture," Revision 2, Vendors
    ISDN Association white paper, December 1996.

    Simpson, W., Editor, "PPP in X.25," RFC 1598

    ITU-T Q.922 - ISDN Data Link Layer Specification for Frame Mode
    Bearer Services

    ITU-T Q.931 - ISDN User-Network Interface Layer 3 Speicifcation for
    Basic Call Control

    ITU-T X.25 - Interface Between Data Terminal Equipment (DTE) and
    Data Circuit-Terminating Equipment (DCE) for Terminals Operating in
    the Packet Mode and Connected to Public Data Networks by Dedicated
    Circuit

Acknowledgements

    This work is the result of the efforts of Andy Kuzma in the Vendors
    ISDN Association. The author would like to acknowledge the wise
    counsel from James Carlson and Jonathan Goodchild.

Author's Address

    Matt Holdrege
    Lucent Technologies
    223 Ximeno Ave.
    Long Beach, CA 90803  USA
    [email-masked]

Holdrege                                                       [Page 15]

Karl Fox <[email-masked]>
Key fingerprint = 4159 B4AD 339D 4E2A 255F  9CC4 9DA9 CB4B B16D E2B1

---

From: Thomas Narten <[email-masked]>
Date: Tue, 27 Mar 2001 13:53:28 -0500

> draft-ietf-pppext-aodi-02.txt (attached, as it has expired) be advanced to 

Is that Informational, or Proposed Standard (there is no Informational
Standard).

Thomas