[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/