CURRENT_MEETING_REPORT_ Reported by George Clapp/Ameritech IPLPDN Minutes Opening Remarks This was the second meeting of the IP over Large Public Data Networks Working Group and the following was the Agenda of the meeting: o Wednesday, March 13, 1991 - Tutorial on Frame Relay (FR) by Andy Malis - Discussion of encapsulation and protocol multiplexing over FR - Tutorial on ISDN (Wayne Heinmiller and Jim Loehndorf) - Discussion of encapsulation and protocol multiplexing over ISDN o Thursday, March 14, 1991 - Joint meeting with the BGP Working Group to discuss the use of BGP for routing and address resolution (Paul Tsuchiya) - Continued discussion of encapsulation and protocol multiplexing Frame Relay Tutorial Due to airplane troubles, Andy Malis had been unable to present his tutorial on Frame Relay during the plenary the previous evening, so he kindly presented his talk during the first half of Wednesday morning's Working Group session. (Andy also presented this tutorial during the Friday morning plenary, and a copy of his presentation is included in the Proceedings for that session. A postscript version is online for anonymous ftp at ``pub/ietf-frame-relay-intro.ps'' on ccv1.bbn.com) The presentation was an excellent preparation for the discussion of encapsulation and protocol multiplexing. Encapsulation and Protocol Multiplexing for Frame Relay After the tutorial Caralyn Brown presented the following encapsulation and protocol multiplexing scheme for Frame Relay. The proposal is documented in the draft ``Multiprotocol Interconnect over Frame Relay Networks'', which is available online on ccv1.bbn.com for anonymous ftp as ``pub/multiprotocol.txt''. (A copy of the viewgraphs of Caralyn's presentation accompanies these minutes.) 1 +--------------------+ | LAPD flag (0x7E) | +--------------------+ | DLCI | +--------------------+ | DLCI... | +--------------------+ | Format Identifier | +--------------------+ |FCSP| Origin_Media | +--------------------+ | ... | +--------------------+ | Info | +--------------------+ | ... | +--------------------+ | Frame Ck Sequence | +--------------------+ | Frame Ck Sequence | +--------------------+ | LAPD flag (0x7E) | +--------------------+ FCSP: Frame Check Sequence Preservation The Format Identifier indicates whether 802.2 and SNAP or a bridged MAC frame follows, and the Origin_Media indicates the type of the bridged MAC frame. If a routed packet is being carried, then the Origin_Media value is set to zero and the 802.2 LLC Type 1 and SNAP headers follow. The Ethertype of the SNAP header is used to indicate the type of the routed packet. This proposal was modified by Charles Carvalho, who proposed that the 802.2/SNAP headers be eliminated by carrying both the bridged MAC frame type and the Ethertype values within a combined Format Identifier/Origin_Media field. There was qualified acceptance of this approach before the group broke for lunch. ISDN Tutorial and Proposal Wayne Heinmiller with Jim Loehndorf presented an overview tutorial on ISDN (a copy of the presentation accompanies these minutes). The presentation led into a talk by Dory Leifer of proposed encapsulation, protocol multiplexing, and fragmentation schemes for circuit and LAPD ISDN. The proposal is documented in the draft ``A Subnetwork Control Protocol for ISDN Circuit-Switching'', which is available online on terminator.cc.umich.edu as `` ftp/isdn'' for anonymous ftp. Further discussion was deferred until the next morning. 2 Joint Meeting with BGP Working Group Paul Tsuchiya led a joint meeting of the IPLPDN and BGP Working Groups. (A copy of his slides accompany the minutes.) Paul proposed alternative mechanisms to support a simple and effective way for routers to obtain routing and address resolution information from BGP servers. He also proposed an extension to BGP in which both the next hop IP address and the hardware, or SubNetwork Point of Attachment (SNPA), address would be given to the requesting router. Members of the BGP group were concerned with potential conflicts between policies of the Autonomous Systems that might be traversed by a packet. This discussion remained unresolved and Paul volunteered to work towards a solution in time for the next meeting. Encapsulation and Protocol Multiplexing After the break, IPLPDN met separately from the BGP Working Group and Caralyn Brown presented the modified proposal for encapsulation and protocol multiplexing over Frame Relay. (A copy of the viewgraph of the proposal accompanies the minutes.) +--------------------+ | LAPD flag (0x7E) | +--------------------+ | DLCI | +--------------------+ | DLCI... | +--------------------+ | Format ID 1 | +--------------------+ | Format ID 2 | +--------------------+ | ... | +--------------------+ | Info | +--------------------+ | ... | +--------------------+ | Frame Ck Sequence | +--------------------+ | Frame Ck Sequence | +--------------------+ | LAPD flag (0x7E) | +--------------------+ 3 If the value of the Format Identifier is less than 1024 decimal (0x0400) then the field is used to encode the MAC type and the code points are identical to those in internet-draft ``Point to Point Protocol Extensions for Bridging''. This is shown below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 0 | F | Z | MAC TYPE | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ The F bit is used to indicate the presence of the MAC Frame Check Sequence, and the Z bit is used to indicate zero compression. If the value of the Format Identifier is 1024 decimal (0x0400) then the 802.2 LLC header follows the Format Identifier field, as shown below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | DSAP | SSAP | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Control | +---+---+---+---+---+---+---+---+ If the value of the Format Identifier is greater than 1024 decimal (0x0400) then the encoded Format Identifier is equivalent to the Digital-Intel-Xerox (DIX) Ethertype, as shown below. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Digital-Intel-Xerox (DIX) Ethertype | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Caralyn continued with a discusion of mechanisms for address resolution and proposed that ARP be used to discover the DLCI associated with an IP 4 address. She also proposed an extension to ARP named Inverse ARP to discover the IP address associated with a DLCI. This latter proposal is documented in the draft ``Inverse Address Resolution Protocol'', which is available online by anonymous ftp on ccv1.bbn.com as ``pub/inarp.txt''. After some discussion and modifications, all of these proposals appeared to be acceptable to the group. IP over ISDN Dory Leifer continued with a discussion of the following issues: o Fragmentation - do we need it considering the access network may impose small max frames? Resolution: further study o End-to-end link state for switched access, i.e., XID frames? Resolution: no o ACK mode support or at least include CONTROL field for Q.921 compatibility? Resolution: the group accepted the CONTROL field with a pad in the encapsulation scheme. The revised scheme is shown below. +-----------+ | flag | +-----------+-----------+ | DLCI | DLCI.. | +-----------+-----------+ | Control | PAD | +-----------+-----------+ | Format ID | Format ID | +-----------+-----------+ | info.. | ... | +-----------+-----------+ | ... | ... | +-----------+-----------+ | CRC | CRC | +-----------+-----------+ | flag | +-----------+ o Discovery protocol of Max frame size? No resolution 5 o Code point for in-connection management protocol? No resolution At this point, time ran out and the group adjourned until the next meeting in Atlanta, GA, in July 1991. Attendees Karl Auerbach karl@eng.sun.com William Babson bill%penril@uunet.UU.NET Fred Baker fbaker@emerald.acc.com Atul Bansal bansal@netrix.nac.dec.com Ron Bhanukitsiri rbhank@wsl.dec.com Caralyn Brown cbrown@wellfleet.com Howard Brown brown@ctron.com Theodore Brunner tob@thumper.bellcore.com Lida Carrier lida@apple.com Eric Carroll eric@utcs.utoronto.ca Charles Carvalho charles@sage.acc.com Martina Chan mchan@mot.com Cho Chang chang_c@apollo.hp.com George Clapp clapp@uunet.uu.net Graham Cobb cobb@marvin.enet.dec.com Richard Colella colella@osi3.ncsl.nist.gov Nabil Damouny Tom Easterday tom@cic.net Gus Elmer arch1!ae@att.com Dennis Ferguson dennis@canet.ca Peter Ford peter@lanl.gov Daniel Friedman danfriedman@bbn.com Charles Gallucci Dave Geurs dgeurs@mot.com Bret Gorsline jinx@engin.umich.edu Martin Gray mg@spider.co.uk Olafur Gudmundsson ogud@cs.umd.edu Frank Heath Kathleen Huber khuber@bbn.com B.V. Jagadeesh bvj@esd.3com.com Dan Jordt danj@nwnet.net Ajay Kachrani kachrani@regent.enet.dec.com Manu Kaycee kaycee@trlian.enet.dec.com Nam Keung Peter Kirstein kirstein@cs.ucl.ac.uk Mary Louise Laier laierl@applelink.apple.com Michelle Landriault crm57a@bnr.ca Joseph Lawrence jcl@sabre.bellcore.com Dory Leifer Dory.Leifer@terminator.cc.umich.edu Richard Libby libby@c10sd6.stpaul.ncr.com Mike Little little@ctt.bellcore.com Then Liu 6 John LoVerso loverso@westford.ccur.com Andrew Malis malis@bbn.com Glenn McGregor ghm@merit.edu Robert Meierhofer bobm@cl0sd6.stpaul.ncr.com Linda Melvin infopath@well.sf.ca.us Agnes Moran Robert Peglar robp@anubis.network.com James Philippou japhilippou@eng.xyplex.com Rehmi Post rehmi@ftp.com Stephanie Price price@cmc.com Ron Roberts roberts@jessica.stanford.edu Manoel Rodrigues manoel.rodrigues@att.com Allyn Romanow allyn@eng.sun.com Allan Rubens acr@merit.edu Ray Samora rvs@proteon.com Paul Selkirk paul@ftp.com Marc Sheldon ms@Germany.eu.net Daisy Shen daisy@watson.ibm.com Stephen Shew sdshew@bnr.ca William Townsend townsend@xylogics.com Paul Tsuchiya tsuchiya@bellcore.com Robert Ullmann ariel@relay.prime.com Kannan Varadhan kannan@oar.net Francis Waldman Wing Fai Wong wfwong@malta.sbi.com Chin Yuan cxyuan@pacbell.com 7