One document matched: draft-ietf-pppext-aodi-01.txt
Differences from draft-ietf-pppext-aodi-00.txt
Always On Dynamic ISDN (AODI).
<draft-ietf-pppext-aodi-01.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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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 (1999). 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
Kuzma & Holdrege [Page 1]
I-D Always On Dynamic ISDN June 1999
networks (Intranet) typically used for businesses. AO/DI does not
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.
Using the X.25 over the D-Channel, while admittedly not the most
efficient protocol stack, allows AO/DI to take advantage of the
existing packet handlers at the central offices. The link
associated to the D-Channel X.25 packet connection is used as the
primary link of the multilink protocol.
It is possible to offer a full-duplex, always-available services
based on the fact that Because the ISDN phsyical-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-
Kuzma & Holdrege [Page 2]
I-D Always On Dynamic ISDN June 1999
switched fabric of the switch, which reduces the impact to the
telephony network.
Switched Virtual Circuits (SVCs) and Permanent Virtual Circuits (PVCs)
between the subscriber (client) and ISP.
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
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.
* 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.
* 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 it's 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 PC
being turned off, an equipment problem due to hardware or software
in the network or the PC, 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.
Kuzma & Holdrege [Page 3]
I-D Always On Dynamic ISDN June 1999
* A LAPD failure, such as inability to establish a DLCI.
While X.25 disconnects are considered highly unlikely, it is a
matter of further study to control the frequency at which the PC
attempts to re-establish the SVC. As certain failures (e.g. other
than a PC problem) have a remote possibility to result in hundreds
of PC's simultaneously attempting to re-establish their connections
which could be a substantial burden on the switch.
When the X.25 SVC is disconnected, the PC 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.
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 recommends a method to
substitute the X.25 header for the PPP header.
It is believed that the overhead of two bytes is more than
compensated by the fact that any link in AO/DI could now be treated
as dial-up PPP connection due to the protocol stack layering that
resulted; i.e., the same PPP process is used for B-Channels and the
X.25 channel.
Physical Layer Requirements
From RFC 1598: PPP treats X.25 framing as a bit synchronous link.
Kuzma & Holdrege [Page 4]
I-D Always On Dynamic ISDN June 1999
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
hex). Any subsequent octet in this CUD is extraneous and MUST be
ignored.
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.
In the interim, AO/DI recommends that until ISO the call originator
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 fields are transmitted from left
to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p(r) |M|p(s) |0| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Kuzma & Holdrege [Page 5]
I-D Always On Dynamic ISDN June 1999
The PPP Protocol field and the following Information and Padding
fields are described in RFC 1990.
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. We
believe this approach better isolates the protocol layers and avoids
the need for a special PPP engine for X.25 transport connection.
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 uses 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 dial
the 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 multilink 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.
Even with asymmetric multilink protocols there are possibilities to
mitigate the asymmetry of multilink protocols, such as Internet
service providers giving their subscribers toll-free numbers.
Please note that the availability of toll-free local data call
services are subject to availability from the Local Exchange
Carrier.
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
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.
Kuzma & Holdrege [Page 6]
I-D Always On Dynamic ISDN June 1999
* 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 users 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.
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.
Kuzma & Holdrege [Page 7]
I-D Always On Dynamic ISDN June 1999
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
and the receiver.
Options
An explicit "Idle Link" command and response handshake would be the
Kuzma & Holdrege [Page 8]
I-D Always On Dynamic ISDN June 1999
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.
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
Kuzma & Holdrege [Page 9]
I-D Always On Dynamic ISDN June 1999
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.
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
Kuzma & Holdrege [Page 10]
I-D Always On Dynamic ISDN June 1999
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.
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
without activity 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
Kuzma & Holdrege [Page 11]
I-D Always On Dynamic ISDN June 1999
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.
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
Kuzma & Holdrege [Page 12]
I-D Always On Dynamic ISDN June 1999
some interval, such 5 minutes, that the SVC be disconnected. When
the user (or more likely the PC) 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.
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
Kuzma & Holdrege [Page 13]
I-D Always On Dynamic ISDN June 1999
* reverse charging accepted @ router
* 1988 blue book X.25
* no d-bit modification
* q-bit should be ignored and the sender should set it to zero
* CVD up to 16 octets in length
* no fast select
* ability for the client to handle separate DN for D X.25 (for
local # portability)
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.)
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;
Kuzma & Holdrege [Page 14]
I-D Always On Dynamic ISDN June 1999
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:
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
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.
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
Kuzma & Holdrege [Page 15]
I-D Always On Dynamic ISDN June 1999
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
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
Author's Address
Andrew Kuzma
Intel Corporation
MS: JF2-007
5200 NE Elam Young Parkway
Hillsboro, OR 97124, USA
Andy_Kuzma@ccm.jf.intel.com
Matt Holdrege
Ascend Communications
1701 Harbor Bay Parkway
Alameda, CA 94502 USA
matt@ascend.com
Kuzma & Holdrege [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-22 14:46:54 |