Date: 15 Jul 97 12:11:40 -0700 Subject: Delayed with regrets .... From: RichardC@bangate.compaq.com To: colinws@bristol.st.com, mike@fireflyinc.com X-Mailer: Cyberdog/2.0 MIMEEnabled: Y MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Cyberdog-MixedBoundary-0056A15D" Content-Transfer-Encoding: 7bit --Cyberdog-MixedBoundary-0056A15D Content-Type: text/enriched; charset=macintosh Content-Transfer-Encoding: 8bit X-Fontfamily: Monaco X-Fontsize: 9 Gentlemen, Attached are the minutes for the June 10, 1997, Long-Haul PMD meeting in Seattle, WA. Again, I wish to express my regrets regarding the delay in making these minutes available. Sincerely, Richard Churchill, Adv. Portable PC Arch., Compaq Computer Corporation, P.O. Box 692000, ms120205 Houston, TX, 77269-2000 20555 St. Hwy. 249, ms120205, Houston, TX, 77070 richardc@bangate.compaq.com phone: (281)514-6984 fax: (281)518-5324 P1394b Long-haul PMD Task Group, June 10, 1997, Double Tree, SeaTac Airport, Seattle, Washington chair: Colin Whitby-Strevens secretary: Richard Churchill Reflector is the common P1394b reflector -- 'p1394b@fireflyinc.com' "FTP" site is 'http://www.fireflyinc.com/p1394b/' Agenda 1. Welcome and introductions 2. Approval of Agenda 3. Approval of minutes of last meeting 4. Report from S100 PMD Task Group 5. Review of requirements 6. Media and transceiver technologies - Contributions identifying suitable technologies - Contributions on cost saving opportunities - Identification of issues for further study 7. Future plans and schedule 8. AOB 9. Adjourn <<<<<<<< 9:00 AM - Called to order >>>> 1. Welcome, etc. Colin Whitby-Strevens welcomed the group and commenced introductions, followed by description of the agenda. 2. Agenda ... Approved without objection 3. Minutes of last meeting Approved without objection 4. S100 meeting report Deferred until Taka Fujimori arrives ... 5. Review of Requirements 1. 50m reach per hop (100m desirable) Need P1394a PHY pinging to determine worst case [Observation by Mike Teener that original estimates by home builders were routinely bumped at each stage "to ensure a safe margin."] 2. Optical fibre support for S800, S1600, S3200 speeds Minimise cost of S800 first (cost is king) Then common media where possible no need for dynimic speed determination (no"modem-style" signal integrity testing) PMDs must be able to identify their maximum speeds PHYs must negotiate speeds Possibly use PMD intelligence to reduce PMD cost further [Comments by various attendees regarding how to proceed. S800 seen as good starting point. Question regarding UTP support lead to comment by Colin that this is difficult at the speeds we intend, etc.] [Comment regarding an expected rapid evolution to 4 Gb/s speeds as a result of using glass fiber.] [Speed training sited as difficult, and slowing initialization, etc., such that it would be better to have media identify best speeds supported.] [Comment that electro-optical heads may be better/cheaper if slightly intelligent.] 3. P1394a and P1394b above the PMD layers Agreed last meeting to pursue common encoding for all P1394b PHYs/PMDs Same Tree-ID algorithms, Self-ID algorithms fully interoperable with current 1394 - no bus bridging required [Wooten - "Does 'Same encoding' mean same encoding over the media?" Colin/Mike comment that this means that a common point (at port) must have common coding. Wooten points out the need for some intelligence in the connection model, etc.] 4. Amateur installable Installation guidelines, installation test, ... ["The quality of installer is about that of current installers of TV antennae, etc."] 5. Facilitate FCC class B emissions compliance 6. Lasers must be class 1 EYE-SAFE (IEC 825-1 and CDRM (r-DA)) for regulatory purposes in order to be amateur installable. Connection model PHY--PMII--Sub-PHY/PMD-n_transceiver/P1394b-n--->> <<<<---p1394b-n/PMD-n_transceiver/Sub-PHY--PMII--PHY A new reference point is defined, call PMII (PHYS Media Independent Interface). Current P1394b work defines everythink towards the PHY from this interface. The new PMD subgroup defines everything towards the medium ---???? Implementation examples - Cu implementation example **diagram** P1394b-Cu = PMII no subPHY or separate PMD transceiver possibly a small pasive network (resisotr, capacitor, ...) [Is this different from present network? Possibly, but this must support D/S encoding.] [We specify electrical behavior at the connector ...] [This is the 4.5m case ...] - Fibre-optic implementation example **diagram** PMII is P1394b-Cu cable-powered dongle provides EO/OE conversion Sub-PHY communicates PMD speed to PHY properties of SubPHY to be determined [Where can we make things cheaper here?] [Do we want this to be a node? Perhaps, but this is the worst case in terms of cost < Reclocking will be necessary. A true two-port PHY is really cheaper than a 3 port, with a saving of about 30% in gate count/cost. We may be pad-limited, so that gate counts, etc., may be a moot point. Use the gates we need, and don't worry about it too much. Don't need an elasticity buffer, and asynch logic is minimized <. Deterministic jitter does not accumulate, but random jitter does, so we may need to limit the number of 're-clockers' between full PHYs.] [Will send 8B/10B signals. Is this a good thing? < <] [Colin did some re-drawing of the diagram ...] [Discussion of D/S to 8B/10B or such ... A DLL is needed ... ] [Could do something like what SSA did, and define a receiver and re- quire that signals transit the system by whatever means, but arrive as required ...] [One of the reasons we are operating under 'b' is to ensure interoper- ability ... Should be completely orthogonal ... It is not clear what the S100 LH folks are doing with their connector ... If we expect this to work in the home environment, we must provide a solution wherein the user can simply walk up to a wall plug and plug any 1394 in and EXPECT IT TO WORK. This meams that the wall plate is a standard P1394b PHY.] ["Short-term is five years" <] [This model is useful if make the assumption that you can make a simple sub-PHY ... the wall-plate must be a full PHY. We're going to have to solve that problem. All others are a subset of that problem. ... ] [This model is the assumption that ... < ... I beleive that a copper interface to wall-plate connection requires that the wall plate act like a PHY. ... <] diagram -- PHY-Cu--------|--PHY*-----SubPHY/???==||==== [One concern about connection model is whether we support long-haul outside the wall, or 4.5m from equipment to the wall-plate. This would tend to make the wall-plate an optical connector. ... Once you get into the optical domain, you should stay there! The issue is what the user puts into the house, and how the user connects to it. What do we do with a long-haul cable outside the wall?] <<<<<<<< Short Break called at 10:20 AM, for 15 minutes. >>>> <<<<<<<< Actual resumption at 10:59 AM. >>>> Connection Scenarios -- **multiple hand-drawn scenarios** 1. Simple PHY connection off ... 2. Simple PHY connected by Cu to wall-plate, with fiber behind wall 3. Simple PHY via Cu to dongle with optics off to elsewhere 4. Simple PHY via Cu to dongle, to optics, to wall-plate 5. Simple PHY with Cu port and internal connection to SubPHY, etc., to separate optical connector. 6. Simple PHY with Cu port and internal connection to SubPHY, and external transceiver dongle, via separate connector. [There are problems with assuming a powered wall-plate. ... You could run 6V AC, and not run into any such regulatory problems or building code issues.< Is this an activity among Power Rangers? No. Wooten is doing it <.] [Should we support a wall-plate model supporting other networking standards?(Scheel) Are we going to standardize what's behind the wall-plate?(Wooten) We are trying to do a 1394 home network, so who cares what others do? Fiber in the wall is "neutral", and we are defining what is behind the wall-plate, though we will need to specify the grade of fiber, etc., which can be used by anyone else for other applications.] [Some of these scenarios may be valuable for long-term development, though some will be best for short-term effort.] [Several wish to rule out scenario 6. In #4, an optical connector must be specified, while in-wall is a different, simpler issue.] [Scenario 1 is just a short-haul. Scenario 2 defines fiber, and inter- face to it (launch power, etc.) in addition to copper short-haul I/F. Scenario 3 is very close to #2, just varying where the wall-plate is located.] [D/S or not is a separate issue/question.] [If we choose to specify #2, #3 is easy, and vice versa.] [Scenario 2 does not require definition of the behind-wall optical connector.] [User accessible connectors are a different issue from installers requirements behind a wall.] [We can probably achieve a Scenario 2 specification faster than a Scenario 4 spec., since optical connector technology is not so ad- vanced.] [Scenario 6 is rejected. Scenarios 4 and 5 are seen as similar, but with fewer exposed interfaces in #5. Wooten wishes to rule out scenario 5 as a strict subset of scenario 4.] [What is the attenuation each time you transit an optical connector? Will involve specification of this, etc. ... (Scheel) A connector for POF is considered the equivalent of about 10m of fiber/cable.] [Scenario 5 is dropped as as subset of scenario 4, but inadequate in itself for broader application.] [What is different between Scenarios 2 and 4 with regard to providing power? ... Scenario 2 allows wall-plate to be powered from wall, but scenario 4 doesn't without some work. So, should we eliminate scenario 4? Perhaps should define 2/3 so as not to preclude scenario 4. Decid- ing a fiber may be the same as defining a connector. Eye-safety ties us into a loss-budget, which in turn decides the fiber.] [We may be able to define the protocols adequately to obviate the problem of defining the optical portion of the solution. However, our guidance from TA and elsewhere is to provide guidance to home-builders as to what should be pulled through the walls of homes.] [We should concern ourselves to some extent with the interoperability of these various scenarios. We should define the parameters. May be able to beg the issue on the optical connector, but must define the fiber.] Mike Teener moves that we make scenarios 2 and 3 the objectives of the group. Seconded by Richard Churchill. [What are these real tasks ... We would specify: The optical medium mechanical properties The optical performance specification Scenario 1 is covered by the broader 1394b group. Should we specify in final motion where scenario will be handled/ specified?] Motion amended to state that we will specify the items mentioned above (optical medium mechanical properties and performance specification) by consent of Mike Teener. [There will be ramifications back into 1394b ... need to deal with these in a timely manner and ensure that these are folded properly into 'b'.] Question is called. Yeas: 24. Nays: 1. Abstentions: 2. <<<<<<<< Recess for Lunch at 11:58 AM, with planned 1:15 PM resumption. >>>> <<<<<<<< Resumed at 1:30 PM. >>>> Issues for P1394b Do we require support for D/S signalling to the long-haul subPHY? -- YES! Does a subPHY have a node ID? -- Prefer not. Worst case delay issues. -- Use pinging. Jitter properties. -- each side is a separate jitter domain Mismatch of cable speed and PHY speed. -- Use pinging. speed map issues. -- Use pinging Signal integrity start-up -- same as 1394b (don't know yet) start-up procedure -- must be same as 1394b need to train before can detect different from copper (Difference constant?) When DS-SubPHY engages in the local speed signalling during Self-ID, and does D/S style speed filtering ... [Utility of NOT providing D/S support in a wall-plate plug is nil. It will confuse the end-user, and create confusion in the market. Ergo, the wall-plate will require a bi-lingual PHY, not a subPHY.] [Need to report three things: PHY speed, connection to parent speed and ...] [We will have unreliable speed maps ...] [It sounds as if nothing is going to communicate in this unless it is operating at the same speed.(Steve Bard)] [Whole point of -1995 process is to keep a device from communicating at a "bad" speed.] [New approach make the cable a possible source of speed-traps.] [Why would it not be possible to establish a communication between two subPHYs to determine the speed across the cable? Cable has no node-ID, and thus does not have any means of reporting via Self-ID packets, or of being addressed to be polled. If you ping, why not determine the speeds of cables at the same time?] [Do we want the P1394a committee to solve this? It's all "our" problem, so we need to solve it somewhere.] [What about concatenating a packet to the end of a Self-ID (caboose) within the cable to identify a cable length? **** NO, WE DON'T WANT TO DO THIS **** (Hauck) I don't think it is that bad an idea. Caboose already breaks TI parts. If we must ping anyway, let's just do it all by pinging. This means the subPHY may remain a subPHY, as it doesn't require much intelligence.] [SubPHYs pass through arbitration, Tree-ID and Self-ID ...] Properties of SubPHY DS-capable on Cu side Beta-only on optic side May be beta capable on Cu side (though necessarily capable for S800 +) Does not have a node ID Does not have a LINK (Its delay is intrinsic to the cable within which it is embedded) Requires pinging to determine both maximum speed and delay of end-to-end Must be able to speed filter in both directions (speed filtering rules apply in both directions Passes through 1394-1995 arbitration signals opportunity to use gap reduction tricks in beta mode (performance improvements) Must retime signals due to prospect of D/S to beta transitions. Needs some form of elasticity buffer [User model questions remain to be addressed. Do we think scenario 3 is compelling enough? ... ] <<<<<<<< Break called at 3:07 PM, for 15 minutes. Resumption at 3:29 PM. >>>> 4. S100 Long-haul meeting report -- Taka Fujimori <<<< include reference to minutes/ftp site >> <<<< include salient points from minutes >> Addressed basic requirements (including up to S400 data speeds) Raised issues of laser safety requirements Coding scheme information on 4B/5B based long haul coding was presented. Start-up Beta mode underlying even S100 data rates Schedule calls for phase I (S200 PMD, S400 PHY) in '97, and phase II (S400 PMD) in '98 UTP is S100 only Tentative meeting schedule July 8, loc TBD, request for host (one tentative offer) September 2, loc TBD, request for host 6. Media and Transceiver technologies S800 (1 GBaud, 50m) S1600 (2 GBaud, 50m) S3200 (4 GBaud, 50m) [(Del Hanson) Glass fiber is well understood. 850 nm, 50m VCSEL tech- nology meets the requirements for all cases listed. Schedule for GI POF is potentially problematic. (Wooten) If we can get a sense of the rela- tive costs, we may reach a conclusion easily. (Colin) People need to get costing information to present. (Del) POF to meet the safety and other requirements is not likely to be "inexpensive." Perflorinated plastic optical fiber is potentially sufficient, but may in fact cost more (given loss requirements) than glass. Will a fine fiber (glass) with correspond- ing connectors be home-owner friendly and installable? Glass connectors are often very low loss -- may not need such precise connectors for the limited range planned. (?) There should be no significant cost difference between glass and POF. (Scheel) What's happening with receiver technol- ogy? Will likely need GaAs receivers at the speeds we anticipate/plan. Large-core fiber could affect the diameter of the receiver -- large fiber means large detector.] [(Colin) So, we should be able to use a common medium across all data rates. Different media would create serious problems for the consumer.] [Both ends of a fiber must match in terms of speed, emitters, receivers, etc., but an S3200 should be able to operate at lower speeds. Power budgets must match! Sensitivity of the S3200 receiver will be about 3 dB lower than the S800 one ... (Del) I can work on the required proper- ties, but will not be able to attend the August meeting.] [Poll of attendees who feel compentent to address optics issues -- most don't feel competent to deal with this topic, but several did feel they were.] [Del Hanson was asked to come up with a set of trade-offs for supporting all speeds under one specification. Alternative is a seperate specifi- cation for each speed transceiver.] [Does this mean we will end up with separate media for each task group (low speed vs. high speed)? (Colin) We should let the two task groups proceed, and then compare the results. We may be able to settle upon one only for both.] [TIA did not want to support active components behind the wall-plate due to potential problems with heating, power, etc. (Teener) But even a dimmer switch is an active component! (Max) Smart House implies active components, including data, phone, power, etc., that includes active com- ponents. This should not be that much different. Max agrees to and action item to investigate the requirements, etc.] [There is an ISO effort to determine in-wall cable requirements for 1394. Will certainly need to establish a liaison in order to assure they meet 1394b requirements. TIA is also active in this area. (TR 41.8 -- .1 and .2 -- commercial and residential) Ken Taylor is possible liaison. (How to contact? Where is their next meeting? Invite chair, others?) Steve Swanson (Corning) has action item to establish contact.] [ISO/TIA intent is apparently to provide an application independent fiber connectivity. It is not certain that this is viable, or that it will be cost effective. These are to establish a set of rules on how to install fiber in the walls, etc. Should, when we are at the point of specifying things, point to the appropriate specification. We will likely need to drive efforts to design for active components behind a wall-plate. Next TIA is in Quebec City, week of Auguest 18.] [We may need to define our wall-plate unit to conform to a TIA "wall- plate" concealed behind "our" wall-plate. Extended discussion of just where a power interface will exist. We must provide power to the SubPHY/ Transceiver from somewhere, so will we be forced to drive from outside wall (from attached device or dongle) or may we be able to power the wall-plate internally via doorbell transformer, or such?] <<<<<<<< Adjourned at 5:19 PM >>>> ================================================================================ ACTION ITEMS David Wooten - issues regarding providing 6V AC power in the wall for wall-plate devices. Del Hanson - specification issues for single definition of transceivers over all speeds. Max Bassler - investigate requirements and issues for active components in wall- boxes and mounted on wall but not in. Steve Swanson - establish contacts with ISO, and TIA TR 41.8.x groups, and place suitable information on P1394b reflector, working through chairman of P1394b. ============================================================================================== Attendee list: 1 Colin Whitby-Strevens +44-1454-611500 colinws@bristol.st.com 2 Jerry Hauck 408-765-5528 jhauck@ccm.sc.intel.com 3 Dave LaFollette 408-765-2587 dlafolle@mipos2.sc. Intel 4 Steve Midford 408-765-8370 steve_midford@ccm.sc.intel.com 5 Dave Instone +44-1705-486363 dinstone@uk.kyrotex.com 6 Steve Bard 503-264-2923 sbard@ccm.jf.intel.com 7 Eric Hannah 408-765-4441 ehannah@mipos2.sc.intel.com 8 Dong Day 408-434-7660 dong.day@sanjose.vlsi.com 9 Del Hanson 408-435-6246 del_hanson@hp.com 10 Richard Churchill 281-514-6984 richardc@bangate.compaq.com 11 Michael Johas Teener 408-461-4901 mike@fireflyinc.com 12 Andy Vogt +49 7066 30301 arogt@molex.com 13 Max Bassler 630-527-4490 mbassler@molex.com 14 Tony Im 852-263-7311 tim@molex.com 15 Mauricio Castro 011-523-668-1463 mcastro@molex.com 16 Michael Cheong 630-527-4257 mcheong@molex.com 17 Atsuhito Noda 011-81-462-61-4500 anoda@molex.com 18 Goji Tanabe 630-527-4622 gtanabe@molex.com 19 Dave Brunker 630-527-2622 dbrunker@molex.com 20 Joe Salamone 603-746-3512 jsconnect@aol.com 21 Ketan Patel 630-527-4047 kpatel@molex.com 22 Sunny Lam 512-838-6276 sunnyl@us.ibm.com 23 Alistair Coles +44 117 922 8750 anc@hplb.hpl.hp.com 24 Eric Deliot +44 117 922 9539 ed@hplb.hpl.hp.com 25 Keith Conroy 215-426-9105 keithconroy@pulseeng.com 26 Al Kelley 904-829-5600 akelley@tensolite.com 27 Philip Armatis 408-588-2210 philiparmatis@cel.com 28 Dao-Long Chen 970-223-5100x9461 dao-long.chen@symbios.com 29 Bill Pherigo 970-229-3586 wlp@fc.hp.com 30 Michael Nguyen 408-894-3542 michael.nguyen@fcpa.fujitsu.com 31 David Wooten 281-518-7231 david.wooten@compaq.com 32 Patrick Yu 408-588-5436 patrick_yu@el.nec.com 33 Dick Scheel 408-955-4295 dicks@lsi.sel.sony.com 34 Kugao Ouchi 408-588-5503 Kugao_Ohuchi@el.nec.com 35 Imran Asif 408-988-3500x2337 iasif@cel.com 36 Jack Serafin 602-544-0459 jack_a_serafin@ccm.ch.intel.com 37 Bill Prouty 916-785-4631 billp@hprnd.rose.hp.com 38 Mike Brown 602-554-3713 mike_brown@ccm.ch.intel.com 39 Taka Fujimori +81-3-5488-6353 fujimori@arch.sony.co.jp 40 Steve Swanson 607-974-4252 swansonse@corning.com --Cyberdog-MixedBoundary-0056A15D--