1. Opening remarks and introductions: John Scheible Jeff Stai Brocade stai@brocade.com Jeff Williams Western Digital jeffrey.l.willams@wdc.com George Penokie IBM gop@us.ibm.com Matt Wakeley HP matt_wakeley@hp.com Bret Ketchum CNT bretk@cnt.com Paul Suhler Seagate paul_a_suhler@notes.seagate.com Bob Snively Sun bob.snively@sun.com Jim Coomes Seagate jim_coomes@notes.seagate.com Edward A. Gardner Ophidian Designs eag@ophidian.com Curt Ridotzway LSI curtr@lsil.com James Stevens JPM stevens@ccsi.com Mark DeWilde PathLight mark@pathlight.com Ron Martin Seagate Software ron.martin@seagatesoftware.com Dave Baldwin Emulex dave.baldwin@emulex.com Dal Allan ENDL endlcom@ibm.net Colin L. Schaffer Mylex cschaffer@mylexboulder.com Gene Milligan Seagate gene_milligan@notes.seagate.com Paul Levin Xyratex levinpa@ix.netcom.com Jeff Stephens FSI grsfsi@aol.com Phil Mills IBM millsp@us.ibm.com Paul Boulay Hitachi CPA p_boulay@hitachi.com Norm Harris Jaycor Networks nharris@jni.com Pak Seto Quantum pseto@tdh.qntm.com Steve Wilson Amdahl scw00@amdahl.com Scott Carlson Amdahl smc20@eng.amdahl.com Bill Martin Gadzoox Networks bmartin@gadzoox.com Giles Fratier IBM gfratier@us.ibm.com Neil Wanamacker Crossroads ntw@crossroads.com John Scheible IBM jpscheible@aol.com Carl Zeitler Compaq carl.zeitler@compaq.com Adge Hawes IBM adge@uk.ibm.com Horst L Truestedt ENDL hotrues@ibm.net Dave Deming Solution Tech ddeming@scruznet.com Mark Hamel Comaq mark.w.hamel@compaq.com David Allen LSI david.allen@lsil.com Gary Warden SRB Consulting gwarden@srbconsulting.com 2. Call for changes to minutes 10/98 No comments. 3. Approval of this agenda Notion expressed that there needs to be more time allotted for AL-2. Agenda items 6.2 and 7 removed... 4. Review of old AL-3 action items None. 5. Old AL-3 business None. 6. Scheduled New Business 0. Jeff Williams introduced a schedule for the AL-3 document a. Document converted to "Frame" by February b. Scrubber proposal introduced by February c. State tables updates by April d. Scrubber incorporated into AL-3 by June e. 98-386vx ready by July f. AL-3 review (rev.0) August g. AL-3 review (rev.1) September h. AL-3 review (rev.2) October Notion that August be the cutoff for any new proposals for AL-3. Otherwise they are moved to AL-4. 1. Multiple Circuit Mode review 98-386v3 1. Need to specify the distinction of CID versus cid. 2. Question regarding since CMRs and CSMs go hand in hand why not combine the two? Come up with a new "name" that includes both resources. The state machine will become a resource of CMR. 3. Change the verbiage in the definition of EMCM from "leaving" to "ending". 4. Question of why BB credit of 0 only. Long lived circuits, don't need credit to OPN. 5. Need to scratch the second sentence in the last paragraph as the second sentence is redundant (with the first). 6. Disaggrement over half-duplex versus simplex, again. How do you differentiate credit between two different circuits? ACKs (class 2) ?and R_RDYs? are addressed via CID and source/destination address. Seems to be a lot of extra management overhead for little gain. Notion there needs to be some verbiage that explains the "advantage" of half-duplex over simplex (or visa versa). There is an implied difference between "data" ACKs and "control" ACKs in the ?half-duplex? model. A question was raised regarding queued ACKs that don't have credit in the half-duplex model. Half-duplex is more AL-2 like. The half-duplex model with a class 3 connection IS a simplex circuit. Two simplex circuits requires less resources than full-duplex in class 3. An attempt was made to drag the group into a "connector war". The half-duplex model however is a much more resource intense solution given a large "loop". Any advantage for using simplex for class 2? Need to allocated resources for the back/return/reverse channel. The burning question is do you have the resources to return ACKs in a half-duplex circuit? Then you have enough resources to build a simplex circuit. Simplex would require more resources for class 2 as you'd need two state machines but the logic is less complex. The bottom line is that both models work but which is the "better" model. Today, most implementations (IP/SCSI) work on a full-duplex model, so there is support for scrapping the half-duplex model in favor of a full-duplex model. The advantage of a half-duplex model is that the target (resource poor) requires less resources to maintain a circuit than an initiator (HPA - resource "rich"). But two simplex channels is basically the same (resource-wise) as a full-duplex channel. Clarification: half-duplex is a circuit (like AL-2) that only small "frames" (R_RDYs, RJTs, ?ACKs?) are returned on the back channel. Simplex requires another circuit for the return of ACKs (versus half-duplex). Given class 2 "people" can live with a simplex model the next question is how large a shift is it to move to simplex. There is a question regarding terminology. A circuit is a connection where information flows in both directions. So there is some confusion as to calling something a half-duplex circuit when in reality data only flows in one direction. To make simplex work for class 2, you'll need two connections between the two communicating ports. But a RDY does not distinguish between data or control which means you must commit resources that may not exist. Or commit resources that aren't used. The onus is placed on the initiator to manage its open connections and may increase the latency in handling OPNs. Circuit is defined as a by-directional connection per FC-??. Open issues: Straw poll half-duplex versus simplex: "an advantage for one implies a disadvantage for the other" Advantages Simplex Half-duplex fewer credit counters can distinguish ACK versus data easier to implement Poll: direct Jeff Williams to change half-duplex to simplex in the MCM document. 10 for/3 against. Jeff Williams will talk with Bob Snively to come up with "better" terminology regarding circuits, connections, etc. 7. Change "begin closing MCM circuit and return to SCM." to "end MCM and to return to SCM." and clean up SCM definition. 8. Note: Use numbers for order, bullets for non-ordered items. "Or" must use "one of the following". 9. Bullet 3 section 1.3.1 need to clarify as to whether or not the BMCM is recognized and what that means. Note that only one BMCM is on the loop at any one time. 10. Section 1.3.2 should be another flag; EMCM transmitted flag and document when to discard and when to forward. 11. Third sentence, section 1.4 should read: An L_Port has a number of these resources that it can assign to a circuit. The CSM may be in one of the following states (see 1.8): 12. Second bullet, third paragraph section 1.4.1 should read: - transition from the MCM IDLE state to the MCM OPEN state: and, 13. And scratch the bullet notation on the last bullet item of that paragraph. 14. Second bullet, second paragraph section 1.4.1 page 5, should be "and". 15. And scratch the bullet notation on the last bullet item of that paragraph. 16. Scratch last paragraph of section 1.4.1 page 5. 17. Second sentence, first paragraph of section 1.4.2; change "may" to "shall". 18. First sentence, first paragraph of section 1.4.2; change "may" to 19. Scratch the last bullet item, fourth paragraph of section 1.4.2. 20. Last sentence, first paragraph of section 1.4.2 shall be rewritten. 21. First paragraph, section 1.4.2 page 6 is correct. Need to edit paragraph four of section 1.4.2 22. First sentence, paragraph 2 of section 1.4.2 page 6 "help me out" 23. In general - lots of work to rewrite whole document to work for "simplex circuits". 24. Third paragraph, section 1.4.3 "...Available_BB_Credit counter for that circuit in order to send a frame." 25. Rework second paragraph of section 1.4.3; removing "set" verbiage. 26. Define absorb - regarding figure 2. 27. Section 1.5.3 should read "...absorbing Primitive Signals, delivering a frame to the FC-2 layer, and forwarding the Transmission Word to the Bypass FIFO." 28. Rework section 1.5.3.1 regarding deleting the Fill Words verbiage. 29. Move the "For example" verbiage in section 1.5.4.2 to a seperate "note" portion. 30. Section labels 1.5.5.1-3 should reference the Multiplexor not the Transmitter. "Short" discussion on what the job of the multiplexor/router is regarding Fill Words, interframe gaps, deleted words, insertion words etc. 31. Concensus is that sections 1.5.5.1-3 need some work. 32. Table 2 - bag the last two Fill Words as well as the RCVff. Given "RCV primitives" are in reality "different SOFs" the two Fill words before the real SOF can go as well. "Short" discussion on whether or not Selective Replicate is necessary. A number of examples for Selective Replicate were described. How do you deal with flow control issues? Current AL-2 applications have other means of selective replicate/multicast type functions. 33. Selective Replicate disappears unless someone invents a compelling reason to resurrect it. 34. Section 1.7.9 goes away as well as the "editor's note" just above that section. 35. Scatter section 1.8 bullet items into appropriate portions of earlier text. 2. Explanation of MCM 98-512v0 3. Scrubber Discussion Cases for a scrubber (or why one needs a scrubber) - An MCM primitive/packet destined for a port that disappears. - Missing RCVff. - Corrupted RCVcid or both the source and destination of an MCM frame or primitive disappear. The BIG issue is the last bullet item. Some believe an occasional LIP is OK others suggest some patterns will identify the errored words and allow them to be removed without intrusive behavior. 7. Unscheduled new AL-3 business None. 8. Review of AL-3 action items None. 9. Adjournment