NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
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 propoals. |
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 1994 (ip1394) Working Group
I. Interop Event
· Showed slides regarding Interop between Sony, Toshiba, and Intel (slides have been submitted to IETF to be part of proceedings)
· Only spec related issues was related to the NPM election process. Specifically, one of the implementations did not have a usable NETWORK_CHANNELS register until after a driver was loaded. This caused the slow node to not be detected by the faster nodes. If the slower node has highest phs ID, then two node believe they are the NPM. Potential solutions related to the implementation with the problem will be fully examined before attempting to make changes to the spec.
· Another Interop Event is planned in Hillsboro, OR USA in 6-8 weeks with implementations of IP multicast over 1394 expected.
II. Version 7 spec Walk-Through
· Specific derivations from IETF editorial guidelines are to be posted to the WG chair and the Editor for evaluation.
· Other editorial changes are to be made - see next version of draft for details.
· Agreed unicast offset should remain the same through bus reset.
· There were no substantive changes to technical content.
III. IP Multicast Over 1394
· Started with three proposals
- Multicast Manager (MM) with request/response
- MM with request/advertise
- link source
· Commonly agreed-on points for all proposals are:
- Default behavior is to use broadcast channel to carry IP multicast.
- The protocol to allocate a channel (other than broadcast) will most likely to be for, but not restricted to, high bandwidth asynchronous or isochronous traffic.
- Encapsulation of this protocol is done within Link Encapsulation. Packet size is restricted to MTU. Myron will allocate a new EtherType.
- tens of seconds of delays in channel deallocation are acceptable
- It was agreed there are minimal differences between the two MM proposals, thus a coin-toss determined MM request/advertise to be the leading proposal. There are two proposal remaining: MM with request/advertise and link source.
· The remainder of the time was devoted to flushing out the following details of the a proposal related to the MM request/advertise. Here are the details:
- source broadcasts periodic requests to MM
- MM broadcasts advertisements of all IP multicast addrs (and associated channel) not using the broadcast channel
- receivers do not send request; just listen for advertisement
- optional leave from source with explicit lifetime
- non-periodic updates available on new channel or group
- solicitations must be rate limited
- reject message
- TLVs (Type, LEN, VALUE) encode fields in protocol packets. Did not agree on encoding of Type, Len, and Value fields.
· TLVs inside any of the packet types:
- BusID
- Mapping data struct
- variable length group addr
- channel number
- speed (s100 by default)
- lifetime
- checksum
- variable length group number
- option channel hint for request
- optional reason for rejection
· Packet types with required TLVs:
- advertisement: BusID, Mapping(s), lifetime, checksum
- request: group num, BusID, Channel hint, lifetime, speed, checksum
- solicitation: BusID, Checksum
- reject: group num, BusID, checksum, reason
- leave: group num, BusID, lifetime, checksum
· Time was insufficient to discuss the link source approach
Roster Not Submitted