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]