Date: 8/20/97 10:29AM Subject: 39th IETF ip1394 WG minutes v1.0 I'd like to thank everyone for an intense, productive meeting. We accomplished a considerable amount of work for only meeting 7 hours. Also, it was a pleasure to meet several of you for the first. Below is the revision 1.0 of the meeting minutes. Revision will change as needed. 1.0 Outline of meeting minutes - Meeting Objectives - IP Unicast/Broadcast, and ARP Issues - All issues are listed then presetned individually using this format - Key points of discussion - Results of discussion - Next steps - Summary of changes to draft - Integrated Services and Multicast presentations - Items to be discussed on the reflector - Action Items 2.0 Meeting Ojbectives - Reminder: first deliverable as stated in charter is IPv4 over 1394. - Resolve issues with IP Unicast/Broadcast and ARP - Introduce issues to IETF and the WG related to defining IP multicast and Integrated Services for 1394. 3.0 IP Unicast/Broadcast & ARP Issues - Link Fragmentation & LLC/SNAP - Remove or retain EUI-64 in ARP format - Have fixed offset between bus resets - Discuss Editorial comments regarding current draft. - Remove or retain bridges as part of WG focus. - Discuss Pull Model - Uses of ARP and IP Broadcast Channel - Multiple vs Single FIFO - MTU size - Pre-assigned Channel number - 16 bit signature in Link Frag header 3.1 Link Fragmentation & LLC/SNAP 3.1.1 Key points - link frag is likely to be required for IP over isoch service; therefore, link frag remains in the spec until isoch traffic is understood. - link frag must have mechanism to - identify first, middle, and last frags - identify the length of link frag - identify uniqueness among multiple IP packets being received - re-order out-of-order link fragments - Do we optimize for IP over 1394 or support other network layer protocols? - Four link fragment header formats follow - Option A. Leading contender format: UNFRAGMENTED ! 8 16 24 32 !---------------!---------------!---------------!---------------! !--------------------!----------!-------------------------------! 0 ! Zeros ! Resrvd ! EtherType ! ! 10 ! 6 ! 16 ! !--------------------!----------!-------------------------------! FRAGMENTED ! 8 16 24 32 !---------------!---------------!---------------!---------------! !--!-----------------!----------!-------------------------------! 0 !M ! Offset ! DgId ! Signature ! !1 ! 9 ! 6 ! 16 ! !--!-----------------!----------!-------------------------------! - Ethertype (16 bits) - All Ethertypes defined in RFC 1700, this allows unfragemented suport of other network layer protocols. - More (1 bit) - 0 = no other link-frags, 1 = more link-frags - Offset (9 bits) - quadlet offset. For example, if there are three 500 byte link-frags that compose a 1500 byte IP datagram, then the first, second, and third link-frags would respectively have the offsets 0, 125, and 250. I don't recall the exact group consensus on this, but I'm assuming starting at 0 is necessary to identify the first link-frag. - DataGram ID (6 bits) - Unique IP datagram identifier from a single sender. - Signature - Sender ID that is unique within a single bus. Node ID is good choice. - DataGram ID & Signature ID are used to reassemble link-frags into IP datagram. - Option B. LLC/SNAP format: FRAGMENTED or UNFRAGMENTED 8 16 24 32 !---------------!---------------!---------------!---------------! !--!-----------------!----------!-------------------------------! 0 !M ! Offset ! DgId ! Signature ! !1 ! 9 ! 6 ! 16 ! !--!------------!----!----------!---------------!---------------! 1 ! DSAP ! SSAP ! CRTL ! Org Code ! ! 8 ! 8 ! 8 ! 8 of 24 ! !---------------!---------------!---------------!---------------! 2 ! Org Code (cont.) ! EtherType ! ! 16 of 24 ! 16 ! !-------------------------------!-------------------------------! - M, Offset, DgID, and Signature are same as "Leading Contender" link-frag header. - LLC/SNAP Header, link IP header, only exists in the first link-frag. - LLC/SNAP portion of header is same as definition if RFC 1209. - Option C. LLC/SNAP Compromise format: UNFRAGMENTED ! 8 16 24 32 !---------------!---------------!---------------!---------------! !--------------------!----------!-------------------------------! 0 ! Zeros ! Resrvd ! EtherType ! ! 10 ! 6 ! 16 ! !--------------------!----------!-------------------------------! FRAGMENTED 8 16 24 32 !---------------!---------------!---------------!---------------! !--!-----------------!----------!-------------------------------! 0 !M ! Offset ! DgId ! Signature ! !1 ! 9 ! 6 ! 16 ! !--!-----------------!----------!---------------!---------------! 1 ! Reserved ! EtherType ! ! 16 ! 16 ! !-------------------------------!-------------------------------! - Unfragmented and Fragemented have special processing for Ethertype. - If (EtherType == 0) then (follow with full LLC/SNAP header) else (follow with the IP header or other network layer header as identified by EtherType) - The second quadlet of the fragmented case (Reserved , Ethertype) is only present in the first link-frag, like the IP header. - M, Offset, DgId, and Signature bits equal definitions in "Leading Contender" option. - Option D. Reversed offset format: UNFRAGMENTED ! 8 16 24 32 !---------------!---------------!---------------!---------------! !--------------------!----------!-------------------------------! 0 ! Zeros ! Resrvd ! EtherType ! ! 10 ! 6 ! 16 ! !--------------------!----------!-------------------------------! FRAGMENTED ! 8 16 24 32 !---------------!---------------!---------------!---------------! !--!-----------------!----------!-------------------------------! 0 !FT! Offset ! DgId ! Signature ! !1 ! 9 ! 6 ! 16 ! !--!-----------------!----------!-------------------------------! - Ethertype (16 bits) - All Ethertypes defined in RFC 1700, this allows unfragemented support of other network layer protocols. - FragType (1 bit) - 0 = first link-frag, 1 = non-first link-frag - Offset (9 bits) - quadlet offset count down. For example, if there are three 500 byte link-frags that compose a 1500 byte IP datagram, then the first, second, and third link-frags would respectively have the offsets 250, 125, and 0. Offset 0 identifies the last link-frag. - DataGram ID & Signature ID follow same definition of "Leading Contender" option. - If I understand this proposal accurately, it is very similar to the first proposal with the mechanism to identify the first and last link-frag being swapped. That is the FT here ids the first where, the "leading contender" poposal uses More bit to id the last link-frag; the offset of 0 here ids the last link-frag, the "leading contender" proposal uses the offset of 0 to id the first link-frag; hence, the mechanisms are swapped. 3.1.2 Results - We agreed to add the ability to re-order out-of-order link-frags as a requirement for the link-frag header. - We agreed to optimize for IP over 1394. This means there is no LLC/SNAP layer defined to support other network layer protocols over 1394. No historical reasons support the inclusion of LLC/SNAP. We will investigate IEEE 802.xxx work in progress in search for future LLC/SNAP requirements. - Option A and D listed above are open for more discussion, but LLC/SNAP is no longer on our discussable list until more information is gathered. 3.1.3 Next steps - Finish discussion of formats (that do not include LLC/SNAP) on the reflector. - Collect data for concrete reasons to include LLC/SNAP. Specifically contact 802.xxx working groups. 3.2 Remove or retain EUI-64 in ARP format - Key points - Some believe there will be other software modules in 1394 that will already do the EUI-64 to Node ID mapping, thus removing the need to perform ARP requests if IP addresses are mapped to the EUI-64. - Some believe the EUI-64 value can be used to notify users of device errors related to IP over 1394. - Results - Keep draft as it is. - Next steps - None. 3.3 Have fixed offset between bus resets - Key points - In general we're assuming offset remains the same between bus resets. To account for the occassions which the offset changes, we will send an ARP RESPONSE after the bus reset. - This requires nodes to maintain additional state information to determine whether or not to send the ARP response after a bus reset. - Results - Keep draft as it is with comments about sending ARP response broadcast on the occassional chage of offset. - Next steps - Craft text to state when ARP response is sent and the values in the fields of the ARP response. Of particular interest are the destination Link Layer and IP addresses. One or both of these addresses must be a broadcast. 3.4 Discuss Editorial comments regarding current draft. - Key points - No one was persent in the meeting to represent this point of view. - Results - None. - Next steps - Discuss on reflector. 3.5 Remove or retain bridges as part of WG focus. - Key points - There is one IP manager per 1394 bus, bridges require IP managers on different buses to communicate the bus specific IP broadcast and ARP channel and configure the bridge to map these channel numbers between buses. New protocol needs to be invented here. - All IP nodes in current bridge spec terminology must be "remote node" capable in order to talk to nodes on other buses. This translates to different requirements for "bridged" IP nodes and "non-bridged" IP nodes. - Mappings of IP multicast over 1394 streams (async or isoch) require a one-to-many mapping of 1394 streams through the bridge. This includes the case of the ARP & Broadcast async streams. It is believed this is outside the current scope of the bridging working group. - Bus bridge spec is not complete. - Results - Chage draft to reflect bridges are not within the current scope of the IP over 1394 WG. - Simple issues related to bridges are still open for discussion within the IP over 1394 WG. - Share requirements with bridging WG to ensure coexistence of both specs. - Next steps - Update draft. - Peter J. (I'm assuming with Dick Scheel) will produce 1394 bridging requirments doc. 3.6 Discuss Pull Model - Key points - need spec to be written so it can be discussed. - Pull model may have benefits over msg queue model for large IP packets. - Can Pull Model and Msg Queue model co-exist? - Results - Both maybe part of spec if peaceful co-existence can be shown. - Next steps - Document pull model and discuss on the reflector. - Determine if both can remain in spec as part of pull model discussion. 3.7 Uses of ARP and IP Broadcast Channel - Key points - The WG is not chartered to define non-IP protocols over 1394; non-IP protocols are the concern of other groups. If other spec choose to use this channel, there is no way for our spec to prevent this. - We should limit the traffic we specify to be used on this channel. - IP packets destined for the IP multicast All-Hosts address of 224.0.0.1 is a good candidate to be added to the specified list of uses. - Results - No change to draft. - Next steps - Look into adding 224.0.0.1 as part of the IP Multicast discussion. 3.8 Multiple vs Single FIFO - Key points - Strong consensus to have a single FIFO per sender. - Results - No change to draft. - Next steps - None. 3.9 MTU size - Key points - Discussed compatibility with Ethernet again. Rough consensus was to optimize for 1394 due to lack of solid requirement imposed by other link layer protocols which include ethernet. - Results - Keep draft as it is. - Next steps - None. 3.10 Pre-assigned Channel number - Key points - A pre-assigned channel number is not possible in either 1394.1995 or 1394.a specifications. - The group is targeting 1394.1995 and 1394.a; therefore, this idea is out of scope with our current work. - Results - No change to spec - we still need IP manager election process. - Next steps - None. 3.11 16 bit signature in Link Frag header - Key points - Value must be unique on all nodes on a bus. - Results - Spec will state that NodeID is best choice, but will not mandate NodeID. - Spec will state that any selection process that does not use the NodeID must have reasonable assurances of uniqueness. - Next steps - Update draft. 3.12 Summary of changes to draft - Fixed Offset: Add comment regarding sending ARP response and values in the ARP response fields. - Bridges: Change draft to reflec bridges are not within the current scope of the IP over 1394 WG. - 16 bit Link Frag Header Signature: Spec will state that Node ID is best choice for 16 bit signature in link fragment header, but will not mandate NodeID. Spec will mandate any other selection process to have a reasonable assurance of uniqueness. 4.0 Integrated Service and IP Multicast - There was presentations to inform us of general issue related to Integrated Service. Raj Yavatkar gave this presentation and invited the ISS Co-chairs. They did not object to anything in the presentation, so it appears the information given to the work group represents their understanding of Integrated Services issues. They also now understand some of the features provided by 1394 as a link layer to IP. They gave mentioned 1394 as upcoming work in the closing comments of the final ISS WG session. - I presented some ideas related to IP multicast over 1394. The first issue is how do we map dynamically allocated stream channel numbers to IP multicast addresses. I discussed an ARP mechanism that gets activated by IGMP Join/Leave to perform this mapping others suggested extending the definitions of IGMP. - Both presentations will be posted on the reflector. 5.0 Next items to be discussed on reflector - Link frag header format - IP manager election process - Address editorial comments about current draft - Pull Model - IP Multicast - Integrated Services 6.0 Action Items - Get input from IEEE 802.xxx people regarding planned uses of LLC/SNAP. Tentative date for having this information is Sept 30th. - Next version of draft is to define IP unicast, IP broadcast, and ARP. Draft will be published after rough consensus on following issues: - Link fragmentation - IP Manager election process - Editorial comments - Peter Johansson and Dick Schell will produce bridging requirements doc. Peter and Dick please provide a date for this. - Determine if there is a need and desire to have an interim meeting. Have proposed agenda by August 30th. If agenda is worthy of a meeting, then have date and location by Sept 5th. Text item: External Message Header The following mail header is for administrative use and may be ignored unless there are problems. ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. To: IP1394@mailbag.jf.intel.com Subject: 39th IETF ip1394 WG minutes v1.0 Organization: Hattig Haven From: Myron Hattig Sender: IETF IP over 1394 Working Group Reply-To: mhattig@pacifier.com Date: Wed, 20 Aug 1997 10:29:10 -0800 Message-ID: <33FB3776.4073@pacifier.com> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Mailer: Mozilla 3.01Gold (Win95; I) Received: from mhattig.pacifier.com (ip44.pdx1.pacifier.com [209.95.32.44]) by mail.pacifier.com (8.8.5pac/8.8.4) with SMTP id KAA16212 for ; Wed, 20 Aug 1997 10:22:37 -0700 (PDT) Received: from mail.pacifier.com (mail.pacifier.com [199.2.117.164]) by mailbag.jf.intel.com (8.8.6/8.8.4) with ESMTP id KAA06225 for ; Wed, 20 Aug 1997 10:25:01 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 68044 for IP1394@MAILBAG.INTEL.COM; Wed, 20 Aug 1997 10:25:04 -0700 Received: from mailbag.jf.intel.com by hebe.or.intel.com (8.8.5/10.0i); Wed, 20 Aug 1997 13:30:25 GMT Received: from hebe.or.intel.com (hebe.or.intel.com [134.134.248.4]) by relay.jf .intel.com (8.7.6/8.7.3) with ESMTP id KAA23515; Wed, 20 Aug 1997 10:32:54 -0700 (PDT) Return-Path: IP1394@mailbag.jf.intel.com