idnits 2.17.1 draft-ietf-pppext-aodi-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 15 longer pages, the longest (page 1) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 210: '... The link MUST be full-duplex, but ...' RFC 2119 keyword, line 226: '... field MAY contain more than one oc...' RFC 2119 keyword, line 228: '...PP encapsulation MUST be indicated by ...' RFC 2119 keyword, line 232: '... in this CUD is extraneous and MUST be...' RFC 2119 keyword, line 235: '... call originator MUST set the NLPID of...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 315 has weird spacing: '...idth of the D...' == Line 722 has weird spacing: '...ing the switc...' == Line 726 has weird spacing: '...several centr...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The PPP FCS MUST not be used in the X.25 PPP encapsulation on the D channel. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '5' on line 223 looks like a reference -- Missing reference section? '3' on line 239 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPPEXT Working Group Matt Holdrege 2 Internet Draft ipVerse 3 Category: Informational 5 Always On Dynamic ISDN (AODI). 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as 22 "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 To view the entire list of current Internet-Drafts, please check 31 the "1id-abstracts.txt" listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 33 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 34 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 35 (US West Coast). 37 Copyright Notice 39 Copyright (C) The Internet Society (2001). All Rights Reserved. 41 Introduction: 42 Always On/Dynamic ISDN (AO/DI) is a networking service that provides 43 an always-available connection to TCP/IP-based services through a 44 specific wide area connection. This service provides several 45 advantages over current practices for dial-up access to Internet 46 services. 48 * For the end-user, there is no need to dial-up the service each 49 time access is desired. 51 * For the Internet service provider, it is possible to give the end- 52 user a notification, such as the arrival of new mail. 54 * For the Local Exchange Carrier, the switched circuit trunk 55 utilization is more efficient. 57 It should be understood that TCP/IP is the network protocol of 58 choice for public data networks (Internet), and private data 59 networks (Intranet) typically used for businesses. AO/DI does not 61 I-D Always On Dynamic ISDN April 2001 63 differentiate whether the user is connected to either the Internet 64 or an Intranet, or both simultaneously. Further, the issues 65 involved in either case are very similar as far as client behaviors 66 and impact on the public telephony networks. 68 The potential impact of Internet access is quite large. According 69 to a recent survey, only 24% of US households have a computer with a 70 modem. It's likely that most of these systems are not used on a 71 regular basis for anything, much less Internet access. But this is 72 changing quickly and already the relatively small number of users 73 are having an impact on the network. There are similar predictions 74 for other countries. 76 Description of AO/DI Operation 78 AO/DI is based on using existing infrastructure of modern central 79 office switches and using The Bandwidth Allocation Control Protocol 80 (RFC 2025). 82 * Modern central offices are capable of supplying ISDN, and many of 83 these central office switches are configured with X.25 packet 84 handlers. 86 * BACP is available in many remote access products. 88 The basic idea of AO/DI is that an ISDN D-Channel X.25 connection is 89 made from the subscriber to the Internet service provider. The 90 multilink PPP protocol and TCP/IP protocols are encapsulated within 91 the X.25 logical circuit carried by the D-Channel. The Bearer 92 Channels are invoked as additional bandwidth is needed. The Bearer 93 Channels use the multilink protocol without the Q.922 and X.25 94 encapsulation used on the D-Channel. I.e., a circuit-switched 95 connection between the ISP and the client is established over the B- 96 Channels over which IP packets are sent through PPP encapsulation. 98 It is possible to offer a full-duplex, always-available services 99 based on the fact that Because the ISDN physical-layer signalling 100 (2B1Q synchronous modulation) and the Q.922 link layer are kept 101 running at all times, even when there are no Q.931 messages being 102 transceived. The physical and link layers allow for packets to be 103 sent across a connection-oriented X.25 virtual circuit to be 104 established between the Internet Service Provider and the 105 subscriber. 107 Further, because the D-Channel X.25 packets are handled at the 108 central office by the X.25 packet handler, it is possible to route 109 these packets without first crossing the time-division circuit- 110 switched fabric of the switch, which reduces the impact to the 111 telephony network. 113 X.25 provides for two call types: a switched virtual circuit (SVC) 114 and a permanent virtual circuit (PVC). Considerations are: 116 * Not all the worlds Packet Handler implementations can be 118 I-D Always On Dynamic ISDN April 2001 120 guaranteed to support PVCs. 122 * Some service providers that own the ISDN infrastructure may not be 123 an ISP in their own right and may be providing ISPs with a standard 124 X.31/X.75 delivery of D-Channel traffic. If this is the case, there 125 is a need to use (and change) X.121 addresses in order for a user 126 (of the CPE) to be able to change ISPs easily. I.e., using an SVC 127 makes is simpler for the users to move to other ISPs, or to 128 establish a connection to a corporate Intranet, as is required for 129 telecommuters. 131 * An SVC can be treated as a "permanent" connection. Once the call 132 is established it does need not to be cleared and can remain in the 133 data state in a similar manner to a PVC. 135 * The success of X.25 networks was due in part to the use of SVCs 136 and the ease of provisioning. Frame Relay, although successful, is 137 extremely complex to provision because of its PVC implementation and 138 the same would apply to a managed service provider solution. 140 Given these considerations, AO/DI uses SVCs. 142 Response to the Loss of an SVC 144 Under certain conditions, the X.25 SVC may be cleared 145 (disconnected). 147 Conditions under the SVC could be cleared include, but are not 148 limited to: 150 * Inability to contact the subscriber. This could be due to the 151 user terminal being turned off, an equipment problem due to hardware 152 or software in the network or the user terminal, etc. 154 * The result of the ISP clearing the call to redistribute the X.25 155 SVC across other LEC facilities due to traffic congestion. This 156 action might be undertaken by an ISP to help distribute network 157 loads across facilities. 159 * An equipment problem in the network. 161 While X.25 disconnects are considered highly unlikely, it is a 162 matter of further study to control the frequency at which the user 163 terminal attempts to re-establish the SVC. As certain failures (e.g. 164 other than a user terminal problem) have a remote possibility to 165 result in hundreds of endpoints simultaneously attempting to re- 166 establish their connections which could be a substantial burden on 167 the switch. 169 When the X.25 SVC is disconnected, the terminal should attempt to 170 re-establish the SVC at the earliest convenient time. It is 171 suggested that the rate of re-establishments attempts within be 172 limited to avoid excessive setup requests sent to the network. 174 I-D Always On Dynamic ISDN April 2001 176 Network Connection Sequence 178 An example of the calling sequence is shown below: 180 * The subscriber makes an X.25 connection to the Internet Service 181 Provider (or Intranet Service Provider) 183 * When additional bandwidth is needed, the appropriate phone numbers 184 are exchanged between the subscriber's equipment and the Internet 185 service provider's equipment to allow additional Bearer channels to 186 be dialed. The Bearer Channels are routed through the switched 187 fabric directly to the Internet service provider without the use of 188 the packet handlers in the central office. Subsequent to successful 189 connection, the multilink protocols are resolved to aggregate the 190 additional bandwidth into a single transport connection. 192 * The X.25 SVC will stop sending PPP payload when one or more B 193 channels are in use. However, BACP messages may still be sent over 194 the X.25 circuit. 196 The Use of IETF RFC 1598 198 The IETF provides some guidelines for the use of PPP over X.25 in 199 RFC 1598. Strictly speaking, RFC 1598 does not apply to AO/DI, but 200 it has been used as a source of many useful concepts. 202 The essential difference between AO/DI and RFC 1598 is that AO/DI 203 treats X.25 as another dial-up resource, over which PPP is used to 204 frame the data transmission, whereas RFC 1598 describes a way to 205 replace the default HDLC header with an X.25 expanded HDLC header. 207 Physical Layer Requirements 209 From RFC 1598: PPP treats X.25 framing as a bit synchronous link. 210 The link MUST be full-duplex, but MAY be either dedicated 211 (permanent) or switched. 213 AO/DI uses the X.25 as a synchronous transport; i.e., there are not 214 character-based escape codes. The connection type is Switched 215 Virtual Circuit, as previously discussed. 217 Call User Data (CUD) Field 219 From RFC 1598: When the link is configured as a Switched Virtual 220 Circuit (SVC), the first octet in the Call User Data (CUD) Field 221 (the first data octet in the Call Request packet) is used for 222 protocol de-multiplexing, in accordance with the Subsequent Protocol 223 Identifier (SPI) in ISO/IEC TR 9577 [5]. This field contains a one 224 octet Network Layer Protocol Identifier (NLPID), which identifies 225 the encapsulation in use over the X.25 virtual circuit. The CUD 226 field MAY contain more than one octet of information. 228 The PPP encapsulation MUST be indicated by the PPP NLPID value (CF 230 I-D Always On Dynamic ISDN April 2001 232 hex). Any subsequent octet in this CUD is extraneous and MUST be 233 ignored. 235 The call originator MUST set the NLPID of the CUD to 0xCF. 237 The Data Link Layer 239 From RFC 1598: Since both "PPP in HDLC Framing" [3] and X.25 use ISO 240 3309 as a basis for framing, the X.25 header is easily substituted 241 for the smaller HDLC header. 243 The PPP Protocol field and the following Information and Padding 244 fields are described in RFC 1661. 246 AO/DI recommends against header substitution by the transmitter. 247 AO/DI uses the X.25 as a virtual PPP dial-up connection, so we 248 recommend that the PPP header be part of the X.25 payload. This 249 approach better isolates the protocol layers. 251 It is desirable that X.25 receivers that expect the header 252 substitution, also be able to properly function when the PPP header 253 is included the X.25 payload. 255 The PPP FCS MUST not be used in the X.25 PPP encapsulation on the D 256 channel. 258 Underlying Multilink Protocol Behaviors 260 AO/DI MAY use the BACP multilink protocol to negotiate for 261 bandwidth, manage phone number exchange, and to aggregate the 262 bandwidth of subsequent connections. 264 In today's multilink protocols (RFC's 1990 & 1934), the session 265 originator (the end that placed the first call) is required to add 266 the following call, thus incurring the additional charges, hence 267 they are not symmetric in the sense that the session originator is 268 obliged to add bandwidth. This is an acceptable model to many 269 people, but not universally so. BACP, being a symmetric control 270 protocol, allows either end of the Internet service to place a phone 271 call to the other so that additional bandwidth can be added to the 272 connection. Either side may request the other to originate the call 273 or may refuse the request to originate the call, and may terminate a 274 link in a bundle. 276 In any case, it may be desirable to have a user interface that 277 confirms with the user the request for additional bandwidth, should 278 the users be sensitive to these charges. 280 Strictly speaking, client (CPE) behavior is left to vendor-specific 281 implementation. A vendor may choose to provide differentiation in 282 the features, behaviors, and look-and-feel of the dialer (the 283 software that controls the addition/subtraction of B-Channels) to 285 I-D Always On Dynamic ISDN April 2001 287 meet customer requirements for a specific business environment. For 288 example: 290 * for a voice call, the dialer would need to grant exclusive access 291 of one of the B-Channels. 293 * for requests to add B-Channels, the dialer may query the user to 294 grant permission depending on the requester; a remote corporate 295 access request might be granted automatically, whereas an unknown 296 source would require manual intervention. 298 Invoking Additional Bandwidth 300 Given the relatively low net bandwidth of the Internet service due 301 to the low bandwidth of the D-Channel (16 kbps total with 9600 bps 302 guaranteed X.25 frame throughput) and the protocol encapsulation, 303 TCP/IP over the D-Channel X.25 has limited applications. However, 304 there are significant application domains where the low-bandwidth, 305 always-available are useful such as 307 * basic ASCII email services, 309 * news feeds, and 311 * automated data collection. 313 Using BACP to Increase Bandwidth 315 To increase the overall bandwidth beyond low-bandwidth of the D- 316 Channel X.25 circuit, BACP messages are used to signal when Bearer 317 Channels should be added to the link bundle. The B-Channels are 318 invoked to temporarily boost data throughput, then the B-Channels 319 are disconnected. This mode of operation statistically multiplexes 320 the switch fabric and inter-office trunk lines across more users, 321 thus reducing the traffic impact to the wide area network. Using 322 the B-Channels for bandwidth-on-demand is good for both the Local 323 Exchange Carrier and the Internet service provider as compared to 324 having users "camp on" a Bearer Channel. 326 AO/DI discourages X.25 spoofing (similar to the current method for 327 spoofing ISDN B-Channel and modem dial-up connections) because 1) 328 this is contrary to the design goals for AO/DI to provide constant 329 connectivity without further intervention of the applications or the 330 operating system, 2) X.25 spoofing is likely to create excessive 331 numbers of X.25 setup messages which can degrade the network and 332 increase the costs to the user, and 3) as distributed applications 333 become more common, spoofing will become much less useful as 334 connections will tend to last longer. 336 This recommendation makes it possible for users to operate AO/DI 337 capable protocol stacks even when the user's ISDN network interface 338 card does not support AO/DI, or if the user does not have an AO/DI 339 service due either to lack of facilities at the users ISP and/or at 340 the LEC. 342 I-D Always On Dynamic ISDN April 2001 344 BACP Phone Deltas 346 BACP was designed for use over a network with only a single 347 numbering plan; i.e. multiple analog modem lines or multiple B- 348 Channels. However, X.25 addresses are only E.164 or X.121. 349 Further, special dialing sequences, such as '9' to access an outside 350 line may not be applicable to X.25 calls. 352 Additional numbers are exchanged in BACP using the concept of 353 "deltas" whereby only the shortest string of digits needed to convey 354 the change are sent. Since this is not guaranteed to work due to 355 the differing numbering plans, AO/DI has a set of recommendations: 357 * Separate X.25 Dial-up setup (likely different than E.164) 359 * Don't use X.25 as base for first B-Channel delta; i.e. send first 360 B-Channel in its entirety 362 * Second B-Channel also sent to client in its entirety 364 * Phone #s are national format only (e.g. N.A. 10 digits: area 365 code+prefix+# ) 367 * Local dialing exceptions are configured at the client (e.g. 368 leading 9 to get outside line, or dialing codes for international 369 access) 371 * The technical subcommittee suggests the software provide an 372 ability to have user-entered defaults. 374 D-Channel Idling 376 The following text proposes a method for idling a link of a 377 Multilink PPP (MP-RFC 1990) bundle. 379 Motivation 381 An AO/DI ISDN MP bundle consists of one or two B-channel links, each 382 running at either 56Kbps or 64Kbps, and an X.25 D-channel link 383 running at 9600bps. To improve throughput and reduce connection 384 costs, it is desirable to stop transferring data over the D-channel 385 whenever at least one B-channel is in the bundle. 387 Idling an MP link, however, causes a problem with the algorithm for 388 detecting lost fragments. This algorithm depends on the value M; 389 only fragments with sequence numbers less than M will be detected as 390 lost. Since M is never incremented if a link is idle, the MP 391 receiver could stall indefinitely (or until a timer expires) if a 392 fragment is lost while one of the links is idle. 394 What this all means is that if one side of an MP connection decides 395 to stop transmitting data on one of the links, the receiver must be 396 able to adapt its receiving algorithm accordingly. Idling a member 397 link, therefore, must occur by mutual agreement between the sender 399 I-D Always On Dynamic ISDN April 2001 401 and the receiver. 403 Recommended Behavior 405 For AO/DI-compatible systems, the implicit algorithm for idling the 406 D-channel shall be as follows: 408 * When a link of 56Kbps or faster is added to an MP bundle that 409 contains a link of 9600bps or slower: 411 1. Both transmitters should immediately cease transmitting all "re- 412 directable" packets on the slow link and instead transmit all such 413 packets over the faster link(s). A packet is deemed re-directable if 414 it is able to be transmitted using the multilink procedure, as 415 described in RFC 1990. The only packets currently NOT able to be 416 redirected are LCP Configure-Request, -Reject, -Ack, -Nak, 417 Terminate-Request, or -Ack packets. Also BAP packets should remain 418 on the X.25 link. 420 2. Both receivers should exclude the slow link from the calculation 421 of M. For simpler implementations, this exclusion could be 422 immediate, but this increases the chances of losing any fragments 423 currently being sent on the slow link. For more robust 424 implementations, the exclusion could be started after a certain 425 (short) time has elapsed. This would give any fragments currently on 426 the slow link a chance to be received successfully. 428 * A robust receiver should: 430 * Receive and process successfully any fragments received on the 431 slow link, as long as the sequence number is greater than M. 433 * Discard any fragments received on the slow link that have a 434 sequence number less than M. 436 Note that this approach requires that both peers adhere to the rules 437 described above. This should be acceptable since we may specifically 438 NOT want to work with equipment that continues to load the D- 439 channel. 441 For a longer term solution, we may want to consider an extension to 442 MP or BAP that would include "Idle-Link" and "Idle-Link-Ack" 443 primitives. 445 Traffic Estimates 447 Based on these estimates, the following triggers can be used as a 448 stimulus for requesting additional bandwidth. 450 Triggers for Requesting Additional Bandwidth 452 Bearer channels are added if the traffic will take more that 5 453 seconds to transmit through the D-Channel X.25, or if the pending 454 data is larger than 7500 bytes. 456 I-D Always On Dynamic ISDN April 2001 458 When the amount of data is larger than 7500 bytes, we invoke a B- 459 channel; further, this B-channel establishment, negotiation, and 460 initialization for data takes 3 seconds, meaning the D-Channel X.25 461 is active for only 3 seconds, or approximately 4500 bytes, before 462 data is no longer sent across it. Thereafter, as long as the B- 463 Channel(s) is active, the X.25 is active-idle; i.e., the connection 464 is maintained, but no data is transceived. 466 Note: AO/DI receivers should be capable of continuing to receive 467 data on the X.25 link as well as B-Channels. This allows simplistic 468 MLPPP-based systems to be used. (Experience has shown that this 469 simplistic approach is actually slower than the recommended D- 470 Channel Idling, and more susceptible to error conditions.) 472 An Example Heuristic for Adding Bearer Channels 474 One method for determining when additional bandwidth needs to be 475 added is described below. 477 * Is the packet service outbound queue getting full? Where full 478 means that at current throughput, will it take longer than 5 seconds 479 to empty? Will it take longer than 10 seconds? 481 * If the time to empty the queue is less than 5 seconds, use D- 482 Channel X.25 without invoking a B-Channel. 484 * If the time to empty the queue is more than 5 second, but less 485 than 10, use the D-Channel X.25 to convey a BAP request for a B- 486 Channel. 488 * If a B-Channel is available, use the multilink protocol to augment 489 the packet service connection. 491 * If a B-Channel is not available, continue to empty the queue and 492 monitor for queue fullness and B-Channel availability. 494 * If the time to empty the queue is more than 10 seconds, request 495 two B-Channels. 497 * If two B-Channels are available, use the multilink protocol to 498 augment the packet service connection. 500 * If only one B-Channel is available, augment the connection with 501 the single B-Channel. Continue to empty the queue and monitor for 502 queue fullness and B-Channel availability. 504 * If a B-Channel is not available, continue to empty the queue and 505 monitor for queue fullness and B-Channel(s) availability. 507 Following this heuristic allows the user the freedom to use the ISDN 508 resources in multiple methods without affecting the ability to 509 augment bandwidth when available. For example, the user may be 510 having an ISDN-voice call simultaneously with the use of the AO/DI. 512 I-D Always On Dynamic ISDN April 2001 514 De-allocating Bandwidth 516 After completing the data transfer that required invocation of the 517 additional B-Channel(s), the B-Channels need to be disconnected so 518 the circuit-switched resources can be returned to the trunk pool. 519 BACP supports such requests. 521 An Example Heuristic for De-allocating Bearer Channels 523 An activity timer is a simple method for deciding when BACP should 524 be used to release the B-Channels. If no activity is seen within 5 525 seconds of the end of the transfer, the channels should be releases. 527 A more sophisticated method would look at the application that 528 generated the request to guide the use of BACP. For example: 530 * When looking at Web pages, a good activity timer is 5-10 seconds. 531 After suchtime it probably means the users is studying the received 532 materials and will be absorbed for several tens of seconds longer. 534 * For email, once messages have been exchanged between the client 535 and the post office server, release the B-Channels. 537 De-allocating Bearer Channels for Other Applications 539 A reason to de-allocate a B-Channel is to allow the user access to a 540 voice call, either incoming or outgoing. 542 The CPE is notified of an incoming call through the Q.931 messages. 543 In response, the CPE can surrender a B-Channel, if necessary, or 544 optionally forward the call to another number (such as an answering 545 service), or decide to ignore the incoming call. 547 If the CPE is at the S/T interface, it can monitor for other ISDN 548 devices seeking to place outgoing voice calls. When it detects an 549 outbound call, it can surrender a B-Channel to the other device. The 550 exact behavior of the CPE regarding bandwidth deallocation is 551 vendor-dependent. 553 Network Architecture from the Switch to the Internet Service 554 Provider 556 The network architecture is an important consideration to understand 557 the potential impact of services - in fact the reason to use AO/DI 558 is to help alleviate network congestion associated with the trend 559 towards more data networking. 561 X.25 Network Utilization 563 When an X.25 call is made, the packets are assigned to a specific 564 trunk group and are not changed while the X.25 call is active; in 565 other words, the logical X.25 circuit is bound to a physical 566 channel. The binding of a subscriber's X.25 packet traffic to a 567 specific aggregation channel depends on the type of connection made. 569 I-D Always On Dynamic ISDN April 2001 571 For the PVC this binding is permanent, whereas for the SVC the 572 binding lasts as long as the circuit as active. 574 For example, an ISP may subscribe to a X.25 service carried within 575 one of the B-Channels of a PRI. This B-Channel can multiplex up to 576 64 X.25 circuits (users) simultaneously. Typically, this binding is 577 not problematic. However, because the physical channel is 578 statistically multiplexed over many users, then under certain 579 circumstances it is possible that the users whose X.25 traffic is 580 bound to this B-Channel will not get sufficient throughput. 582 The concern is that a few users could opt to use only D-Channel X.25 583 for all data exchange in the hope that this could lead to lower 584 bills. The attendant worry these users could consume all the 585 available bandwidth, thus "starving" the other users for bandwidth. 587 This concern is somewhat unrealistic because: 589 First, the concern implies that these users are willing to forebear 590 low throughput. Were they really willing to do so, they would have 591 opted to use a lower-speed analog modem with a flat-rate tariff. We 592 assume that (1) users are attracted to access the Internet through 593 ISDN for its higher throughput, and (2)choose AO/DI because it is a 594 more compelling user model and is more cost effective than a purely 595 switched-circuit access. 597 Second, as multiple logical circuits are crowded into the same 598 physical channel, the throughput of all the users will decrease as 599 the protocol windowing and acknowledgments impose delays. 601 Third, this problem degenerates gracefully under AO/DI. If the D- 602 Channel X.25 throughput to too small, the B-Channel(s) are added. 604 SVC Lifetimes 606 A concern voiced about the duration of an SVC being used for AO/DI. 607 The concerns are based on several factors: 609 * The "binding" issue discussed in the section above. 611 * A desire to be able to rebalance the load should "binding" become 612 a problem. 614 * The number of SVCs that a modern central office can host 615 simultaneously due to memory and processing constraints in the 616 Packet Handlers. 618 To allay these concerns, it has been suggested that AO/DI be 619 recommended with an option to use inactivity timers in conjunction 620 with SVCs. The notion being that when no traffic is detected within 621 some interval, such 5 minutes, that the SVC be disconnected. When 622 the user (or more likely the user application) attempts to query the 623 ISP (such as for email) the SVC would be re-established, typically 624 without the user becoming aware of the dial-up delay. 626 I-D Always On Dynamic ISDN April 2001 628 Short-lived SVCs seem unnecessary for several reasons: 630 * As proposed, AO/DI is symmetric in that both the ISP and the 631 client can be used as servers while retaining the model that the ISP 632 subscriber originates calls to the ISP. Switching to an inactivity 633 timer would cause the ISP to originate the packet SVC to the 634 subscriber. While this model could work, given the current business 635 practices of the ISPs, they will not readily adopt this method. 637 * While, the above point seems negative, it should be contrasted 638 with the current practice of long-duration calls (both analog and 639 ISDN) and the adverse impact of this behavior on the public 640 telephony network. 642 * As LECs become ISPs in their own right, they may wish to retain 643 the current ISP networking practices with respect to call 644 origination. 646 * As applications become more distributed, such as downloaded Java 647 applets, it becomes very likely that the SVC inactivity timer would 648 never be exceeded, hence the SVC would not be disconnected. 650 The ideal way to resolve these issues is through real-world 651 experience through trial deployments. It should be clear that there 652 are complex interactions between user behaviors, network impacts, 653 and tariffs that are difficult to predict - much the same as the 654 Internet phenomena itself. 656 X.25 Parameters 658 * Packet size default = 128 660 * Window size = 2 (mod 8) 662 * Call type = SVC 664 * (PVCs are not in AO/DI, but may exist at CPE Termination. Assigned 665 PVCs start at LCN 01 and increment) 667 * TEI = 21 669 * # of logical channels (LCN) = 4 (01,02,03,04 starting with 01) 671 * Throughput class = 9600 bps 673 * X.25 flow control negotiation = enabled 675 * client must be able to negotiate at least to default reverse 676 charging allowed @ client 678 * reverse charging accepted @ router 680 * 1988 blue book X.25 682 I-D Always On Dynamic ISDN April 2001 684 * no d-bit modification 686 * q-bit should be ignored and the sender should set it to zero 688 * CUD up to 16 octets in length 690 * no fast select 692 * ability for the client to handle separate DN for D X.25 (for 693 local # portability) 695 Use of Call User Data field in X.25 Call Request packet for AO/DI 697 Octet 1: Protocol Identifier for AO/DI to be selected from reserved 698 values in ISO/IEC TR 9577 700 Octets 2-4: Reserved for future AO/DI use. Optional. If these 701 octets are present, then: * these octets must be filled in all 702 zeros (0). * octet must be present in its entirety 704 The absence of Octet 2 or the presence of all zeros in Octet 2 705 represents that AO/DI Version 1 is operating. 707 Octets 5 - 16: Optional. Available for supplier- 708 specific/application-specific use. If present, then an integral 709 number of octets must be present. 711 Octet 2 must be present in order for Octets 3 to 16 to be utilized. 712 If AO/DI Version 1 is operating and Octets 3 to 16 are not utilized, 713 then: Octet 2 may or may not be inserted into the Call User Data 714 field. (That is, equipment that originates AO/DI SVCs has the 715 option as to whether it will utilize Octet 2. Equipment that 716 terminates AO/DI SVCs must be capable of accepted CUDs with and 717 without Octet 2.) 719 Connections to the ISP 721 Routing D-Channel X.25 packet calls to the Internet service provider 722 can be done more efficiently without over-loading the switch trunk 723 lines and the switching fabric. For efficiencies, the X.25 can be 724 concentrated into standard WAN connections (e.g., T1 or PRI) 725 between the central office and the Internet service provider; 726 several central office-to-Internet service provider options are 727 available and can be decided on their own merits between the Local 728 Exchange Carrier and the Internet service provider. 730 X.25 Translations 732 The general goals for the translations are that they be 1.) user- 733 friendly, 2.) network-friendly, and 3.) switch-specific. 735 X.25 Translation Caveats: 737 I-D Always On Dynamic ISDN April 2001 739 1. These translations are for the client, not for the router. 741 2. The reverse charging parameter, which is set to No in the 742 translations, refers to Reverse Charging Acceptance. This parameter 743 does not prohibit Reverse Charging Allowed (Reverse Charging 744 Allowed gives the client the ability to originate calls containing 745 the Reverse Charging facility). 747 3. The Directory Numbers assigned for D-channel packet are different 748 from the other Directory Numbers assigned to the terminal for voice 749 or circuit-mode data. 751 AO/DI Stability and Robustness 753 It should also be recognized that AO/DI is inherently stable in 754 these regards. This is achieved through the following behaviors: 756 When bandwidth becomes insufficient, AO/DI attempts to augment the 757 bandwidth. Failure to augment bandwidth results in continuing with 758 a slower-than-desired throughput, but no damage. If the D-Channel 759 throughput becomes unacceptable, an attempt to add a B-Channel will 760 be made; this could be the result of delays in packet acknowledgment 761 or even packet rejection at the packet handler. 763 Given the discussions above regarding the use of SVCs and network 764 congestion, it is clear that some behaviors can be incorporated into 765 AO/DI to help overall robustness. One possiblel behavior is to put 766 a "bandwidth limiter" on the D-Channel that slows the transmission 767 of packets through the D-Channel when a threshold is exceeded over 768 some relatively short time interval. 770 Kudos: The author wishes to thank Joe Boucher for his contribution 771 on the D-Channel Idling, Scott Stamp for his contributions on X.25 772 translations, and Pierre-Luc Provencal for his contribution on the 773 BACP phone deltas and efforts to register an NLPID for X.25 specific 774 to AO/DI. 776 This work came from the Vendors ISDN Association members (especially 777 those on the AO/DI technical subcommittee) and thanks to the 778 National ISDN Council for their enthusiasm and persistence. 780 Special thanks for the wise council of the IETF PPPEXT working group 781 and especially Jonathan Goodchild. This document was created mostly 782 by Andy Kuzma in conjunction with the Vendors ISDN Association. 784 References 786 K. Sklower, B. Lloyd, G. McGregor, D. Carr, "The PPP Multilink 787 Protocol" RFC 1990 789 Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, 790 RFC 1661 792 K. Smith, "Ascend's Multilink Plus (MP+)," RFC 1934 794 I-D Always On Dynamic ISDN April 2001 796 C. Richards, K. Smith, "The PPP Bandwidth Allocation Protocol (BAP), 797 The PPP Bandwidth Allocation Control Protocol (BACP)" RFC 2125 799 A. Kuzma, et al, "AO/DI Network Architecture," Revision 2, Vendors 800 ISDN Association white paper, December 1996. 802 Simpson, W., Editor, "PPP in X.25," RFC 1598 804 ITU-T Q.922 - ISDN Data Link Layer Specification for Frame Mode 805 Bearer Services 807 ITU-T Q.931 - ISDN User-Network Interface Layer 3 Speicifcation for 808 Basic Call Control 810 ITU-T X.25 - Interface Between Data Terminal Equipment (DTE) and 811 Data Circuit-Terminating Equipment (DCE) for Terminals Operating in 812 the Packet Mode and Connected to Public Data Networks by Dedicated 813 Circuit 815 Author's Address 817 Matt Holdrege 818 ipVerse 819 223 Ximeno Ave. 820 Long Beach, CA 90803 USA 821 matt@ipverse.com