Draft Parameter Negotiation Feb. 1992 INTERNET DRAFT Expires: August 16, 1993 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 Feb. 1992 3. Acknowledgements The authors wish to thank Brian Lloyd of Lloyd & Associates for extensive discussion of the PPP protocol, Brad Steinke of Microcom, and Joel Halpern of Network Systems for useful suggestions, and especially 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. Since both RFC's 1294 and 1331 spec- ify details of framing and encapsulation in incompatible ways, there is a minor modification to PPP's encapsulation which is required for this context. There are some additional changes that have been proposed to the PPP-extensions working group for use in this context. Principally, we would like parameter negotiation as a whole to be made optional. We would also like to be able to rene- gotiate parameters at any time during the course of an asso- ciation. There was also expressed the desire to decrease the number of actual packets exchanged to traverse PPP's state diagram. A method for doing this was proposed by emiting compound frames which would be made up of multiple logical PPP packets. It was thought that this might reduce Sklower & Frost [Page 2] Draft Parameter Negotiation Feb. 1992 the negotation to an exchange of three actual link-level packets. 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 (0xZZZZ - to be obtained). A system SHOULD recognize incoming PPP data packets; however, we RECOMMEND that only control or negotia- tion type PPP packets be transmitted 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 (to be .. | +-- . --+ | ETHERTYPE obtained) | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ | PPP Protocol (0x21 for LCP)| | (two octets) | +-----------------------------+ Sklower & Frost [Page 3] Draft Parameter Negotiation Feb. 1992 | 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) | +-----------------------------+ 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 (to be .. | +-- . --+ | ETHERTYPE obtained) | | (two octets) | +-----------------------------+ | PPP Protocol (e.g. 0x0c) | +-- . --+ Sklower & Frost [Page 4] Draft Parameter Negotiation Feb. 1992 | PPP Protocol (0x21 for LCP)| | (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) | +-----------------------------+ 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 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 Sklower & Frost [Page 5] Draft Parameter Negotiation Feb. 1992 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. Other Extensions to PPP 8.1. Protocol Summaries in NCP It has been suggested that there should be a PPP LCP option to pre-emptively announce which protocols will be routed or bridged, in lieu of conducting independent negotiations for each protocol via their separate NCPs, The rationale for having this option is that it gives what may be for simple situations the single most important benefit of having an NCP at all (i.e. a sanity check that data packets will not be black holed) without having the complexity or latency requirements of a full blown NCP. 8.2. Compound PPP packets If it is desired to conduct several independent NCPs at the same time, and since there are per-packet charges, it may be useful to bundle up several logical PPP packets into the same physical packet and thus reduce packet charges. The PPP-extensions working group has agreed to advance this change, and it will be described in a forthcoming document. 9. 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- Sklower & Frost [Page 6] Draft Parameter Negotiation Feb. 1992 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. 10. Authors' Addresses Keith Sklower Computer Science Department 570 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-9587 Email: sklower@cs.Berkeley.EDU Clifford Frost Information Systems & Technology 275 Evans Hall University of California Berkeley, CA 94720 Phone: (510) 642-5360 Email: cliff@cmsa.Berkeley.EDU 11. Expiration Date of this Draft August 16, 1993 Sklower & Frost [Page 7]