Draft Parameter Negotiation July 1993 INTERNET DRAFT Expires: January 7, 1994 Parameter Negotiation for the Multiprotocol Interconnect Keith Sklower Computer Science Department University of California, Berkeley Clifford Frost Information Systems & Technology University of California, Berkeley 1. Status of This Memo This document is an Internet Draft. Internet Drafts are working documents of the Inter- net Engineering Task Force (IETF), its Areas, and its Work- ing 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 mechanisms for negotiating opera- tional parameters wherever SNAP encapsulation of Internet Protocols is available. For example, it is suitable for use in conjunction with RFC 1294 (Multiprotocol Over Frame Relay) and RFC 1356 (Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode) [1,2], and potentially others. The mechanisms described here are intended as optional exten- sions, intended to facilitate interoperation in public net- works were preconfiguration may not have been done symmetri- cally by all parties who wish to exchange information. Sklower & Frost [Page 1] Draft Parameter Negotiation July 1993 3. Acknowledgements The authors wish to thank Brian Lloyd of Lloyd & Associates and Bill Simpson of Daydreamer, Inc. for extensive discus- sion of the PPP protocol, Brad Steinke of Microcom, and Joel Halpern of Network Systems for useful suggestions, and espe- cially Chris Ranch of Novell for details about the protocol itself. 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 When parties wish to exchange information over a public data network, it may be useful to perform sanity checks, such as verifying that buffer sizes are sufficient to receive data being transmitted, or that there is agreement as to which protocols will be routed or bridged. As another example, there may be circumstance in which the identity of a calling party may not be readily available; thus some form of authentication may be desired. The Point-to-Point Protocol (RFC 1331 and 1332) provides a means of achieving these goals [3,4]. It is very general and can be adapted to any situation where there is a virtual point-to-point connection between parties wishing to exchange information. Both RFC's 1294 and 1331 specify details of framing and encapsulation in incompatible ways; however, one can accommodate PPP's encapsulation of control packets by prepending a SNAP header without otherwise chang- ing the description of the packets. Alternatively, should ISO or CCITT be persuaded to grant an NLPID (identifier for use in ISO TR 9577[6]), the PPP pack- ets and encapsulations could co-exist as an extension to RFC's 1294 and 1356. Members of the IPLPDN group expressed the desire that param- eter negotiation as a whole be made optional, and also wanted to be able to renegotiate parameters at any time Sklower & Frost [Page 2] Draft Parameter Negotiation July 1993 during the course of an association. Both of these goals can be met without violating the current PPP spec. 6. Frame Format 6.1. Basic Format In this document, we propose prepending a SNAP header to otherwise unchanged PPP (data and control) packets [5]. The SNAP header MUST specify an OUI of 0 (Xerox Ethernet Encap- sulation). The protocol ID field MUST be 0x0B03. A system SHOULD recognize incoming PPP data packets. We RECOMMEND that only control or negotiation type PPP packets be trans- mitted in this fashion, since RFCs 1294 and 1356 already specify a means of encapsulating data packets. Since we are proposing using this in conjunction with both RFC1294 and RFC1356, we give an example in each packet for- mat: Sample Frame Relay PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Q.922 Address | +-- --+ | | +-----------------------------+ | Control (UI = 0x03) | +-----------------------------+ | Optional Pad(s) (0x00) | +-----------------------------+ | NLPID 0x80 | +-----------------------------+ | OUI 0x00 | +-- . --+ | OUI 0x00 | +-- . --+ | OUI 0x00 | | (three octets) | +-----------------------------+ | ETHERTYPE 0x0B | +-- . --+ | ETHERTYPE 0x03 | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ | Data | Sklower & Frost [Page 3] Draft Parameter Negotiation July 1993 | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ Sample X.25 PPP LCP packet +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ | Address A or B 0x1 or 0x3 | +-- --+ | LAPB Control | +-----------------------------+ | D,Q bits | SVC# high order | +-----------------------------+ | SVC low order | +-----------------------------+ | p(r) | m_bit | p(s) | 0 | +-----------------------------+ | NLPID 0x80 | +-----------------------------+ | OUI 0x00 | +-- . --+ | OUI 0x00 | +-- . --+ | OUI 0x00 | | (three octets) | +-----------------------------+ | ETHERTYPE 0x0B | +-- . --+ | ETHERTYPE 0x03 | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| Sklower & Frost [Page 4] Draft Parameter Negotiation July 1993 | (two octets) | +-----------------------------+ | Data | | (e.g LCP Code ) | +-----------------------------+ | (e.g LCP Identifier) | +-----------------------------+ | (e.g. LCP Option Length)| +-- . --+ | (two octets) | +-----------------------------+ | (e.g. LCP Option) | | . | | . | | . | | . | +-----------------------------+ | Frame Check Sequence | +-- . --+ | (two octets) | +-----------------------------+ | flag (7E hexadecimal) | +-----------------------------+ Since one of the packet formats specified in RFC1356 permits logically prepending the call user data supplied when the virtual circuit was established to each packet transmitted over that virtual circuit, one could transmit PPP packet unchanged if the 6 byte snap header is supplied as the call user data. Equivalently, if a NLPID for PPP is obtained, then the single byte NLPID is all that is required as CUD. 6.2. Supported Types The PPP protocol is a rich language and allows many options to be negotiated. An implementation MAY request any option specified by PPP, but MAY decline to support any option. Because PPP and Frame Relay encapsulations evolved indepen- dently, there are duplicate ways to obtain configuration information such as the IP address of the other end of the PVC - by inverse arp, or determine the transmit and receive buffer sizes - by XID negotiation. Where there are such choices, it is RECOMMENDED that an implementation adhere to practice specified in the Frame Relay and X.25 RFCs. Manual configuration also implicitly provides information that may otherwise have been explicitly negotiated. 7. Changes to PPP semantics 7.1. Optionality and Separability of Negotiations As noted above, people have expressed the desire not to be required to conduct any negotiations before transmitting Sklower & Frost [Page 5] Draft Parameter Negotiation July 1993 data packets in a public data network environment. Thus, an implementation MAY silently ignore any SNAP encapsulated PPP packet. If an implementation responds to LCP packets, it MUST traverse the LCP state diagram according to RFC1331. If an implementation responds to NCP packets for any partic- ular protocol, it MUST otherwise obey the rules of the RFC for that corresponding NCP. One reason for making negotiations optional is cost; there are environments which charge by the packet and there are applications such as mail hubs which generally exchange only a few data packets with a given remote host and then will not exchange any other packets for relatively long periods of time. Another reason is simplicity of implementation. For use of small computers at home, people may wish to be able to only support the required packet framing. Or, for routers at campus or business hubs, this could reduce memory require- ments from having to maintain state information for hundreds of virtual point-to-point connections. Another reason is reduction of latency. 8. References [1] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", Network Working Group, RFC-1294, January 1992. [2] 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. [3] 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. [4] McGregor, G., "The PPP Internet Protocol Control Proto- col (IPCP)" Network Working Group, RFC-1332, May 1992. [5] Postel, J. and Reynolds, J., "A Standard for the Trans- mission of IP Datagrams over IEEE 802 Networks", ISI, RFC-1042, February 1988. [6] International Organization for Standardization, "Infor- mation technology - Telecommunications and Informations exchange between systems - Protocol identification in the network layer", Technical Report 9577, October 1990. Sklower & Frost [Page 6] Draft Parameter Negotiation July 1993 9. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 E-mail: sklower@cs.Berkeley.EDU Clifford Frost Information Systems & Technology 275 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-5360 E-mail: cliff@cmsa.Berkeley.EDU 10. Expiration Date of this Draft January 7, 1994 Sklower & Frost [Page 7]