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 <mhattig@pacifier.com>
Sender: IETF IP over 1394 Working Group <IP1394@mailbag.jf.intel.com>
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
<ip1394@mailbag.intel.com>; 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
<ip1394@mailbag.jf.intel.com>; 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