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