Network Working Group P. Johansson Internet-Draft Congruent Software, Inc. Expires: October, 1998 IPv4 over IEEE 1394 STATUS OF THIS DOCUMENT 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 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ABSTRACT This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary methods, data structures and codes for that purpose and additionally defines a method for Address Resolution Protocol (ARP). Expires: October, 1998 [Page 1] Internet-Draft 08 IPv4 over 1394 April 1998 TABLE OF CONTENTS 1. INTRODUCTION.......................................................3 2. DEFINITIONS AND NOTATION...........................................4 2.1 Conformance....................................................4 2.2 Glossary.......................................................4 2.3 Abbreviations..................................................5 2.4 Numeric values.................................................5 3. IP-CAPABLE NODES...................................................6 4. NETWORK_CHANNELS REGISTER..........................................6 5. NETWORK PROTOCOL MANAGER (NPM).....................................7 6. LINK ENCAPSULATION AND FRAGMENTATION...............................9 Encapsulation header...............................................9 6.2 Link fragment reassembly......................................11 7. ADDRESS RESOLUTION PROTOCOL (ARP).................................12 8. IP UNICAST........................................................14 8.1 Asynchronous IP unicast.......................................15 8.2 Isochronous IP unicast........................................15 9. IP BROADCAST......................................................15 10. IP MULTICAST.....................................................16 11. SECURITY CONSIDERATIONS..........................................17 12. ACKNOWLEDGEMENTS.................................................17 13. REFERENCES.......................................................17 14. EDITOR’S ADDRESS.................................................17 Expires: October, 1998 [Page 2] Internet-Draft 08 IPv4 over 1394 April 1998 1. INTRODUCTION This document specifies how to use IEEE Std 1394-1995, Standard for a High Performance Serial Bus (and its supplements), for the transport of Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary methods, data structures and codes for that purpose and additionally defines a method for Address Resolution Protocol (ARP). The group of IEEE standards and supplements, draft or approved, related to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as Serial Bus. 1394 is an interconnect (bus) that conforms to the CSR architecture, ISO/IEC 13213:1994. Serial Bus permits communications between nodes over shared physical media at speeds that range, at present, from 100 to 400 Mbps. Both consumer electronic applications (such as digital VCR’s, stereo systems, televisions and camcorders) and traditional desktop computer applications (e.g., mass storage, printers and tapes), have adopted 1394. Serial Bus is unique in its relevance to both consumer electronic and computer domains and is expected to form the basis of a home or small office network that combines both types of devices. The CSR architecture describes a memory-mapped address space that Serial Bus implements as a 64-bit fixed addressing scheme. Within the address space, ten bits are allocated for bus ID (up to a maximum of 1,023 buses), six are allocated for node physical ID (up to 63 per bus) while the remaining 48 bits (offset) describe a per node address space of 256 terabytes. The CSR architecture, by convention, splits a node’s address space into two regions with different behavioral characteristics. The lower portion, up to but not including 0xFFFF F000 0000, is expected to behave as memory in response to read and write transactions. The upper portion is more like a traditional IO space: read and write transactions in this area usually have side effects. Control and status registers (CSR’s) that have FIFO behavior customarily are implemented in this region. Within the 64-bit address, the 16-bit node ID (bus ID and physical ID) is analogous to a network hardware address---but 1394 node ID's are variable and subject to reassignment each time one or more nodes are added to or removed from the bus. The 1394 link layer provides a packet delivery service with both confirmed (acknowledged) and unconfirmed packets. Two levels of service are available: "asynchronous" packets are sent on a best-effort basis while "isochronous" packets are guaranteed to be delivered with bounded latency. Confirmed packets are always asynchronous but unconfirmed packets may be either asynchronous or isochronous. Data payloads vary with implementations and may range from one octet up to a maximum determined by the transmission speed (at 100 Mbps, named S100, the maximum asynchronous data payload is 512 octets while at S400 it is 2048 octets). NOTE: Extensions underway in IEEE P1394b contemplate additional speeds of 800, 1600 and 3200 Mbps. Expires: October, 1998 [Page 3] Internet-Draft 08 IPv4 over 1394 April 1998 2. DEFINITIONS AND NOTATION 2.1 Conformance When used in this document, the keywords "may", "optional", "recommended", "required", "shall" and "should" differentiate levels of requirements and optionality and are to be interpreted as described in RFC 2119. Several additional keywords are employed, as follows: expected: A keyword used to describe the behavior of the hardware or software in the design models assumed by this standard. Other hardware and software design models may also be implemented. ignored: A keyword that describes bits, octets, quadlets or fields whose values are not checked by the recipient. reserved: A keyword used to describe objects---bits, octets, quadlets and fields---or the code values assigned to these objects in cases where either the object or the code value is set aside for future standardization. Usage and interpretation may be specified by future extensions to this or other standards. A reserved object shall be zeroed or, upon development of a future standard, set to a value specified by such a standard. The recipient of a reserved object shall not check its value. The recipient of an object defined by this standard as other than reserved shall check its value and reject reserved code values. 2.2 Glossary The following terms are used in this standard: address resolution protocol: A method for a requester to determine the hardware (1394) address of an IP node from the IP address of the node. bus ID: A 10-bit number that uniquely identifies a particular bus within a group of multiple interconnected buses. The bus ID is the most significant portion of a node's 16-bit node ID. The value 0x3FF designates the local bus; a node shall respond to requests addressed to its 6-bit physical ID if the bus ID in the request is either 0x3FF or the bus ID explicitly assigned to the node. encapsulation header: A structure that precedes all IP data transmitted over 1394. See also link fragment. IP datagram: An Internet message that conforms to the format specified by RFC 791. link fragment: A portion of an IP datagram transmitted within a single 1394 packet. The data payload of the 1394 packet contains both an encapsulation header and its associated link fragment. It is possible to transmit datagrams without link fragmentation. Expires: October, 1998 [Page 4] Internet-Draft 08 IPv4 over 1394 April 1998 node ID: A 16-bit number that uniquely identifies a Serial Bus node. The most significant 10 bits are the bus ID and the least significant 6 bits are the physical ID. node unique ID: A 64-bit number that uniquely identifies a node among all the Serial Bus nodes manufactured worldwide; also known as the EUI-64 (Extended Unique Identifier, 64-bits). octet: Eight bits of data. packet: Any of the 1394 primary packets; these may be read, write or lock requests (and their responses) or stream data. The term "packet" is used consistently to differentiate 1394 packets from ARP requests/responses or IP datagrams. physical ID: On a particular bus, this 6-bit number is dynamically assigned during the self-identification process and uniquely identifies a node on that bus. quadlet: Four octets, or 32 bits, of data. stream packet: A 1394 primary packet with a transaction code of 0x0A that contains a block data payload. Stream packets may be either asynchronous or isochronous according to the type of 1394 arbitration employed. 2.3 Abbreviations The following are abbreviations that are used in this standard: ARP Address resolution protocol CSR Control and status register CRC Cyclical redundancy checksum EUI-64 Extended Unique Identifier, 64-bits IP Internet protocol (within the context of this document, IPv4) 2.4 Numeric values Decimal and hexadecimal numbers are used within this standard. By editorial convention, decimal numbers are most frequently used to represent quantities or counts. Addresses are uniformly represented by hexadecimal numbers. Hexadecimal numbers are also used when the value represented has an underlying structure that is more apparent in a hexadecimal format than in a decimal format. Decimal numbers are represented by Arabic numerals or by their English names. Hexadecimal numbers are prefixed by 0x and represented by digits from the character set 0 – 9 and A – F. For the sake of legibility, hexadecimal numbers are separated into groups of four digits separated by spaces. For example, both 42 and 0x2A represent the same numeric value. Expires: October, 1998 [Page 5] Internet-Draft 08 IPv4 over 1394 April 1998 3. IP-CAPABLE NODES Not all 1394 devices are capable of the reception and transmission of ARP requests/responses or IP datagrams. An IP-capable node shall fulfill the following minimum requirements: - the max_rec field in its bus information block shall be at least 8; this indicates an ability to accept write requests with data payload of 512 octets. The same ability shall also apply to read requests; that is, the node shall be able to transmit a response packet with a data payload of 512 octets; - it shall be isochronous resource manager capable, as specified by 1394; - it shall support both reception and transmission of asynchronous streams as specified by P1394a; - it shall implement the NETWORK_CHANNELS register; and - it shall be network protocol manager (NPM) capable. 4. NETWORK_CHANNELS REGISTER This register is required for IP-capable nodes. It shall be located at offset 0xFFFF F000 0234 within the node's address space and shall support quadlet read and write requests, only. The format of the register is shown below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|v| npm_ID | reserved | channel | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - NETWORK_CHANNELS format Upon a node power reset or a bus reset, the entire register (with the exception of the most significant bit and the npm_ID field) shall be cleared to zero; the npm_ID field shall be set to ones. The most significant bit (a constant one) differentiates the presence of the NETWORK_CHANNELS register in an IP-capable node from the value (all zeros) possibly returned when offset 0xFFFF F000 0234 is read at node(s) that do not implement this register. NOTE: Nodes compliant with P1394a return an address error response when unimplemented addresses are accessed---but some 1394 implementations are known to return zeros. The valid bit (abbreviated as v above), when set to one, indicates that the channel field contains meaningful information. IP-capable nodes shall transmit neither ARP requests/responses nor broadcast IP datagrams while the valid bit is zero. Expires: October, 1998 [Page 6] Internet-Draft 08 IPv4 over 1394 April 1998 The npm_ID field identifies the physical ID of the network protocol manager (NPM). When npm_ID is equal to 0x3F the physical ID of the NPM is not specified; otherwise it shall be initialized (by the NPM) to the 6-bit physical ID assigned during the self-identification process. The channel field shall be initialized by the NPM (see below) to identify the channel number shared by IP-capable nodes for ARP and IP broadcast. Only the valid bit and the npm_ID and channel fields may be changed by quadlet write requests; the data value in the write request shall be ignored for all other bit positions. 5. NETWORK PROTOCOL MANAGER (NPM) In order for ARP or broadcast IP to function on 1394, a prerequisite is the presence of a network protocol manager (NPM). The domain of the NPM is limited to the local Serial Bus; the functions of the NPM are as follows: - the allocation of a channel number for ARP and broadcast IP; and - the communication of that channel number to all IP-capable nodes on the same bus. All IP-capable nodes shall be capable of functioning as the NPM. Subsequent to a Serial Bus reset a single NPM shall be determined by a distributed algorithm executed by all the NPM-capable nodes. The algorithm is straightforward: the NPM-capable node with the largest 6-bit physical ID shall be the NPM. The steps in the algorithm are as follows: a) An NPM-capable node shall also be a contender for the role of isochronous resource manager. The C (contender) and L (link active) bits in its self-ID packet shall be set to one; b) Subsequent to a bus reset, isochronous resource manager contention takes place during the self-identification process specified by 1394; c) An NPM-capable node that wins the contention process referenced in b) is the NPM and shall proceed with g). Other NPM-capable node(s) not selected as the isochronous resource manager (hereafter referred to as candidates) shall continue with d); d) A candidate NPM shall delay before it attempts to become the NPM. The delay time shall be equal to 15 ms * (irm_ID - candidate_ID), where irm_ID and candidate_ID are the physical ID’s of the isochronous resource manager and the candidate NPM, respectively. After the delay time has elapsed, the candidate NPM shall examine the npm_ID field in its own NETWORK_CHANNELS register; if it is not equal to 0x3F, another node is the NPM. The losing candidate shall wait for the valid bit of its own register to be set before transmitting any ARP requests/responses or IP datagrams; Expires: October, 1998 [Page 7] Internet-Draft 08 IPv4 over 1394 April 1998 e) Otherwise, the candidate NPM shall attempt to read the NETWORK_CHANNELS register of any contenders with a larger physical ID (these nodes were identified by the C bit in their self-ID packets). The candidate NPM shall read the NETWORK_CHANNELS register in the contender with the largest physical ID and progress downward. If the register is implemented, the NPM is determined to be a different node. The losing candidate shall ignore the contents of NETWORK_CHANNELS returned in the read response and shall wait for the valid bit of its own register to be set before transmitting any ARP requests/responses or IP datagrams; f) If no contender with a physical ID larger than the candidate NPM's physical ID implements the NETWORK_CHANNELS register, the search is complete and the candidate becomes the new NPM; g) Once elected, the NPM shall update the npm_ID field in the NETWORK_CHANNELS register of all the IP-capable nodes on the bus (including itself) with its own physical ID. This signals to other candidates that the NPM election process is complete. Either a broadcast write request or a series of write requests addressed to individual nodes may be used; h) The NPM shall attempt to allocate a channel number from the CHANNELS_AVAILABLE register (note that the NPM may also be the isochronous resource manager). If no channel number had been allocated prior to the bus reset, the NPM shall wait one second before it attempts to allocate a channel number. Otherwise, the NPM shall attempt to reallocate the same channel number in use before the bus reset; if the same channel number is not available, the NPM may allocate a different channel number. If no channel number is available, the NPM shall take no additional action (all valid bit(s) were cleared by the bus reset); NOTE: Parts of the preceding step are still under discussion within the working group; there is as yet no consensus as to what time interval the NPM shall wait (if any) before attempting to allocate a new channel number if the previously allocated channel number is unavailable after a bus reset. i) Otherwise, the NPM shall update its own NETWORK_CHANNELS register with the allocated channel number and set the valid bit to one. The NPM shall then write this value to the NETWORK_CHANNELS register of all the IP-capable nodes on the bus. Either a broadcast write request or a series of write requests addressed to individual nodes may be used to propagate the information. In the case that the NPM is unable to allocate a channel number for ARP and broadcast IP, a warning should be communicated to a user that IP initialization could not complete because of a lack of Serial Bus resources. The user should be advised to reconfigure or remove other devices if she wishes to make use of IP. NOTE: If the NPM is unable to allocate a channel number, IP-capable nodes are unable to use the ARP and broadcast IP methods specified by this document. If other methods (e.g., a search of configuration ROM) permit IP-capable nodes to discover each other, they may be able to send and receive IP datagrams. Expires: October, 1998 [Page 8] Internet-Draft 08 IPv4 over 1394 April 1998 An IP-capable node that is not the NPM typically awaits a write to its NETWORK_CHANNELS that sets the valid bit to one; this indicates that the channel field is valid for ARP and IP broadcast. If some time-out elapses without this occurrence, an IP-capable node may attempt to locate the NPM and retrieve valid information from the NETWORK_CHANNELS register. If the npm_ID field in its own NETWORK_CHANNELS register is not equal to 0x3F, the address of the NPM is known; otherwise the node may search for the NPM as described in e) above. In either case, it is recommended that reads of the NETWORK_CHANNELS register not be performed within a tight loop, as this could adversely affect both IP and overall 1394 performance on the local bus. 6. LINK ENCAPSULATION AND FRAGMENTATION All IP datagrams (broadcast, unicast or multicast), as well as ARP requests/responses, that are transferred via 1394 block write requests or stream packets shall be encapsulated within the packet's data payload. The maximum size of data payload, in octets, is constrained by the speed at which the packet is transmitted. Table 1 - Maximum data payloads Speed Asynchronous Isochronous +------------------------------------+ | S100 | 512 | 1024 | | S200 | 1024 | 2048 | | S400 | 2048 | 4096 | | S800 | 4096 | 8192 | | S1600 | 8192 | 16384 | | S3200 | 16384 | 32768 | +------------------------------------+ The maximum data payload may also be restricted by the capabilities of the sending or receiving node(s); this is specified by max_rec in either the bus information block or ARP response. For either of these reasons, the minimum capabilities between IP-capable nodes may be less than the 1500 octet maximum transmission unit (MTU) specified by this document. This requires that the encapsulation format also permit 1394 link-level fragmentation and reassembly of IP datagrams. 6.1 Encapsulation header All IP datagrams transported over 1394 are prefixed by an encapsulation header with one of the formats illustrated below. If an entire IP datagram may be transmitted within a single 1394 packet, it is unfragmented and the first quadlet of the data payload shall conform to the format illustrated below. Expires: October, 1998 [Page 9] Internet-Draft 08 IPv4 over 1394 April 1998 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf| reserved | ether_type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Unfragmented encapsulation header format The lf field shall be zero . The ether_type field shall indicate the nature of the datagram that follows, as specified by the following table. ether_type Datagram +-----------------------+ | 0x800 | IPv4 | | 0x806 | ARP | +-----------------------+ NOTE: Other network protocols, identified by different values of ether_type, may use the encapsulation formats defined herein but such use is outside of the scope of this document. In cases where the length of the datagram exceeds the maximum data payload supported by the sender and all recipients, the datagram shall be broken into link fragments; the first two quadlets of the data payload for the first link fragment shall conform to the format shown below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf|rsv| buffer_size | ether_type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dgl | signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - First fragment encapsulation header format The second and subsequent link fragments (up to and including the last) shall conform to the format shown below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lf|rsv| buffer_size | rsv | fragment_offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | dgl | signature | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - Subsequent fragment(s) encapsulation header format The definition and usage of the fields is as follows: Expires: October, 1998 [Page 10] Internet-Draft 08 IPv4 over 1394 April 1998 The lf field shall specify the relative position of the link fragment within the IP datagram, as encoded by the following table. lf Position +------------------------+ | 0 | Unfragmented | | 1 | First | | 2 | Last | | 3 | Interior | +------------------------+ buffer_size: The size of the buffer, expressed as buffer_size + 1 octets, necessary for the recipient to reassemble the link fragments. ether_type: This field is present only in the first link fragment and shall have a value of 0x800, which indicates an IPv4 datagram. fragment_offset: This field is present only in the second and subsequent link fragments and shall specify the offset, in octets, of the fragment from the beginning of the IP datagram. The first octet of the datagram (the start of the IP header) has an offset of zero; the implicit value of fragment_offset in the first link fragment is zero. dgl: The value of dgl (datagram label) shall be the same for all link fragments of an IP datagram. The sender shall increment dgl for successive, fragmented datagrams; the incremented value of dgl shall wrap from 65,535 back to zero. signature: The sender shall set this field to the most significant 16-bits of its own NODE_IDS register. All IP datagrams, regardless of the mode of transmission (block write requests or stream packets) shall be preceded by one of the above described encapsulation headers. This permits uniform software treatment of datagrams without regard to the mode of their transmission. 6.2 Link fragment reassembly The recipient of an IP datagram transmitted via more than one 1394 packet shall use both signature and dgl to identify all the link fragments from a single datagram. Subsequent to reassembly, the recipient shall verify the IP header checksum of the datagram. NOTE: The use of signature for any purpose other than link fragment reassembly is fraught with error and is strongly discouraged. Upon receipt of a link fragment, the recipient may place the data payload (absent the encapsulation header) within an IP datagram reassembly buffer at the location specified by fragment_offset. The size of the reassembly buffer may be determined from buffer_size. If a link fragment is received that overlaps another fragment for the same signature and dgl, the fragment(s) already accumulated in the Expires: October, 1998 [Page 11] Internet-Draft 08 IPv4 over 1394 April 1998 reassembly buffer shall be discarded. A fresh reassembly may be commenced with the most recently received link fragment. Fragment overlap is determined by the combination of fragment_offset from the encapsulation header and data_length from the 1394 packet header. Upon detection of a Serial Bus reset, recipient(s) shall discard all link fragments of all partially reassembled IP datagrams and sender(s) shall discard all not yet transmitted link fragments of all partially transmitted IP datagrams. 7. ADDRESS RESOLUTION PROTOCOL (ARP) ARP requests and responses shall be transmitted by the same means as broadcast IP datagrams. An ARP request/response is 56 octets and shall conform to the format illustrated below. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hardware_type (0x0018) | protocol_type (0x0800) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hw_addr_len | IP_addr_len | opcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- sender_unique_ID ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender_node_ID | sender_unicast_FIFO_hi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender_unicast_FIFO_lo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender_max_rec| sspd | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sender_IP_address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +--- target_unique_ID ---+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target_node_ID | target_unicast_FIFO_hi | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target_unicast_FIFO_lo | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target_max_rec| tspd | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target_IP_address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - ARP request/response format Field usage in an ARP request/response is as follows: hardware_type: This field indicates 1394 and shall have a value of 0x0018. Expires: October, 1998 [Page 12] Internet-Draft 08 IPv4 over 1394 April 1998 protocol_type: This field shall have a value of 0x0800; this indicates that the protocol addresses in the ARP request/response conform to the format for IP addresses. hw_addr_len: This field indicates the size, in octets, of the 1394- dependent hardware address associated with an IP address and shall have a value of 20. IP_addr_len: This field indicates the size, in octets, of an IP version 4 (IPv4) address and shall have a value of 4. opcode: This field shall be one to indicate an ARP request and two to indicate an ARP response. sender_unique_ID: This field shall contain the node unique ID of the sender and shall be equal to that specified in the sender's bus information block. sender_node_ID: This field shall contain the most significant 16 bits of the sender's NODE_IDS register. sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields together shall specify the 48-bit offset of the sender's FIFO available for the receipt of IP datagrams in the format specified by section 8. The offset of a sender's unicast FIFO shall not change, except as the result of a power reset . sender_max_rec: This field shall be equal to the value of max_rec in the sender’s configuration ROM bus information block. sspd: This field shall be set to the lesser of the sender’s link speed and PHY speed. The link speed is the maximum speed at which the link may send or receive packets; the PHY speed is the maximum speed at which the PHY may send, receive or repeat packets. The encoding used for sspd is specified by the table below; all values not specified are reserved. Value Speed +---------------+ | 0 | S100 | | 1 | S200 | | 2 | S400 | | 3 | S800 | | 4 | S1600 | | 5 | S3200 | +---------------+ sender_IP_address: This field shall specify the IP address of the sender. target_unique_ID: In an ARP request, the value of this field is not specified; it shall be ignored by the recipient. In an ARP response, Expires: October, 1998 [Page 13] Internet-Draft 08 IPv4 over 1394 April 1998 it shall be set to the value of sender_unique_ID from the corresponding ARP request. target_node_ID: In an ARP request, the value of this field is not specified; it shall be ignored by the recipient. In an ARP response, it shall be set to the value of sender_node_ID from the corresponding ARP request. target_unicast_FIFO_hi and target_unicast_FIFO_lo: In an ARP request, the value of these fields is not specified; they shall be ignored by the recipient. In an ARP response, they shall be set to the value of sender_unicast_FIFO_hi and sender_unicast_FIFO_lo from the corresponding ARP request. target_max_rec: In an ARP request, the value of this field is not specified; it shall be ignored by the recipient. In an ARP response, it shall be equal to the value of max_rec from the corresponding ARP request. tspd: In an ARP request, the value of this field is not specified; it shall be ignored by the recipient. In an ARP response, it shall be equal to the value of sspd from the corresponding ARP request. target_IP_address: In an ARP request, this field shall specify the IP address from which the responder desires a response. In an ARP response, it shall be set to the value of sender_IP_address from the corresponding ARP request. 8. IP UNICAST A unicast IP datagram may be transmitted to a recipient within a 1394 primary packet that has one of the following transaction codes: tcode Description Arbitration +--------------------------------------+ | 0x01 | Block write | Asynchronous | | 0x0A | Stream packet | Isochronous | | 0x0A | Stream packet | Asynchronous | +--------------------------------------+ Block write requests are suitable when 1394 link-level acknowledgement is desired but there is no need for bounded latency in the delivery of the packet (quality of service). Isochronous stream packets provide quality of service guarantees but no 1394 link-level acknowledgement. The last method, asynchronous stream packets, is mentioned only for the sake of completeness. This method should not be used for IP unicast, since it provides for neither 1394 link-level acknowledgment nor quality of service---and consumes a valuable resource, a channel number. Regardless of the IP unicast method employed, asynchronous or isochronous, it is the responsibility of the sender of a unicast IP Expires: October, 1998 [Page 14] Internet-Draft 08 IPv4 over 1394 April 1998 datagram to determine the maximum data payload that may be used in each packet. The necessary information may be obtained from: - the SPEED_MAP maintained by the 1394 bus manager, which provides the maximum transmission speed between any two nodes on the local Serial Bus. The bus manager analyzes bus topology in order to construct the speed map; the maximum transmission speed between nodes reflects the capabilities of the intervening nodes. The speed in turn implies a maximum data payload (see Table 1); - the target_max_rec field in an ARP response. This document requires a minimum value of 8 (equivalent to a data payload of 512 octets). Nodes that operate at S200 and faster are encouraged but not required to implement correspondingly larger values for target_max_rec; or - other methods beyond the scope of this standard. The maximum data payload shall be the minimum of the largest data payload implemented by the sender, the recipient and the PHYs of all intervening nodes (the last is implicit in the SPEED_MAP entry indexed by sender and recipient). NOTE: The SPEED_MAP is derived from the self-ID packets transmitted by all 1394 nodes subsequent to a bus reset. An IP-capable node may observe the self-ID packets directly. 8.1 Asynchronous IP unicast Unicast IP datagrams that do not require any quality of service shall be contained within the data payload of 1394 block write transactions addressed to the target_node_ID and target_unicast_FIFO obtained from an ARP response . If no acknowledgement is received in response to a unicast block write request, the state of the target is ambiguous. NOTE: An acknowledgment may be absent because the target is no longer functional, may not have received the packet because of a header CRC error or may have received the packet successfully but the acknowledge sent in response was corrupted. 8.2 Isochronous IP unicast Unicast IP datagrams that require quality of service shall be contained within the data payload of 1394 isochronous stream packets. The details of coordination between nodes with respect to allocation of channel number(s) and bandwidth are beyond the scope of this standard. 9. IP BROADCAST Broadcast IP datagrams are encapsulated according to the specifications of section 6 and are transported by asynchronous stream packets. There is no quality of service provision for IP broadcast over 1394. The Expires: October, 1998 [Page 15] Internet-Draft 08 IPv4 over 1394 April 1998 channel number used for IP broadcast is specified by the NETWORK_CHANNELS register. All broadcast IP datagrams shall use asynchronous stream packets whose channel number is equal to the channel field from the NETWORK_CHANNELS register. Although 1394 permits the use of previously allocated channel number(s) for up to one second subsequent to a bus reset, IP-capable nodes shall not transmit asynchronous stream packets at any time the valid bit in their NETWORK_CHANNELS register is zero. Since the valid bit is automatically cleared to zero by a bus reset, this prohibits the use of ARP or broadcast IP until the NPM allocates a channel number. 10. IP MULTICAST At the 41st IETF working group sessions in Los Angeles, choices for IP multicast were reduced to two: a) multicast manager and b) link source manager (please see the minutes for a more complete description). Time permitted discussion of only one of the two, multicast manager. The working group reached consensus on the following salient features: - IP multicast shall use stream packets, either asynchronous or isochronous, according to the quality of service required - by default all best-effort is transmitted on the channel number identified by the NETWORK_CHANNELS register; - intended multicast sources that wish to use a different channel number request the manager to assign/allocate a channel number to a group address; - there is an explicit reject message if the manager is unable (lack of resources) or unwilling (policy) to assign/allocate a channel; - otherwise, in response the manager broadcasts the current list of group addresses and their channel assignments. The manager also broadcasts the list periodically; - intended receivers typically listen for the broadcast channel list but may also (within reasonable rate limitations) solicit the list; - multicast sources that cease transmission may optionally transmit a leave request with a future time-stamp; - in the absence of a leave request, the manager deallocates channel when its lifetime expires. Multicast sources periodically request their active channel(s) in order to refresh the lifetime of the channel(s); and - the formats of the advertise, request, reject and solicit messages are structured by TLVs to permit future extension. All of this information will be published (with more detail, message formats, etc.) in a separate document for review by the working group. CAUTION: No choice has been made to select either the above scheme or a link source method; the details of IP multicast are still work in progress. Expires: October, 1998 [Page 16] Internet-Draft 08 IPv4 over 1394 April 1998 11. SECURITY CONSIDERATIONS This document specifies the use of an unsecured link layer, Serial Bus, for the transport of IPv4 datagrams. Serial Bus is vulnerable to denial of service attacks; it is also possible for devices to eavesdrop on data or present forged identities. Implementers who utilize Serial Bus for IPv4 should consider appropriate counter-measures within application or other layers. 12. ACKNOWLEDGEMENTS This document represents work in progress by the IP/1394 Working Group. The editor wishes to acknowledge the contributions made by all the active participants, either on the reflector or at face-to-face meetings, which have advanced the technical content. 13. REFERENCES [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer Buses [3] IEEE Project P1394a, Draft Standard for a High Performance Serial Bus (Supplement) [4] IEEE Project P1394b, Draft Standard for a High Performance Serial Bus (Supplement) 14. EDITOR’S ADDRESS Peter Johansson Congruent Software, Inc. 3998 Whittle Avenue Oakland, CA 94602 (510) 531-5472 (510) 531-2942 FAX pjohansson@aol.com Expires: October, 1998 [Page 17]