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 Sender: IETF IP over 1394 Working Group Reply-To: IETF IP over 1394 Working Group Date: Fri, 11 Jul 1997 13:15:00 PDT Message-ID: 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 ; 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