Internet DRAFT - draft-davic-ip1394
draft-davic-ip1394
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:28:31 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Wed, 20 Aug 1997 03:04:14 GMT
ETag: "2e6d9b-4ca4-33fa5eae"
Accept-Ranges: bytes
Content-Length: 19620
Connection: close
Content-Type: text/plain
INTERNET DRAFT
Expires December 1997
draft-ietf-ip1394-00.txt
July 1997
IPv4 and ARP over IEEE 1394
Status of this Memo
/* NOT YET
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast).
*/
/* NOT YET
! This draft is a product of the IP over 1394 Working Group of
! the Internet Engineering Task Force. Comments are solicited and
! should be addressed to the working group's mailing list at
! ip1394@mailbag.intel.com and/or the author(s).
*/
Abstract
This document describes a protocol for transmission of the Internet
Protocol Version 4 (IPv4) over IEEE 1394 serial bus.
1. Introduction
IEEE 1394-1995 [1] is a high speed serial bus targeted for Consumer
Electronic devices and home PCs. IEEE 1394-1995 supports asynchronous
and isochronous communications over a shared media at bandwidths
ranging from 100 Mbps to 400 Mbps.
This draft only utilizes the asynchronous capabilities of IEEE 1394-
1995.
IEEE 1394-1995 generally operates under a shared memory model with
the 16 bit node ID and 48 bit offset combined to form a 64 bit memory
location.
Any node can read or write the 64 bit location. The shared memory
model allows a packet received to overwrite a previously received
packet.
Instead of this shared memory model, this specification encourages a
message model similar to ethernet. The message model operates under
the assumption that packets are queued when received. Packets or
messages are removed from the queue to be processed completely and
independently of each other. The message model reduces the
possibility of one packet overwriting a previously received packet.
This document specifies the MTU size, link-fragmentation,
encapsulation, ARP, IP Unicast, and IP Broadcast/IP Multicast by
appropriating a section for each. But first, the protocol stack is
shown in Table 1 and the term link-fragmentation is clarified.
Table 1, as well as, other sections use the term link-fragmentation.
+-----------+------------+
| TCP | UDP |
+-----------+------------+
| IPv4/ARP |
+------------------------+
| LLC/SNAP |
+------------------------+
| Link-Fragment |
+------------------------+
| IEEE 1394-1995 |
+------------------------+
Table 1. IP and ARP over IEEE 1394-1995 protocol stack
Link-fragmentation is the process of dividing a single LLC/SNAP
packet into one or more fragments. Each fragment is encapsulated
into a single IEEE 1394-1995 packet. Link-fragmentation is necessary
to support the IETF recommended MTU size of 576 bytes over 100Mbps
interfaces. 100Mbps interfaces, otherwise known as S100 interfaces
have a maxmum payload size of only 512 bytes. A 576 byte packet must
be devided and sent in two S100 packets. Fragmentation is required.
This fragmentation is called link-fragmentation.
2. MTU size
The MTU size is 2024 bytes. A 2024 byte MTU allows a single LLC/SNAP
packet to be fragmented into four S100 async write packets.
Furthermore, an MTU size of 2024 does not require fragmentation on
S400 interfaces if a packet is equal to the MTU size.
This example of a 2024 byte packet over an S100 interface explains
how the number 2024 bytes was derived. The size of the link-fragment
header is 4 bytes; the LLC/SNAP header is 8 bytes. The first link-
fragment includes the LLC/SNAP and link-fragment headers; the last
three link-fragments include just the link-fragment header. The
payload of the first link-fragment is 500 bytes; the payloads of
the last three link-fragments are 508 bytes. The total payload is
2024 = 500 + (508 * 3).
3. Encapsulation
This section describes the encapsulation of all types of link-
fragments. The layers include the IEEE 1394-1995, link-fragment
header, and the LLC/SNAP header.
The link-fragment types are Begin of Packet(BOP), Continuation of
Packet(COP), End of Packet(EOP), and Single Fragment Packet (SFP).
See the Link-Fragmentation section for details of link-fragment
types.
Table 2 specifies the entire encapsulation format of a first fragment
of an LLC/SNAP packet or a single link-fragment packet(SFP).
This includes the link-fragment header, and the LLC/SNAP header.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 | IEEE 1394-1995 Async Write |
+-------+-------------------------------------------+
| 2 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 3 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 4 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 5 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 6 | Link-fragment Header |
+-------+--------------------------------+----------+
| 7 | LLC | SNAP |
+-------+--------------------------------+----------+
| 8 | SNAP (cont) |
+-------+-------------------------------------------+
| 9 | SNAP Packet Payload Data |
| : | : |
+-------+-------------------------------------------+
Table 2. Encapsulation Format of BOP or SFP
Table 3 specifies the format of link-fragments that are not the first
link-fragment of the packet or are not a single link-fragment packet
(SFP). There is no LLC/SNAP header.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 | IEEE 1394-1995 Async Write |
+-------+-------------------------------------------+
| 2 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 3 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 4 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 5 | IEEE 1394-1995 Async Write (cont.) |
+-------+-------------------------------------------+
| 6 | Link-fragment Header |
+-------+-------------------------------------------+
| 7 | SNAP Packet Payload Data |
| : | (continued from last link-fragment)|
| : | : |
+-------+-------------------------------------------+
Table 3. Encapsulation Format of EOP or COP
Table 4 specifies the format of the 1394 Async write packet headr.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 | dest NodeID | tl rt |tcode pri|
+-------+---------------------+----------+----------+
| 2 | src NodeID | Offset |
+-------+---------------------+---------------------+
| 3 | Offset (cont.) |
+-------+---------------------+---------------------+
| 4 | data length | Extended tCode |
+-------+---------------------+---------------------+
| 5 | Header CRC |
+-------+-------------------------------------------+
Table 4. Async Write Packet Header
The format of this packet matches a standard Async Write. These
comments are only present to explain specific values shown in
specific fields. For more details of the specific header fields,
see IEEE 1394-1995 specification [1].
The offset value of 0xFFFFFFFFFFFF is used for broadcast 1394
packets. 1394 broadcast message include ARP requests. The offset
specified in the ARP response information associated with a specific
node must be used for unicast 1394 messages. ARP responses are 1394
unicast messages.
The source node ID from the 1394 async-write packet is used to
associate a single Link-fragment with an LLC/SNAP packet. A sequence
number is used to maintain the order of link-fragments.
Table 5 specifies the format of the link-fragment header.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+-----+----+
| 1 |stream | source 1394 Node ID |seq |frag|
| | type=0x00| | (6) |type|
| |(LLC/SANP)| | |(2) |
+-------+----------+---------------------+-----+----+
Table 5. Link-fragment Header Format
The value of the 'stream type' shall be 0x00 to define LLC/SNAP
streams.
The value of the 'source 1394 Node ID' shall be the same as the
source the source Node ID of the 1394 async write packet. This value
associates a link-fragment with a LLC/SNAP packet.
This field shall be combined with the 'sequence number' and
'link-fragment type' to assemble a packet.
Link-fragments from a single LLC/SNAP packet are ordered and
assembled using the 6 bit 'sequence number'. The sender shall
continuously increment this number after every fragment is
transmitted. This number shall NOT be reset to zero at the end
of transmitting all the link-fragments of a single packet.
The values of the 2 bit 'fragment type' shall be 0x00 for single
fragment packet (SFP), 0x01 for begin of packet(BOP), 0x02 for
continuation of packet(COP), and 0x03 for end of packet(EOP).
LLC/SNAP specifically refers to IEEE 802.2 LLC [5] and IEEE 802.1A
Sub Network Access Protocol(SNAP) [6]. The SNAP header is used to
identify the EtherType Code as listed in Assigned Numbers [7].
IEEE 802.2 LLC Type One Unnumbered Information(UI) communication
shall be used exclusively.
Table 6 specifies the detailed format of the LLC/SNAP header and
values.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 |DSAP=0xAA |SSAP=0xAA |CTRL=0x03 |Organ Code|
+-------+----------+----------+----------+----------+
| 2 | Organ Code(cont.) | EtherType = |
| | =0x000000 | (0x0800, IP),|
| | | (0x0806, ARP)|
+-------+---------------------+---------------------+
Table 6. LLC/SNAP Header and Values
The total length of the LLC/SNAP header shall be 8 octets.
The value of DSAP and SSAP in the LLC header shall be 0xAA.
The value of the Control(Ctrl) in the LLC header shall be 0x03.
The value of the Organization Code in the SNAP header shall be
0x000000.
The value of the EtherType in the SNAP header shall be 0x0800 for IP
or 0x0806 for ARP.
4. Link-Fragmentation
LLC/SNAP packets encapsulate IP or ARP packets. The link-fragments
encapsulate portions of, or the entire, LLC/SNAP packet. There are
four types of link-fragments: Begin of Packet(BOP), Continuation of
Packet(COP), End of Packet(EOP), and Single Fragment Packet(SFP).
The link-fragment type of SFP is used if the entire LLC/SNAP packet
is able to fit into a single link-fragment. Otherwise, the first
portion of the LLC/SNAP packet is placed in a BOP link-fragment.
The last portion of the LLC/SNAP packet is placed in the a EOP link-
fragment. The middle portions are of the LLC/SNAP packet are placed
in COP link-fragments.
The IEEE 1394-1995 interface types are S100, S200, and S400.
Requirements for the maximum size of link-fragment payloads are
different for each.
The maximum payload of a S100 link-fragment packet is 508 bytes.
The number is derived by subtracting the size of the link-fragment
header from the maximum payload of a S100 packet (i.e. 512-4).
The maximum payload of a S200 link-fragment packet is 1020 bytes.
The number is derived by subtracting the size of the link-fragment
header from the maximum payload of a S200 packet (i.e. 1024-4).
The maximum payload of a S400 link-fragment packet is 2024 bytes.
The number equals the MTU size.
The recomended minimum sizes for S100, S200, and S400 interfaces are
the same. There are no required or suggested minimum size for SFP
and EOP link-fragments. The recommended minimum link-fragment size
for BOP and COP link-fragments is 64 bytes.
5. Address Resolution Protocol (ARP)
In general, Address Resolution Protocol (ARP) consists of requests
and responses to map unknown hardware addresses to known IP
addresses.
In the case of IEEE 1394-1995, the hardware address is called the
1394 address. The 1394 address is a combination of the IEEE 1394-1995
Bus ID, IEEE 1394-1995 Phy ID, and IEEE 1394-1995 offset.
In addition to the 1394 address, ARP over 1394 requests retrieve a
world wide unique id (WWUID) used to uniquely identify each node on
the network.
Other types of networks use the hardware address as the global unique
identifier. The 1394 address cannot be a unique 1394 node Identifier
because the node ID changes when a device is connected or
disconnected from the network.
ARP requests shall be sent to the local bus broadcast Node ID of
0xFFBF with the offset of 0xFFFFFFFFFFFF. This Node ID consists of
a 10 bit bus ID of 0x3FE and a 6 bit phy ID of 0x3F.
The destination information in the payload of the ARP request has
no meaning.
It is recommended this portion be filled with ones.
ARP responses shall be unicast messages.
The destination information in the ARP response shall be taken from
directly from the source information in the ARP request.
The source information in the ARP response shall be derived from
information that resides in the responding node.
ARP caches shall be cleared on bus resets.
The format of the ARP request/response packet is shown in Table 7.
+-------+----------+----------+----------+----------+
|quadlet| octet 1 | octet 2 | octet 3 | octet 4 |
+-------+----------+----------+----------+----------+
| 1 | Hardware Type=0x18 | ProtocolType=0x800 |
+-------+----------+----------+----------+----------+
| 2 | SHWaLen | SWwuidLen| SIPaLen | DHWaLen |
+-------+----------+----------+----------+----------+
| 3 | DWwuidLen| DIPaLen | operation code |
+-------+----------+----------+---------------------+
| 4 | Source Node ID | Src IP Ucast Offset |
+-------+---------------------+---------------------+
| 5 | Src IP Ucast Offset (cont.) |
+-------+-------------------------------------------+
| 6 | Source World Wide Unique ID |
+-------+-------------------------------------------+
| 7 | Source World Wide Unique ID (cont) |
+-------+-------------------------------------------+
| 8 | Source IP Address |
+-------+---------------------+---------------------+
| 9 | Destination Node ID | Dst IP Ucast Offset |
+-------+---------------------+---------------------+
| 10 | Dst IP Ucast Offset (cont.) |
+-------+-------------------------------------------+
| 11 | Destination World Wide Unique ID |
+-------+-------------------------------------------+
| 12 | Destination World Wide Unique ID (cont) |
+-------+-------------------------------------------+
| 13 | Destination IP Address |
+-------+-------------------------------------------+
Table 6. ARP Request/Response Packet
Note: The entire ARP header is not described here, just the portions
relevant to this specification. Refer to [8] for more details.
The value of the 'Hardware Type' shall be 0x18. [9]
'SHWaLen' and 'DHWaLen' are the length of the source and destination
address respectively. This includes the offset and the node id.
The value of this field is 8.
'SWwuidLen' and 'DWwuidLen' is the length of the World Wide Unique
Id for the source and destination, respectively.
The value of this field is 8.
'SIPaLen' and 'DIPaLen' is the length of the IP address for the
source and destination, respectively.
The IP Unicast Offsets is used to send all unicast messages by that
particular node. It may be 0xFFFFFFFFFFFF which is the same as
broadcast messages or some other node unique value.
The World Wide Unique IDs (source and destination) are defined by
IEEE 1394-1995.
6. IP Unicast Messages
IP Unicast messages use bus ID of 0x3ff and the node specific phy ID.
7. IP Multicast and Broadcast
IP Multicast and Broadcast messages shall be mapped to IEEE 1394-1995
broadcast destination Node IDs of 0xFFBF with an offset of
0xFFFFFFFFFFFF. The Node ID of 0xFFBF is the same as a bus ID of
0x3FE and the phy ID of 0x3F.
8. Security Considerations
Security issues are not discussed in this document.
9. Acknowledgments
Most part of this document is derived from "DAVIC 1.2 specification
part7" [3] and "DAVIC 1.2 Baseline Document #41" [4].
The author would like to acknowledge the work of DAVIC, especially
Myron Hattig.
10. References
[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
11. Authors' Addresses
AUTHOR Expires December 1997 [Page xx]
