NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 06-Nov-97
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 (or unsubscribe) ip1394
Archive: listserv@mailbag.intel.com. In body, get ip1394 LOGyymm
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 1394 Serial Bus (1394) is specified by IEEE Std 1394-1995 and the draft standard IEEE P1394a. 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:
· Ipv4 over IEEE 1394
No Request For Comments
Minutes of the IP over IEEE 1394 (ip1394) WG
The goals of this meeting were centered around completing IP unicast. Toward this goal the agenda was to continue with the discussion in progress on the reflector.
At the top of the discussion list was link fragmentation. The only contentious issue left is the presence, or lack of, a length of the link fragment in the link fragment header. For implementing link fragmentation over isoch services on some link chips that don't pass length, we need this field in the parameter. No decisive result, but the next step is to determine how pervasive this problem is today and how long it will likely be present over time. Dirk Brandewie is going to accumulate information then post the results back to the list.
Next topic was the election of the IP manager to allocate and distribute a channel number needed to transfer IP broadcast and ARP packets. Peter Johansson and Dirk worked together prior to the meeting to modify an earlier proposal. The group agreed to move forward with the proposal.
Once we have link fragment header and IP manager election process defined, IP unicast will be complete. A draft with this information is expected in early January. Next steps are IP multicast and Integrated Services.
None Received
Roster not received