Draft Multiprotocol ISDN Feb. 1993 INTERNET DRAFT Expires: August 16, 1993 The Transmission of Multi-protocol Datagrams over Circuit-mode ISDN Keith Sklower Computer Science Department University of California, Berkeley 1. Status of This Memo 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appro- priate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 2. Abstract This document describes means for transmitting Internet Pro- tocols across public data networks using circuit-mode ISDN. It describes compatible alternatives, discusses the relative merits of each and provides methods for discrimination between them. The intention is to capture in a slightly more formal way the level of consensus reached at the 24th and 25th IETF meetings. 3. Acknowledgements The author specifically wishes to thank Clifford Frost and William Jolitz for many extensive discussions on the sub- ject, and more generally the IP over Large Public Data Sklower [Page 1] Draft Multiprotocol ISDN Feb. 1993 Networks working group, whose deliberations this memo is supposed to reflect. Extensive references are made to ear- lier work by Leifer et al. [1], and Murakami et al. [2]. 4. Conventions The following language conventions are used in the items of specification in this document: o Must, Shall or Mandatory -- the item is an absolute requirement of the specification. o Should or Recommended -- the item should generally be followed for all but exceptional circumstances. o May or Optional -- the item is truly optional and may be followed or ignored according to the needs of the implementor. 5. Introduction The advent of Circuit-mode ISDN has provided the possibility of much higher rates of information exchange than previously possible over modems and voice-grade lines. We anticipate the use of this technology to encourage ``tele-commuting'' (making it more possible for people to work effectively at home), and to reduce the cost of data communications in businesses having geographically dispersed sites. Other applications, such as multi-media conferencing, are much more economically feasible than before. The contribution by Murakami also cites the use of ISDN to acquire additional bandwidth for handling excess traffic in parallel with leased lines, and more generally back-up of a failed leased line. Given the newness of the technology, the diversity of its applications, and its wide availability, it is not surpris- ing that a number of incompatible link level protocols are coming into use for the transmission of data over ISDN links. Examples are the use of SLIP [3] and PPP [4,5] over asynchronous terminal adapters using V.120 [6], PPP over synchronous terminal adapters using V.120 or directly over the B channel via native ISDN interfaces, and both the Mul- tiprotocol Encapsulation over X.25 [7], or Mutltiprocol Encapsulation over Frame Relay [8] directly on the B chan- nel. There are even other examples cited in Murakami's paper. In this paper we recommend a primary choice of encapsulation - -- that described in RFC 1294. We also suggest two accept- able alternatives for specific situations: PPP and X.25. Sklower [Page 2] Draft Multiprotocol ISDN Feb. 1993 The contribution by Murakami suggests using out-of-band sig- naling for negotiating the link-layer protocol and other configuration parameters using ISDN Information Elements such as UUI and BC. It is the experience of the members of the IPLPDN that ISDN implementation are as yet so diverse, the deployment of Switching System 7 so limited, and sub- scription policies by the regional providers so different, that user cannot depend on having these information elements passed end-to-end. The likeliest element to be passed end- to-end is LLC; this memo proposes a method for chosing the link-layer protocol based on this element when available. Where it is not available, an algorithm is proposed for ``negotiating'' the protocol by in-band exchange of data. Other configuration parameters can be negotiated in band using PPP, even for the Frame Relay and X.25 cases, as described in PNMI[9]. 6. Principal Recommendations 6.1. RFC 1294 6.1.1. Specific Encoding RFC 1294 specifies the transmission of datagrams in a format according to Q.922. As this is an HDLC framing, it is com- pletely suitable for use on an ISDN B channel. The RFC does not describe how the Q.922 header is generated; it was assumed that a genuine frame relay would provide it as a normal consequence of its operation. All other details of the encapsulation were completely specified by this RFC. In fact, it is possible to employ ISDN to gain access to a Frame Relay, and when doing so packets received from it will contain a valid DLCI. Obviously, a system communicating with a frame relay must set the DLCI's appropriately. When transmitting datagrams across an ISDN B-channel using this format between systems which are not Frame Relays, such systems MUST provide a valid DLCI header. As such, the low- est order bit of the first byte transmitted MUST be zero. The DLCI may be configured by prior agreement to any accept- able value. A default DLCI value of 16 is consistent with current ANSI recommendations (T1.617), however at some future time when frame relay service is offered over the D channel, the default DLCI value should be 512 (T1.618). 6.1.2. Advantages of Frame Relay Encapsulation Proponents for this method have claimed that RFC 1294 encap- sulation is very simple to implement; in fact it is possible to prepend a fixed header to all datagrams sent, and Sklower [Page 3] Draft Multiprotocol ISDN Feb. 1993 completely ignore the first few bytes of any datagram received. When systems have been compatibly preconfigured, no further state must be maintained on a per B-channel basis. This is clearly of concern for circumstances like multiple primary rate interfaces coming into a single router, thus poten- tially supporting hundreds of B-Channels. Furthermore, it is possible to start transmitting data as soon as the circuit has been established, thereby reducing latency. PPP and X.25, by contrast require an exchange of packets to declare the link up. 6.2. PPP The proponents for PPP argue that it is widely implemented, and constructed in such a way to force interoperability. The details of the protocol are completely specified by RFC's 1331 and 1332, and are also applicable to any situa- tion where synchronous transmission of data is possible. They argue that any commercial router one procures is likely already to have code supporting PPP, and it is flexible enough to adapt to all the situations cited as applications in this memo. 6.3. RFC 1356/B-Channel X.25 Systems supporting exchanging information according to OSI conventions are required to support X.25 over the B-channel, and RFC 1356 provides means for conveying Internet Protocols in this situation. 7. In-Band Link Protocol Negotiation The algorithm is that the caller starts transmitting data or negotiation according to his preferred encapsulation, and the callee just figures out what is desired by inspection of the first correctly framed HDLC packet. If either the caller or callee insists on doing PPP or X.25 it will be impossible to shut them up. 7.1. Caller's Algorithm A system wishing to exchange information using RFC-1294 encapsulation MUST transmit some packet with a valid two- byte DLCI. The calling system MAY transmit protocol data immediately, given suitable preconfiguration. The calling system MAY also initiate parameter negotiation according to PNMI, using the RFC-1294 encapsulation. A system wishing to exchange information using PPP will issue an LCP packet in native PPP format, according to the Sklower [Page 4] Draft Multiprotocol ISDN Feb. 1993 requirements of RFC 1331; i.e. the first byte will be 0xff, and the second byte will be 0x3, etc. A system wishing to use X.25 will issue a SABM with an address of station A, according to the OSI implementors agreement [10]. 7.2. Callee's Algorithm The called system will wait until it has received a cor- rectly framed and checksummed HDLC packet and inspect the very first byte. PPP requires that the station address be all ones (0xff). Conventional X.25 HDLC requires a station address of either 1 or 3. The 2,3 or 4 byte DLCI Q.922 for- mats all require that the low order bit of the first byte to be zero. Thus, it is possible for a called system support- ing all three methods to unambiguously determine which encapsulation is desired and respond in the appropriate man- ner. 8. Out of Band Signaling {Warning - Meta paragraph. At the last IETF meeting, it was agreed that somebody would approach ANSI for obtaining a code point for the LLC-IE byte 7 "user information layer 3 protocol" that would indicate PPP. I probably have botched this section but I'm going to include it to make it easier for whoever edits this next}. 8.1. Caller's Requirements In cases where the LLC information element is available and can be transmitted to be relied on end to end, and the sys- tem wishes to communicate using the RFC-1294 encapsulation, a system MUST encode the LLC-IE in the following way in his setup message: Sklower [Page 5] Draft Multiprotocol ISDN Feb. 1993 8 7 6 5 4 3 2 1 - ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 - ----------------------------------------------------------- . . . - ----------------------------------------------------------- 1 1 0 0 1 1 1 1 Octet 6 ext layer 2 ident Core Aspects of Q.922 (Frame Relay) - -or- 1 1 0 0 1 1 1 0 Octet 6 ext layer 2 ident Full Q.922 (LAPF) - ----------------------------------------------------------- 1 1 1 0 1 0 1 1 Octet 7 ext layer 3 ident ISO/IEC TR 9577 (Protocol Identifi- cation in the Network Layer) - ----------------------------------------------------------- In cases where the system wishes to exchange information using RFC-1356/X.25 PLP/LAPB a system MUST encode the LLC-IE in the following way in his setup message: 8 7 6 5 4 3 2 1 - ----------------------------------------------------------- 0 1 1 1 1 1 0 0 0 Low Layer Compatibility Octet 1 - ----------------------------------------------------------- . . . - ----------------------------------------------------------- 1 1 1 0 0 1 1 0 Octet 6 ext layer 2 ident CCITT Recommendation X.25 link level - ----------------------------------------------------------- 1 1 1 0 0 1 1 0 Octet 7 ext layer 3 ident CCITT Recommendation X.25 packet level - ----------------------------------------------------------- 8.2. Callee's Algorithm If the LLC-IE exactly matches that generated by the caller's algorithm, the system SHOULD proceed according to the encap- sulations spelled out here. The callee MAY inspect the first correctly framed HDLC packet to see that it matches the encapsulation scheme described. If the LLC-IE contains other values, the system SHOULD pro- ceed according to the ``wait-and-see'' algorithm described Sklower [Page 6] Draft Multiprotocol ISDN Feb. 1993 above. However, system MAY refuse the connection, or the system MAY make the following inferences: If the User infor- mation layer 3 protocol is 0 1 0 0 0 (ISO 8348 Connection oriented network service), the system MAY assume that RFC-1356/X.25 operation is requested. If the User informa- tion layer 3 protocol is 0 1 0 0 1 the system MAY assume that only ISO 8473 packets will be routed, (just as if an X.25 call had been placed with a CUD of 81). A system MAY also assume that octet 7 with a value of 0 1 1 1 0 indicates a desire to encapsulate according to RFC-1294. 9. Addressing Stated Requirements of Earlier Work 9.1. Leifer et al A goal of this proposal was to be able to use bandwidth on demand, and obtain the advantage of using multiple B chan- nels for transmitting traffic between two hosts. There are a number of possible ways of doing this which will be discussed at length in a separate draft. For purposes of illustration, we will summarize the methods discussed at the November, 1992 IETF: Almost all the methods require some means of identifying which channels are to be aggregated, which could be done by the methods discussed in PNMI, or potentially by use of the calling party information element. (1) Use the bank-teller's algorithm: assign a complete packet to whatever channel is next free. (2) Employ ISO 7776[11] multilink procedure. (This is being pursued by the PPP working group). (3) Adapt the fragmentation and reassembly scheme for RFC-1294 for bridged packets, regarding the fragment identifier as applying to all packets from a given peer rather than from a given PVC. (4) Rely on hardware and packet switching facilities that combine multiple B-channels into a single (HDLC) bit stream, such as the BONDING proposal currently being discussed by ANSI T1. 9.2. Murakami et al A major concern of this paper was the use of out-of-band signaling to negotiate compatible configuration parameters. It is the contention of this author that any parameter need- ing to be negotiated in this scheme should be able to be done so by PNMI, and if it can't then PPP should be extended to negotiate that parameter. Sklower [Page 7] Draft Multiprotocol ISDN Feb. 1993 10. References [1] Leifer, D., Sheldon, S., and Gorsline B., "A Subnetwork Control Protocol for ISDN Circuit-Switching" IPLPDN Working Group, Internet Draft (Expired), March 1991. [2] Muramaki, K., and Sugawara, T., "A Negotiation Protocol for Mutliple Link-Protocol over ISDN Circuit Switch- ing", IPLPDN Working Group, Committee Document, May 1992. [3] Romkey, J.L., "A Nonstandard for Transmission of IP Datagrams over Serial Lines: SLIP." Network Working Group, RFC-1055, June 1988. [4] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", Network Working Group, RFC-1331, May 1992. [5] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [6] CCITT, "Recommendation V.120: Data Communications over the Telephone Network" Blue Book, ITU 1988 [7] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", Net- work Working Group, RFC-1356, August 1992. [8] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1294, January 1992. [9] Sklower, K. and Frost, C. "Parameter Negotiation for the Multiprotocol Interconnect" IPLPDN Working Group, Committee Document, November 1992. [10] Boland, F., editor, "Stable Implementation Agreements for Open Systems Interconnection Protocols: Version 2 Edition 1", NIST Workshop for Implementors of OSI, NIST, February 1989. [11] Internation Organisation for Standardization, "HDLC - Description of the X.25 LAPB-Compatible DTE Data Link Procedures", Internation Standard 7776, 1988 11. Author's Address Keith Sklower Computer Science Department 570 Evans Hall University of California Sklower [Page 8] Draft Multiprotocol ISDN Feb. 1993 Berkeley, CA 94720 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU 12. Expiration Date of this Draft August 16, 1993 Sklower [Page 9] ------- End of Forwarded Message