Data Link Switching BOF (DLSW) Reported by Louise Herndon Wells Call to Order The meeting was called to order by Shannon Nix. Shannon is vice-chair of the Data Link Switching (DLSw) Related Interest Group (RIG) of the APPN Implementer's Workshop (AIW) and is the proposed co-chair of the proposed DLSw Working Group. There were about 30 attendees, including Stev Knowles and Claudio Topolcic, Internet Area co-Directors. Shannon introduced Louise Herndon Wells, chair of the AIW DLSw RIG and proposed co-chair for the DLSw Working Group. History/Background IBM posted Informational RFC 1434 in the second quarter of 1993, which described the Data Link Switching functionality of its 6611 multiprotocol router. DLSw was a technique, with elements of both routing and bridging, to support traditional SNA, APPN, and NetBIOS traffic over TCP/IP. Several vendors then approached IBM to discuss working together to enhance DLSw with the goal of it becoming an industry standard. Since that time, these vendors have met four times under the auspices of the APPN Implementer's Workshop (AIW). The group's AIW designation, initially a Special Interest Group (SIG), was changed to Related Interest Group (RIG) to reflect its topic protocol not being one that directly feeds into APPN. At the last AIW DLSw meeting in February 1994, the DLSw RIG decided to explore the advantages and disadvantages to vendors and users of presenting its work to the IETF as a working draft toward an IETF DLSw standard. The first step in this exploration is this IETF Birds-of-a-Feather (BOF) meeting. Technical Overview Shannon Nix gave a top-level description of DLSw. Requests to be added to the DLSw mailing list can be sent to: aiw-dlsw-request@ibmstandards.cary.ibm.com The group as a whole and each of its working groups has its own mailing list, the postmaster of which is IBM's APPN Implementer's Workshop (AIW). Information is available via anonymous FTP on ibmstandards.cary.ibm.com, including all mail archives. There were then presentations on five of the seven DLSw technnical working groups (called RIGlets): o Capabilities - protocol for negotiating capabilities prior to connection. o Connect - Finite state machines (FSMs) in RFC 1434 were not complete enough for multiple data link types. o Flow control - On circuit-level basis, way to enforce back pressure across DLSw cloud. o Loop prevention - For Ethernet, to avoid loops, since DLSw cloud looks like a large token ring. o DLSw network management - SNMP MIB development and support within IBM network management. o Priority/Class of Service (COS) - Support requested SNA priorities and COS across TCP/IP. (Not discussed here.) o Conformance - Testing for specification conformance and, perhaps, for interoperability. (Not discussed here.) DLSw Top-level Overview Shannon Nix described how a data link switch terminates the LAN logical link control (LLC) connection and communicates with one or more other data link switches across TCP/IP over TCP/IP sessions. They discover the resources supported by other data link switches by broadcasting a CANUREACH, to which the responsible device replies with an ICANREACH. --- --- ------ ------ ------ --- ----- |end|--(Tkn)--|DLSw|--(TCP/IP)--|DLSw|--(SDLC)--|end| |sys| (Ring) ------ (network) ------ (link) |sys| --- ---- ------- ----- <--------------> <---------------> LLC connection LLC connection <----------------> TCP/IP session Capabilities Wayne Clark, coordinator of the AIW DLSw Capabilities RIGlet, described the group's work. The RIGlet has divided the DLSw capabilities support into a base set and an option set. The base includes 1434 plus added capabilities exchange features plus base MIB plus flow control minus NetBIOS (which is now optional). The option set includes NetBIOS, Loop Prevention, Priority/COS, Advanced Flow Control, and MAC Address list (at CANUREACH time). Capabilities Exchange Control Vectors include: o 5 bytes for organization-unique identifier (OUI) (vendor ID) (X'81') o n bytes for version string (X'82') o 3 bytes for NetBIOS support (X'83') o 3 bytes for Loop Prevention (X'84') o 4 bytes for Flow Control Support (X'85') o 4 bytes for Initial Pacing Window (IPW) (X'86') o 8 bytes for MAC address masks (X'87') o 8 bytes for MAC address value (X'88') o Sets of n bytes for MAC address lists (X'89') For TCP/IP session establishment, a data link switch always listens on port number 2065 and calls out on port 2067 to the other's port 2065. Ordinarily, a data link switch accepts all calls to port 2065. However, there is a paranoid option for a switch to drop a call if the partner is not on its prespecified list. Loop Prevention Wayne Clark gave a presentation on loop prevention in place of this RIGlet's coordinator Choon Lee who was unable to attend. o Problem: A parallel path may exist in a data link switch network, which presents a problem for SNA Test frames and NetBIOS Name Queries. o Focus of previous proposal: In a modified test frame, carry the virtual ring number. o Problem with proposal: Adds states to FSM and delay for every circuit establishment. Another possible proposal would be to carry the routing information field (RIF) end-to-end, i.e., not terminating the connection. RIGlet is still working on the topic. Connect Peter Gayek presented on behalf of Steve Klein, coordinator of this RIGlet, who was unable to attend. Items where consensus has been reached: o Scope = SNA and NetBIOS switch-to-switch protocol (SSP) flows to support 802.2 and SDLC. (QLLC and others may be added later.) Information encapsulated across TCP/IP, except LLC connection is terminated so no header is carried across TCP/IP. Not as much in RFC 1434 on switch-to-switch communication as on end-station-to-switch communication. o Separation of topology establishment from circuit establishment. When origin router gets Test frame, it triggers data link switch to send CANUREACH (based on destination MAC/SAP address). CANUREACH does two things: 1) it discovers which switch supports that destination, and 2) gets control blocks to set up circuit. There is a problem with doing search and set-up at once. Solution: ``CANUREACH explorer'' used just to find other data link switches. o Current FSMs are generally on the right track. Additional information and examples are being added. Open issues: o Resolving circuit establishment collision. Race condition: two proposals on the table from Bernie Brady (BBN) and Steve Klein (IBM) for contention resolution. o Handling SDLC devices. Most of 1434 was written in LAN terminology. Need example flows to show how SDLC is handled. Proposal regarding CANUREACH (CUR) and ICANREACH (ICR) carrying DLC header and frame data. CUR/ICR circuit set-up (CUR_cs/ICR_cs) may or may not be needed after CUR/ICR explorer (CUR_ex/ICR_ex) is sent. o FSM enhancements. Make normative (descriptive - there are too few footnotes). Add non-activation XID support. Add process to handle ``loss of TCP connection.'' Network Management Peter Gayek (IBM) presented information on the network management RIGlet in place of Gene Cox, coordinator of this AIW RIGlet, who was unable to attend. Stev Knowles noted that, in the IETF, a MIB is published under a separate RFC. Items where consensus has been reached: o RIGlet scope includes SNMP and SNA Management Services (SNA/MS) management of DLSw. Most discussion to date has been on SNMP. o DLSw conformance requires implementing a base DLSw MIB. o Base MIB to contain RIG algorithm-related and common implementation variables. o Base MIB will reference, but not duplicate, information in the SDLC and 802.2 MIBs. o Base MIB may contain SETs and administrative variables. Open issues: o Specification of DLSw MIB contents. o Publication vehicle for the DLSw MIB. o Whether to define DLSw-specific traps. o Whether to define SNA/MS alerts or NetView RUNCMDs. Stev Knowles noted that, in the IETF, people have been turning off to traps. Flow Control Shannon Nix presented information on work to date in the AIW DLSw flow control RIGlet, of which he is coordinator. A protocol mechanism is needed to allow the implementation to exert flow control on a per-circuit basis. The group is not discussing why a receiver would use pacing but rather how it would do it, if it wants to do it. Items on which consensus has been reached: o Adaptive pacing window. Independent pipes in each direction. o Receiver control - Receiver allows permission to sender to send a certain number of SSP messages. o Initial window size is negotiated. o Reset window mechanism resets to zero. o Flow control is on a per-circuit basis only, not at transport level. Open issues: o No feedback on network delay. E.g., based on buffer conditions, outbound queues, but no information on usage, network. o Initial window is granted immediately. Relationship to Other Work It was noted that RFC 1001 and RFC 1002 relate to support of NetBIOS over TCP/IP. However, they support this directly from end-system to end-system, which makes them quite different than DLSw. Stev Knowles indicated that the surface similarity in support would not pose a problem in DLSw's acceptance in IETF. Discuss Change Control Procedures There were several shorter discussions during the meeting as well as at this agenda topic time regarding the issues of coordination and change control between the work of the AIW DLSw RIG and the proposed IETF DLSw Working Group. All these discussions are summarized here. At the last AIW DLSw RIG meeting, that group developed several consensus positions regarding its preferences for interacting with the IETF. Each of these is presented here, followed by input from the IETF area directors at the meeting. Comments following a AIW DLSw RIG consensus element are preceded by >>>. ``Consensus of AIW DLSw RIG regarding relationship to IETF. The AIW DLSw RIG, at its February 1994 meeting, discussed the benefits, risks, and costs of taking our DLSw standard to the IETF as well as timing considerations. After considerable discussion, we reached the following agreements.'' >>>These AIW DLSw ``agreements'' are considered as ``proposals'' to the IETF. Some of them may need slight amendment to be acceptable (IETF-rule-wise or politically) and some may be against certain IETF rules and thus not acceptable. o ``AIW DLSw RIG Consensus: We intend to propose our completed AIW DLSw standard to the IETF to be also accepted as an Internet standard.'' >>>Suggest rewording to: ``...to the IETF as a Proposed Internet Standard,'' since the IETF does not consider itself in the position of passing on other groups' work without full consideration and input. The IETF area directors understand that it was never our intention to submit the document as a fait accompli. o ``AIW DLSw RIG Consensus: To shorten the time between our completion and the IETF completion, we will request a BOF session at the March IETF. Because attendance at the BOF is one of the criteria used by the IETF to determine whether to approve a working group, we request that as many DLSw participant companies as possible send a representative to this BOF.'' o ``AIW DLSw RIG Consensus: Document, meetings, mail list, change management.'' - ``The AIW is the standard development body for the DLSw standard. An IETF standard is being pursued as an additional industry benefit.'' >>>It is okay for the AIW to consider itself the primary body, but the full IETF process has to be followed nonetheless. - ``The standard developed by the AIW DLSw RIG is the document submitted to the IETF for its approval.'' >>>Reword because the IETF does not consider itself in the position of passing on other groups' work without full consideration and input. It can be submitted as the Proposed Standard. - ``The DLSw RIG AIW meetings are, simultaneously, the IETF working group meetings. These meetings are open to all interested parties.'' >>>The AIW currently excludes the press from attending the AIW. >>>The IETF working group also meets at the IETF general meetings and must be considered a fully functional working group. - ``The AIW DLSw mail exploder is, simultaneously, the IETF electronic mail forum. Participation in the mail exploder is open to all interested parties.'' >>>Currently, the IETF mail exploder excludes the press. This exclusion may not continue if it will also be the IETF mail exploder. - ``The AIW DLSw RIG is the only group authorized to change the document. This is similar to the relationship between the ATM Forum and the IETF, and between the Frame Relay Forum and the IETF. The only change we are aware that this will create in the AIW standard development process is that IETF members as well as AIW members would be able to make submissions for DLSw.'' >>>Any meeting at the IETF general meeting is a fully functional working group meeting, open to input from all present and must be capable of making decisions. o ``AIW DLSw RIG Consensus: Chair, vice-chair, IETF meetings.'' - ``The AIW DLSw RIG chair, Louise Herndon Wells, will also be the IETF DLSw Working Group chair. The AIW DLSw RIG editor, Alan Bartky, will also be the IETF DLSw Working Group editor. Shannon Nix was selected as the DLSw vice-chair and will manage the DLSw process at the IETF meetings that Louise Herndon Wells is unable to attend.'' >>>The working group can propose a chair/vice- chair/editor to the IETF area director, but the area director must approve the selection and retains the right to remove that person. However, Stev Knowles noted that he has only rarely removed a chair and then only for long-term non-performance. - ``At the full IETF meetings, a subset of AIW DLSw RIG participants will manage the IETF standard process, propose the AIW DLSw RIG documents, and bring back to the DLSw mail exploder or next AIW meeting any feedback from the IETF organization.'' >>>Certainly the mail exploder is a good place for things to happen. However, as stated above, the working group meetings at the IETF general meetings must be fully functional. >>>However, since the IETF meetings have usually been about a month after the AIW meetings, as a point of practicality, it would be rare that enough would have happened between the meetings for much to happen at such an IETF meeting. >>>In summary, with regard to the change control procedures, there is some concern about the meeting at the IETF general meeting BEING ABLE to make substantive changes, although it is unlikely because the leadership will probably be the same and because the AIW meeting preceds the IETF general meeting so closely. Draft of the Proposed DLSW Working Group Charter Because of the number of discussion points, the proposed charter was not adopted. Instead, the BOF leaders, the AIW, and appropriate IETF area directors will work over the network between IETF meetings to attempt to resolve the points of concern and develop a second proposed charter. Comments following a proposed charter element are preceded by >>>. o Purpose of the working group: The Data Link Switching Working Group (DLSW) is formed to develop a draft standard for the routing of SNA and (optionally) NetBIOS traffic across TCP/IP. o Goal of work: The goal of the working group's work is to provide interoperation among routers of different vendors implementing DLSw. o Milestones: The working group has targeted the following milestones. - July 1994 (full IETF) - First meeting at general IETF. Receive interim proposed standard (AIW Approved Pages) from APPN Implementer's Workshop DLSw Related Interest Group (from June 1994 AIW meeting). >>>The interim proposed standard may be ``submitted'' immediately following the June meeting by posting it to the mail exploder. - October 1994 (third 1994 AIW) - Working group meeting in conjunction with APPN Implementer's Workshop. DLSw RIG to approve Closed Pages for AIW DLSw. DLSw Closed Pages becomes amended proposed standard for IETF DLSw Working Group to consider for remainder of meeting. - November 1994 (third 1994 IETF) - February 1995 (first 1995 AIW) - March 1995 (first 1995 IETF): Formally receive/present AIW DLSw RIG Closed Pages as IETF DLSw Working Group proposed standard. - June 1995 (second 1995 AIW) - July 1995 (second 1995 IETF) - September or October 1995 (third 1995 IETF) - October 1995 (third AIW) >>>The precise milestones for each of these meetings will be set as the charter is hammered out. >>>Depending on the number of changes proposed and made after document is received by IETF, an IETF standard may be final within nine months. o IETF sponsorship: This working group is formed under the auspices of the Internet Engineering Task Force. As an IETF working group, its activities follow the working group guidelines in the IETF Procedures manual as well as this document. >>>We need to get the formal name of the IETF operating guide. o Membership/participation. - Qualifications. There is no formal DLSw Working Group membership body or qualifications. The relationship between the IETF and any working groups that meet under its auspices are described in the IETF procedures document. Participation in the DLSw Working Group is appropriate for: 1) vendors with an interest in implementing the standard on their product(s) or interfacing their product(s) to DLSw, 2) users with an interest in using the standard in their organizations, and 3) consultants and other service organizations with an interest in assisting their clients with regard to the DLSw standard. - Attendance. DLSw Working Group meetings are held in conjunction with the APPN Implementer's Workshop (AIW). Attendees of the DLSw Working Group meeting are required to register and pay for attendance at the AIW meeting, whether or not they attend any portion of the AIW other than the DLSw Working Group. >>>The IETF has no limitations regarding when working groups meet. The IETF area director does not have concerns about the working group meeting in conjunction with the AIW as long as it is open to the public and does not charge an exorbitant attendance fee. (The AIW attendance fee is a few hundred dollars.) >>>Add ``with the AIW AND THE IETF GENERAL MEETINGS'' and replace ``AIW'' with ``meeting'' the other two times it appears. - E-mail participation. Interested parties are welcome to request participation on the Internet DLSw mail exploders for the DLSw Working Group as a whole and/or its technical groups. Requests to be added to the mailing lists should be sent to aiw-dlsw-request@ibmstandards.cary.ibm.com - Fees. The AIW currently sponsors administrative expenses of the DLSw group, including meeting space at the AIW, Internet mail exploder, and draft publication. These fees are partially covered by AIW conference fees. The participants or their organizations cover the expenses of their representatives' participation (including travel and AIW conference fees). - No commitment to implement. Participation does not mean that a participant or that participant's organization has agreed to implement the resulting standard. >>>Some of these items are covered by the IETF guidelines. - Active participation. All participants are expected to actively contribute and critique technical approaches at meetings and electronic mail. - Consensus. Technical decisions will be made on the basis of technical consensus; i.e., technical discussion will continue until a favored approach emerges. Within that context, however, speedy resolution of technical issues is also considered a key consideration in this work. This consensus may be made at IETF working group meetings at the AIW or through the Internet electronic mail or other official meetings, as discussed below. The group meeting at the IETF general meetings is responsible to the IETF working group and is not intended to operate independently. >>>As stated above, the DLSw Working Group meeting at the IETF general meeting must be allowed to be a fully functional meeting. o Draft document. - Working draft. The starting point for the AIW DLSw work was RFC 1434 as published by IBM in March 1993. RFC 1434 is a public document and any vendor may implement any portion of that RFC and may use the name Data Link Switching without incurring any legal or financial liability or obligation to IBM. This proposal is being enhanced by the AIW DLSw RIG and is expected to be approved as AIW Closed Pages in October 1994. This document will be used as the entering proposed draft for the IETF DLSw Working Group. Further proposals from IBM or other vendors may be covered by one or more patents. For this reason, proposals may only be made by AIW members or IETF members. The working group will use the IETF membership guidelines regarding patents, which are detailed in the IETF membership agreement. >>>The IETF does not have a membership form that companies sign. Participants are expected to operate under a set of IETF guidelines, but there is nothing legally binding them to do so. This caused significant discussion at the meeting and is the main point of concern of several companies -- that a company might, for example, submit a DLSw proposal that is accepted, standardized, and implemented, and is then revealed to be covered under a patent. The AIW membership agreement makes specific, binding company agreements on this point. - Changes by consensus. Any changes to the working group document must be made by consensus of the working group as discussed above. - Completeness. The draft must be complete and detailed enough to allow the interworking of all implementers' products for which the standard is faithfully implemented. - Scope. The intent of the DLSw standard is to address external interface standardization and to leave the implementation of the standard to each implementer. - Focus. In the interest of time, the working group will focus first on required changes and adaptations. Future versions of the document may contain significant expansion, but this will not be attempted in the first version. o Meetings and process. - Frequency. The working group and its technical groups will meet regularly as part of the scheduled AIW sessions, currently scheduled for three to four meetings per year. >>>Add ``and three IETF general meetings per year.'' - Technical groups. The working group will designate and dissolve such technical working groups as it may decide will serve its purposes. Proposals from technical groups must be approved by the working group as a whole to be included in the DLSw document. - Mailing lists. Most of the DLSw working group work is conducted on Internet mail exploder lists. The working group will have a general discussion list and a list for each working group. IBM, through the AIW, provides the list service postmaster. Participation in the working group is through the list-request alias. - Public archive. The AIW maintains an archive of all RIG electronic mail, RFC 1434, posted proposals, and any RIG-approved or working group-approved complete or partial drafts in a publicly FTPable place. >>>Replace first ``RIG'' with ``DLSw'' and add ``IETF'' before ``working group.'' - Electronic mail decisions. Between meetings, IBM sponsors a mail exploder to facilitate the exchange of technical opinions and drafts. Decisions may be made by consensus on electronic mail if sufficient time (two weeks after posting as an official ballot) is allowed for potential dissenters to publish their objections. - Additional official meetings. The DLSw Working Group may officially meet separately from the AIW as long as 1) the meeting is proposed in writing on the Internet mail exploder to the entire working group at least 3 weeks in advance of such meeting and 2) there is not significant objection on the Internet mail exploder to such a meeting. These other official meetings may include videoconferences or teleconferences. (For the purposes of this section, ``official'' means a meeting that is authorized to make decisions for the working group. Individual members of the working group are free to interact with each other unofficially regarding DLSw issues without the above constraints.) >>>Add ``separately from the AIW AND THE IETF GENERAL MEETINGS.'' o Leadership, meetings, agenda, minutes - Leadership---chair. The working group will choose a chair based on consensus. This chair will report on the working group's work to the IETF area director. - Leadership---editor. The working group may choose to split the leadership responsibilities between a chair, for administrative duties, and an editor, for technical responsibility for the draft. If split, the working group will choose an editor based on consensus. - Agenda. A proposed working group agenda will be published before each meeting listing proposed discussion topics. A final agenda will be set based on working group membership input. - Minutes. Minutes of the meeting will be published within a month after each official meeting documenting decisions, priorities, and work assignments. >>>In summary, with regard to the charter, the main point of contention is the protection companies would lose by allowing proposals from companies who are not legally bound by signing a patent and intellectual property rights agreement. In Conclusion Since 1) several companies have significant concerns about the change control issue and the intellectual property rights issue, now that we have more information, and 2) some of ``consensus points'' are not congruent with IETF rules, our the DLSw RIG will need to reconsider 1) whether to still go for the IETF standard and 2) when to officially start the process: a) before we reach AIW closed pages or b) after we reach AIW closed pages. Generally, the benefits of before are that the two standards will be more similar and finished closer together; the benefits of after are that companies maintain the AIW agreement protections and we avoid issues with change control until after the AIW standard is complete. Attendees Steve Buchko stevebu@newbridge.com Greg Celmainis gregc@newbridge.com Wun Chao wun@doelztc.timeplex.com Wayne Clark wclark@cisco.com Peter Gayek gayek@vnet.ibm.com Shawn Gillam shawn@timonware.com William Kwan kwan@crosscomm.com Kevin Loo loo_k@timeplex.com Gilles-Andre Morin gamorin@shl.com Dennis Morris morrisd@cc.ims.disa.mil John Myers jgm+@cmu.edu Shannon Nix snix@metaplex.com Michael Otto mho@netlink.com Benny Rodrig brodrig@rnd-gate.rad.co.il Hal Sandick sandick@vnet.ibm.com Barbara Sterling bjs@mcdata.com Ed Stern els@proteon.com Richard Sweatt rsweatt@synoptics.com John Tavs tavs@vnet.ibm.com