Internet Draft 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." 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 (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 holdrege@lucent.com Holdrege [Page 15]