2.3.7 IP Over IEEE 1394 (ip1394)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

Tony Li <tli@juniper.net>
Myron Hattig <myron_hattig@ccm.jf.intel.com>

Internet Area Director(s):

Jeffrey Burgan <burgan@home.net>
Thomas Narten <narten@raleigh.ibm.com>

Internet Area Advisor:

Jeffrey Burgan <burgan@home.net>

Mailing Lists:

General Discussion: ip1394@mailbag.intel.com
To Subscribe: listserv@mailbag.intel.com
In Body: subscribe ip1394
Archive: TBD

Description of Working Group:

The goal of the IP1394 Working Group is to define how the Internet Protocol (IPv4 & IPv6) is supported over IEEE 1394 Serial Bus. IEEE Std 1394-1995 and the draft standard IEEE P1394a specify IEEE 1394 Serial Bus (1394). The IP1394 working group intends for the specification to be utilized by devices with a broad range of capabilities. These devices are expected to include (but not be limited to) both traditional equipment such as computers, as well as equipment that has not traditionally been networked, such as consumer electronics (e.g. TVs & VCRs).

Unlike most other data link protocols, IEEE 1394 provides the capability for isochronous as well as asynchronous transmission. This capability can have a significant impact on how IP is supported on 1394. The IP1394 working group will prepare an architecture document and appropriate protocol documents for the usage of these unique link layer properties. Both IPv4 and IPv6 will be addressed, although in separate documents.

The IP1394 working group is chartered to deliver the documents described below. The working group will maintain informal liaison with other standards groups and industry organizations doing related work. Some of these documents may depend upon facilities not currently standardized in 1394. If necessary, working group members will work within the IEEE standards process to request modification or extension of existing IEEE standards (or standards in development).

The deliverable documents are as follows:

· An architecture document detailing the interactions between 1394 asynchronous and isochronous transmissions, resource reservation and multicast.

· An IPv4 over 1394 document covering the encapsulation and framing of IPv4 unicast, multicast and broadcast packets over asynchronous and isochronous 1394, including address resolution.

· An IPv6 over 1394 document covering the encapsulation and framing of IPv6 unicast, multicast and broadcast packets over asynchronous and isochronous 1394, including neighbor discovery.

· A media-specific MIB for managing 1394 interfaces.

Goals and Milestones:

Jul 97

  

Meet to evaluate the various proposals presented for the transmission of IP over 1394. Also discuss interaction document.

Aug 97

  

Meet in Munich to further discuss the proposals.

Sep 97

  

Post Internet-Draft for the architecture document.

Sep 97

  

Post Internet-Draft for IP(v4) over 1394.

Dec 97

  

Meet in Wash., D. C. to discuss implementation experiences.

Apr 98

  

Submit architecture document as an Informational RFC.

Apr 98

  

Submit IP(v4) over 1394 for publication as a Proposed Standard.

Jun 98

  

Post Internet-Draft for IP(v6) over 1394.

Jun 98

  

Post Internet-Draft for a 1394 specific MIB.

Dec 98

  

Shut down working group

Dec 98

  

Submit 1394 specific MIB for publication as a Proposed Standard.

Dec 98

  

Submit IP(v6) over 1394 for publication as a Proposed Standard.

Internet-Drafts:

No Request For Comments

Current Meeting Report

INTERIM Meeting

IP over 1394 (ip1394) Working Group Meeting Minutes
July 8th and 9th, 1997
Hosted by Intel in Hillsboro, OR

Attendees:

Peter Johansson, Congruent Software, pjohansson@aol.com
Koichi Tanaka, Sony, Tanaka@sm.sony.co.jp
Michael Deacon, Samsung, mdeacon@mtc.samsung.com
Rudi Bloks, Philips, bloks@natlab.research.philips.com
Fernando Matsubara, Mitsubishi, fernando@nambc.mea.com
Jeffrey Burgan, IETF Representative, @Home Networks, burgan@home.net
Rajiv Choudhary, Intel, Rajiv_choudhary@ccm.jf.intel.com
Barbara Love, Hewlett Packard, barbara@rosemail.rose.hp.com
Shivaun Albright, Hewlett Packard, shivaun_albright@hp.com
Andy Henroid, Intel, Henroid_andrew@ccm.jf.intel.com
John Fuller, Microsoft, jfuller@microsoft.com
Dick Scheel, Sony, dicks@lsi.sel.sony.com
Dirk Brandewie, Intel, dirk@mink.intel.com
Kaz Honda, Sony, honda@sm.sony.com.jp
Izzat Izzat, Thomson CE, izzati@indy.tce.com
Myron Hattig, Intel, Myron_hattig@ccm.jf.intel.com

1.0 Summary

We started the meeting with introductions and the following agenda:
· Status of working group
· Review proposals
· Identify requirements of protocols
· Discuss architectural interaction document
· Define Async Unicast IP, ARP, and Async IP Broadcast
· Capture options for isoch/async IP multicast/broadcast
· Publish Interim meeting WG Draft to the reflector by July 18th, incorporate comments from the reflector into the draft to be submitted to IETF by July 30th.

Actual Activities Were:
· Status of working group
· Charter to be submitted to IESG July 11th.
· Mail Archive exists but is not accessible by people not on list.
· To retrieve archive send mail to listserv@mailbag.intel.com, no subject msg of "get ip1394 LOGyymm" with yy="97","98", mm="01","02"."12"
· Review proposals - Microsoft, DAVIC, Asynchronous Streaming
· Defined Async Unicast IP (Msg Queue or Pull), ARP (Async Stream), and Async IP Broadcast (Async Stream), election algorithm for IP
· Resource Manager.
· Discussed issues for isoch IP multicast/broadcast

Action Items
· Hattig to publish meeting minutes by July 11th.
· Johansson to publish WG draft by July 18th.
· Johansson to incorporate feed back on the reflector and submit to IETF as a WG draft by July 30th. Interim doc will be posted on symbios FTP site.
· Scheel, Honda, Johannson, Fuller, Bloks, Hattig, Brandewie to share critical issues with IEEE p1394x (x=a,b,1), silicon, board, product vendors, and software stack providers ASAP. Critical issues are:

· Everyone to stay focused on Async IP Unicast, Async IP Broadcast, and ARP, but help group develop understanding of IP Multicast.
· Everyone to consider implementation plans for when spec firms up.

2.0 Technical Results

· We agreed that an IP subnet includes all 1394 buses connected via 1394 bus bridges. We wish to support this concept until we prove it cannot be supported.
· We agreed MTU size is around 2048 (max size of S400 packet).
· We agreed on a need for terminology. Did not agree on exact terms, but during the meeting we used the following terms (mostly):

· This document will use these terms.
· Other technical results relate to the IP resource Manager, Streaming (ARP, and Async IP Broadcast), ARP, IP Unicast, IP Broadcast, and IP Multicast.

2.1 IP Resource Manager (new name needed)

This proposal was taken from postings on the reflector originating from P. Johannson, and then by Kaz Honda & Kenji Fujisawa. Please refer to the posting for details. Here is a brief summary.

At startup, a node becomes the IP resource manager according to algorithm in proposal. The IP resource manager allocates a channel number (but no bandwidth), then communicates the channel number to all IP nodes on the bus. This single channel number is used for all IP Asynchronous Broadcasts, all ARP request, and all ARP responses.

Other channels maybe allocated for many purposes which are to be defined. Possibilities include Async IP Multicast, Isoch IP Multicast. See IP Multicasting for more details.

The initial allocation of the single channel for ARP and Async IP Broadcast is required for Asynchronous Streaming.

Note: make mod to proposal so a value in register indicates if a node is IP capable.

2.2 Streaming

Asynchronous Streaming is required for Async IP Broadcast and ARP.

Isochronous streaming may rely on the IP resource manager and may be similar to async streaming in many ways, but the group believes we should focus on Async streaming first. This will give us an understanding of streaming issues in general as well as time to learn more about possibilities and requirement for isoch streaming over 1394. Here we only discuss Async streaming for use of IP broadcast and ARP.

Async streaming sends an isochronous data block packet over asynchronously arbitrated time cycle. The format of an isochronous data block as shown in Figure 6-17 Page 155 of the IEEE 1394.1995 specification follows:

+-----------------+----------+--------------+------------+---------+
|data len(16 bits)|tag(2bits)|channel(6bits)|tcode(4bits)|sy(4bits)|
+-----------------+----------+--------------+------------+---------+

Async streaming requires link fragmentation to reassemble IP packets.
Encapsulation format of the BOP, COP, EOP Link Fragment Header follows:

+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Seq Num (14 Bit)|Reassembly ID (16 bits)|
+------------------+-----------------------+----------------------+
Encapsulation format of the SFP Link Fragment Header follows:
+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Reserved (14 Bit) | EtherType (16 bits) |
+------------------+-----------------------+----------------------+

Frag Type = BOP=0x1, COP=0x3, EOP=0x2, SFP=0x0.
Reassembly ID = may be senders Node ID, but receiver cannot use ID for purposes other than packet reassembly.
Seq Num = increment every fragment - no start/reset value agreed.
Did agree that this is a simple method of error detection that relies on further error detection at higher layers.
EtherType = same definition as LLC/SNAP EtherType field, (e.g. IP = 0x800, ARP = 0x806)

Asynchronous streaming supports:
· One logical data stream from one source node per channel.
· One logical data stream from multiple serial sources per channel.

Asynchronous streaming does not support:
· Multiple logical data streams from one source node per channel.

Note: We need to investigate implementation issues with Async streaming. Reportedly silicon supports such streams, but software interfaces may not. Link chip up through several software interfaces (e.g.,. Microsoft 1394 WDM Class driver). Need some mechanism to support async streaming.

2.3 ARP

The format of the ARP response and ARP request follows:

+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 | HardwareType = 0x18 |ProtocolType = 0x800 |
+-------+---------------------+----------+----------+
| 2 |HW Len=16 |IPLen = 4 |OpCode=ArpRqs/ArpRsp |
+-------+---------------------+---------------------+
| 3 |Src World Wide Unique ID |
+-------+---------------------+---------------------+
| 4 |Src World Wide Unique ID (cont.) |
+-------+---------------------+---------------------+
| 5 | Src Node ID | Src Unicast Offset |
+-------+-------------------------------------------+
| 6 |Src Unicast Offset (cont.) |
+-------+---------------------+---------------------+
| 7 |Dst World Wide Unique ID |
+-------+---------------------+---------------------+
| 8 |Dst World Wide Unique ID (cont.) |
+-------+---------------------+---------------------+
| 9 | Dst Node ID | Dst Unicast Offset |
+-------+-------------------------------------------+
| 10 |Dst Unicast Offset (cont.) |
+-------+---------------------+---------------------+

Usage of WWUID, Node ID, and offset. We concluded that given the range of possible implementations all fields (i.e. Node ID, offset, and WWUID) may or may not be used. The final result is that all fields must be in the ARP msg. ARP uses the common channel number allocated by the IP REsource manager on startup. That same channel number is written to a register in all IP capable nodes. As stated earlier, this is part of the Async Stream proposal.

Link Fragmentation is needed. ARP message must always use SFP link fragments.

Encapsulation format of the SFP Link Fragment Header follows:
+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Reserved (14 Bit) | EtherType (16 bits) |
+------------------+-----------------------+----------------------+

Frag Type = BOP=0x1, COP=0x3, EOP=0x2, SFP=0x0.
EtherType = same definition as LLC/SNAP EtherType field,
(e.g. IP = 0x800, ARP = 0x806)

2.4 IP Unicast

All work was related to Async IP Unicast; not Isoch IP unicast. We agreed that Isochronous IP Unicast did not make sense. Three methods of Async IP Unicast were discussed: Push Model, Pull Model, and Msg Queue.

The Microsoft Proposal, or Push Model, was discussed. The group concluded the Pull Model was fundamentally similar to the Push in that both require memory space to be managed for every source/destination pair. The Push model has memory on destination with the IP packet being pushed (async write) to it. The Pull model has memory on source with the IP packet being pulled (async read) from it. The Pull Model better addressed two issues:

· In the push model, it is believed memory management algorithms would be easier and more robust if maintained on the sender.
· In the pull model, it is believed memory corruption may occur by any node on the bus performing an async write into the destination's memory. Pull model uses async read transactions.

We agreed there is not sufficient understanding of IP over 1394 usage to determine if Msg Queue or Pull Model is best. Here are the descriptions of each followed by a compare/contrast. The details of both proposals will be published by July 18th.

2.4.1 Msq Queue

Encapsulation format of the BOP, COP, EOP Link Fragment Headr follows:

+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Seq Num (14 Bit)|Reassembly ID (16 bits)|
+------------------+-----------------------+----------------------+
Encapsulation format of the SFP Link Fragment Header follows:
+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Reserved (14 Bit) | EtherType (16 bits) |
+------------------+-----------------------+----------------------+

Frag Type = BOP=0x1, COP=0x3, EOP=0x2, SFP=0x0
Reassembly ID = may be senders Node ID, but receiver cannot use ID for purposes other than packet reassembly.
Seq Num = increment every fragment - no start/reset value agreed.
Did agree that this is a simple method of error detection that relies on further error detection at higher layers.
EtherType = same definition as LLC/SNAP EtherType field, (e.g. IP = 0x800, ARP = 0x806)
Requires 1394.1995 max_rec to support 512-byte payload to prevent retries from consuming a high percentage of bus bandwidth.

Notes:
· Fields in LLC/SNAP header are fixed except for EtherType; therefore, there is no need for most of the LLC/SNAP hdr fields. EtherType distinguishes between ARP and IP packets. This function is only necessary in SFP link fragments; hence, it only exists in SFP link fragment headers.
· Link Fragment Header is same format as ARP, Async IP Unicast, and Async IP Broadcast.
· All 1394 packets are Async Writes.
· 1394 Packets are destined to Node ID and Offset returned in ARP Response.

2.4.2 Pull Model

Notes:

· Sending an IP packet consists of the following steps:
· The IP packet is stored in the source's memory offset X.
· Source node tells destination to come get IP packet from memory offset X,
· Destination node performs async reads to get data from offset X.
· Destination tells source I have the data.
· Memory offset X on source node is ready to send another IP packet
· Offset X is part of a data structure. The entire data structure includes number of buffers, buffer lengths, max transfer size, free buffer register, full buffer register, etc.
· The offset to identify the location of the data structure is the offset returned in the ARP response.

2.4.3 Compare/Contrast MsqQue and Pull Model Bandwidth Overhead

· MsgQue uses async write to transfer IP packet, Pull uses assign read. On S400 Interface async read uses 15 Mbps of bandwidth more than Async write. (See P. Johansson for formula)
· The 4-byte link fragment header for MsgQue uses 4 Mbps of bandwidth on S400 interface (See P. Johansson for formula). Pull has no link fragment header.
· Net difference is Pull uses 11 Mbps more than MsgQue on S400.

"Out of Band" Communication
· Pull method has two additional 1394 async write packets per IP packet transfer. MsgQue has no "out of band" communication.

Two 1394 async write packets are:
· one async write packet to tell destination to come get IP packet
· one async write packet to tell the sender to free the memory used by IP packet.

Processing prior to transfer of IP Packet
· Both methods use ARP for initial gathering of info; polling Unit Directories is not used by either method.
· Pull Method requires retrieving data structure with number of bufs, buf lengths, max transfer size, etc. MsgQue has no such requirement.

Processing Overhead
· MsqQue requires assembly of fragments. Reassembly processing overhead is not required by the Pull method.

Below are the most problematic issues with each method (at least from my interpretation of the group's discussion).

MsqQue:
· MsgQue has no flow control that will cause unwanted retires if que fills. These retries may consume large percentages of bandwidth. The method chosen to reduce the problem, but not eliminate it, is to require a minimum queue size.

Pull Model:
· The Pull method has the sender reliant on the destination to behave properly for transfer of IP packets. Specifically, the destination must tell the sender it has completely transferred the IP packet before the sender can reuse memory for the next IP packet. If there is a single memory queue on the source for all destinations, then a single slow or misbehaving destination may congest all transmissions. The sender may have multiple queues to alleviate the problem, but the problem still exists.

2.5 IP Broadcast

We only discussed Async IP Broadcast. I think most of us assumed there was not much need for isoch IP broadcast because isoch streams are typically Audio or Video content, thus IP multicast would be used. We still need more input on isoch IP broadcast.

Async IP Broadcast uses the common channel number allocated by the IP REsource manager on startup. That same channel number is written to a register in all IP capable nodes. As stated earlier, this is part of the Async Stream proposal.

Link Fragmentation is needed.

Encapsulation format of the BOP, COP, EOP Link Fragment Header follows:

+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Seq Num (14 Bit)|Reassembly ID (16 bits)|
+------------------+-----------------------+----------------------+
Encapsulation format of the SFP Link Fragment Header follows:
+------------------+-----------------------+----------------------+
|Frag Type (2 bits)| Reserved (14 Bit) | EtherType (16 bits) |
+------------------+-----------------------+----------------------+

Frag Type = BOP=0x1, COP=0x3, EOP=0x2, SFP=0x0.
Reassembly ID = may be senders Node ID, but receiver cannot use ID for purposes other than packet reassembly.
Seq Num = increment every fragment - no start/reset value agreed.
Did agree that this is a simple method of error detection that relies on further error detection at higher layers.
EtherType = same definition as LLC/SNAP EtherType field, (e.g., IP = 0x800, ARP = 0x806)

2.5 IP Multicasting

We talked about IP multicast at some length. We had revelations about IP as well as 1394, but no conclusions. Here is a bullet list of topics and issues discussed:

· There will probably be some mapping from IP multicast addresses to channel numbers.
· The channel number may be an isoch or async stream. If no bandwidth is allocate with the channel, then it may be async.
· There is no "in-band" mechanism to determine if an IP multicast address is intended to be async or isoch.
· RSVP, Subnet Bandwidth Management (SBM), or some other "out of band" method may be used to map IP multicast isoch or asyn services.
· To ferret out these issues, the group needs a clear understanding of IP Multicast addresses, IGMP, RSVP, SBM, RTP, allocation of IP Multicast addresses, and mapping of IP multicast addresses to
streams.

3.0 References of Interest taken from submission to reflector many of these documents were available during the meeting.

1. IEEE, "Standard for a High Performance Serial Bus", IEEE 1394-1995, 1995.
2. IEEE P1394a WG, "Draft Standard for a High Performance Serial Bus (Supplement)", P1394a Draft 0.09, June 1997.ftp://ftp.symbios.com/pub/standards/io/1394/P1394a/Drafts/P1394a09.pdf
3. DAVIC, "DAVIC 1.2 specification Part7", March 1997.ftp://monviso.alpcom.it/pub/Davic-Public/Spec1_2/prt07_12.doc
4. Myron Hattig, "DAVIC 1.2 Baseline Document #41", January 1997.
5. IEEE, "IEEE Standards for Local Area Networks: Logical Link Control", IEEE, New York, New York, 1985.
6. IEEE, "Sub Network Access Protocol", IEEE 802.1A.
7. J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC1700, October 1994.
8. David C. Plummer, "An Ethernet Address Resolution Protocol", RFC826, November 1982.
9. IANA, "IANA Assignments", http://www.iana.org/iana/assignments.htmlftp://ftp.isi.edu/in-notes/iana/assignments/arp-parameters
10. Peter Johansson, "INTERNET PROTOCOL (IP) over IEEE 1394-1995" Revision 1, proposal for IP1394 WG, June 1997

39th IETF ip1394 Working Group 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 time.

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 presented individually using this format

· Integrated Services and Multicast presentations
· Items to be discussed on the reflector
· Action Items

2.0 Meeting Objectives

· 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

· 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 support 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 Fragmented 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" proposal 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 discussible 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

3.2.1 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.

3.2.2 Results
· Keep draft as it is.

3.2.3 Next Steps
· None.

3.3 Have Fixed Offset Between Bus Resets

3.3.1 Key Points
· In general we're assuming offset remains the same between bus resets. To account for the occasions 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.

3.3.2 Results
· Keep draft as it is with comments about sending ARP response broadcast on the occasional change of offset.

3.3.3 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.

3.4.1 Key Points
· No one was present in the meeting to represent this point of view.

3.4.2 Results
· None.

3.4.3 Next Steps
· Discuss on reflector.

3.5 Remove or retain bridges as part of WG focus.

3.5.1 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.

3.5.2 Results
· Change 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.

3.5.3 Next Steps
· Update draft.
· Peter J. (I'm assuming with Dick Scheel) will produce 1394 bridging requirements doc.

3.6 Discuss Pull Model

3.6.1 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?

3.6.2 Results
· Both maybe part of spec if peaceful co-existence can be shown.

3.6.3 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

3.7.1 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.

3.7.2 Results
· No change to draft.

3.7.3 Next Steps
· Look into adding 224.0.0.1 as part of the IP Multicast discussion.

3.8 Multiple vs Single FIFO

3.8.1 Key Points
· Strong consensus to have a single FIFO per sender.

3.8.2 Results
· No change to draft.

3.8.3 Next Steps
· None.

3.9 MTU Size

3.9.1 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 that include ethernet.

3.9.2 Results
· Keep draft as it is.

3.9.3 Next Steps
· None.

3.10 Pre-assigned Channel Number

3.10.1 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.

3.10.2 Results
· No change to spec - we still need IP manager election process.

3.10.3 Next Steps
· None.

3.11 16-bit Signature in Link Frag Header

3.11.1 Key Points
· Value must be unique on all nodes on a bus.

3.11.2 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.

3.11.3 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 reflect 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. RJ 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:

· 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 September 5th.

Slides

Integrated Services Background
Definition and Services Provided by IP Multicast over 1394

Attendees List

go to list

Previous PageNext Page