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 are 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 issus are:
- asynchronous streaming requirements - link chip and software APIs
- 512 buffer requirement of msg queue option for async IP unicast
- multiple Isoch talkers using same channel number during a single
isoch time cycle assuming appropriate bandwidth has been alloced
- 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):
IP Packet = IP Header & IP Payload
1394 Packet = 1394 Header (Isoch or Async) and 1394 Payload
Link Fragment = The portion of an IP packet that is currently being
transmitted in a 1394 packet. If the entire IP packet
fits into a single 1394 packet, it is called a single
fragment packet (SFP). Begin of Packet (BOP), Continuation
of packet (COP), and End of Packet (EOP) are other
fragment types. The IP Packet header only exists in a
SFP or BOP link fragment.
This document will 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
Asychronous 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) |Reassmbly 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.
Reassmbly 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
which 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 softare
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) |Reassmbly 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
Reassmbly 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
which 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 asyn 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
Directies 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. Reassebmly 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 which 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 mis-behaving 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) |Reassmbly 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.
Reassmbly 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
which 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 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 Managment (SBM), or some other "out of band"
method may be used to map IP multicast isoch or asyn services.
- To ferrit 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. 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.html
ftp://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
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: WG meeting minutes
From: Myron Hattig <Myron_Hattig@CCM.JF.INTEL.COM>
Sender: IETF IP over 1394 Working Group <IP1394@mailbag.jf.intel.com>
Reply-To: IETF IP over 1394 Working Group <IP1394@mailbag.jf.intel.com>
Date: Fri, 11 Jul 1997 13:15:00 PDT
Message-ID: <Fri, 11 Jul 97 13:18:35 PDT_1@ccm.jf.intel.com>
Received: by ccm.jf.intel.com (ccmgate 3.2 #8) Fri, 11 Jul 97 13:18:35 PDT
Received: (from ccmgate@localhost) by relay.jf.intel.com (8.7.6/8.7.3) id
NAA12112 for ip1394@mailbag.intel.com; Fri, 11 Jul 1997 13:18:35
-0700 (PDT)
Received: from relay.jf.intel.com (relay.jf.intel.com [134.134.131.6]) by
mailbag.jf.intel.com (8.8.5/8.8.4) with ESMTP id NAA16680 for
<ip1394@mailbag.jf.intel.com>; Fri, 11 Jul 1997 13:20:55 -0700 (PDT)
Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release
1.8c) with spool id 9361 for IP1394@MAILBAG.INTEL.COM; Fri, 11 Jul
1997 13:20:56 -0700
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4])
by mailbag.jf.intel.com (8.8.5/8.8.4) with ESMTP
id NAA16688; Fri, 11 Jul 1997 13:20:57 -0700 (PDT)
Received: from mailbag.jf.intel.com (mailbag.jf.intel.com [134.134.248.4]) by re
lay.jf.intel.com (8.7.6/8.7.3) with ESMTP id NAA13211; Fri, 11 Jul 1997 13:25:18
-0700 (PDT)
Return-Path: IP1394@mailbag.jf.intel.com