CURRENT_MEETING_REPORT_ Reported by Fred Baker/ACC and George Clapp/Ameritech Minutes of the joint session of IPLPDN and PPPEXT Working Groups RFC 1356 X.25 RFC 1356 will be recommended as a Draft Standard. There have been six to seven implementations with no interoperability problems. RFC 1294 has already been recommended for advancement to Draft Standard. Protocol Discrimination A PPP NLPID has been requested by the PPPEXT Working Group for use in NLPID-encapsulated protocols. The request has unfortunately gotten lost in the mail. Bill Simpson will resend the request to Lyman Chapin, who has agreed to make it happen. There is a separate issue with the ISDN Lower Layer Compatibility Information Element; George Clapp will pursue obtaining a value indicating PPP. o IP/Circuit Switched Service The question was seriously discussed whether we in fact need a default way to send IP over circuit switched services such as ISDN B channel. It was observed that the question is malformed; we do not need a default way to send IP over a V.35 or V.11 interface, for example. We need a way to speak to a peer system at the data link layer, which might be a Frame Relay or X.25 switch, or a peer host or router. We already have standards for PPP, Frame Relay, and X.25. In different contexts, we are willing to run any of the three standards. This approach is recommended for circuit switched services: - Systems must implement PPP, on the assumption that circuit switched communications are generally [host or router] to [host or router]. - Systems may implement other protocols such as Frame Relay or X.25 The implication here is not that all calls will be initiated with PPP signaling and encapsulation, but that PPP signaling and encapsulation will be a universally implemented option. 1 Multi-link Protocol The header will be changed to one of the following: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|P|0|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o M - More - 1 if a non-terminal fragment, 0 if the last fragment o P - Phase - has the same value on each fragment of a message, inverts from message to message o 0 - Reserved, must be zero o Sequence Number - 0 to 4095 fragment sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|L|0|0| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o F - First - 1 if first fragment in a message o L - Last - 1 if last fragment in a message o 0 - Reserved, must be zero o Sequence Number - 0 to 4095 fragment sequence number Including a link in the multi-link group is done by authenticating inclusion in the multi-link group and negotiation of the Fragmentation Protocol Control Protocol (FPCP). Removing a link from the multi-link group is done by terminating the FPCP on that link. In the worst case, receiver recovery from a sequence error (fragment loss) is done by sending an FPCP Configure Request in the OPEN state on all links; in most cases, one of the following two conditions is sufficient to detect and step past the loss of a sequenced fragment: 1. Receipt of a frame on each link with a successor to the omitted sequence number. 2. Expiration of an implementation-specific receipt timer; this should be long enough to handle the relevant timing issues. There is a separate LCP negotiation, authentication step, and set of Control Protocol negotiations for each link in a multi-link group. 2 Several other options were considered, including the use of the RFC 1294 fragmentation header, which was agreed to in the March meeting; RFC 1294 provides the same essential features as this but requires four octets, and additionally provides only compatibility with RFC 1294. PPP on Frame Relay We need to have an Applicability Statement for PPP over Frame Relay, in view of the existence of RFC 1294. The default encapsulation is as described in the minutes of the March IETF. Various edits were recommended, which will be included in an updated draft, including collapsing of Keith Sklower's parameter negotiation document (with attribution as author) into this document. LQM should not be used on a Frame Relay DLCI. PPP on X.25 We need to have an Applicability Statement for PPP over X.25 in view of RFCs 877 and 1356. Various edits were recommended, which will be included in an updated draft. Primary attention should be given to reducing the size of the X.25 frame. LQM should not be used in this environment. The PPP NLPID SHOULD be placed in the call user data rather than being carried in each frame. PPP/ISDN Bill Simpson presented his paper on PPP over ISDN. PPP must have the same default MRU (and any other defaults) on ISDN as in other environments. Keith Sklower will publish his IPLPDN document, ``Determination of Encapsulation of Multi-Protocol Datagrams in Circuit Switched Environment,'' and Bill indicates that he would like to copy some of the technical material from it into this document. It was decided that he would reference Keith's document. Parameter Negotiation Keith and Bill will merge their documents. This document should be separate from the PPP over foo documents, as it is desired to be placed on the standards track, and the PPP over foo documents may not be placed on that track. 3 Attendees George Abe abe@infonet.com Nick Alfano alfano@mpr.ca Bernt Allonen bal@tip.net Frederik Andersen fha@dde.dk Arun Arunkumar nak@3com.com Cynthia Bagwell cbagwell@gateway.mitre.org Fred Baker fbaker@acc.com Per Bilse bilse@ic.dk Carsten Bormann cabo@cs.tu-berlin.de Rich Bowen rkb@ralvm11.vnet.ibm.com Robert Braden braden@isi.edu Caralyn Brown cbrown@wellfleet.com Steve Buchko stevebu@newbridge.com Les Clyne l.clyne@jnt.ac.uk Thomas Cordetti tomc@digibd.com Geert Jan de Groot geertj@ica.philips.nl Marty Del Vecchio marty@shiva.com Bob Downs bdowns@combinet.com Ian Duncan id@cc.mcgill.ca Toerless Eckert Toerless.Eckert@informatik.uni-erlangen.de Kjeld Borch Egevang kbe@craycom.dk Ed Ellesson ellesson@vnet.ibm.com Shoji Fukutomi fuku@furukawa.co.jp Eugene Geer ewg@cc.bellcore.com David Ginsburg ginsb@us-es.sel.de Marcel Graf graf%dhdibm1.bitnet@vm.gmd.de Chris Gunner gunner@dsmail.lkg.dec.com Joel Halpern jmh@network.com Jari Hamalainen jah@rctre.nokia.com Patrick Hanel hanel@yoyodyne.trs.ntc.nokia.com Ken Hayward crm57d@bnr.ca Gerd Holzhauer Holzhauer1@applelink.apple.com John Hopkins J_Hopkins@icrf.icnet.uk Chris Howard chris_howard@inmarsat.org David Jacobson dnjake@vnet.ibm.com Philip Jones p.jones@jnt.ac.uk Frank Kastenholz kasten@ftp.com Rajeev Kochhar rajeev_kochhar@3com.com Dave Langley davel@hprnd.hp.com Eliot Lear lear@sgi.com Paolo Malara malara@crs4.it Andrew Malis malis_a@timeplex.com Shehzad Merchant merchant@erg.sri.com Gerry Meyer gerry@spider.co.uk William Miskovetz misko@cisco.com Keith Mitchell keith@pipex.net Daniel Myers dan@nsd.3com.com Drew Perkins ddp@fore.com David Piscitello dave@mail.bellcore.com Lars Poulsen lars@cmc.com Dave Rand dave_rand@novell.com 4 Juergen Rauschenbach jrau@dfn.de Tony Richards richards@icm1.icp.net Benny Rodrig brodrig@rnd-gate.rad.co.il Miguel Sanz miguel.sanz@rediris.es Henk Sennema sennema@sara.nl Keith Sklower sklower@cs.berkeley.edu Timon Sloane timon@timon.com Kenneth Smith kensmith@bnr.ca Henk Steenman henk@sara.nl Richard Sweatt rsweatt@synoptics.com Antoine Trannoy trannoy@crs4.it Hisao Uose uose@tnlab.ntt.jp Rene van der Hauw rene@geveke.nl Willem van der Scheun scheun@sara.nl Ruediger Volk rv@informatik.uni-dortmund.de Scott Wasson sgwasson@eng.xyplex.com Kirk Williams kirk@sbctri.sbc.com Rachel Willmer rachelw@spider.co.uk Sam Wilson sam.wilson@ed.ac.uk Paul Zawada Zawada@ncsa.uiuc.edu 5