idnits 2.17.1 draft-ietf-ip1394-ipv4-15.txt: -(72): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(100): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(341): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == There are 10 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 24 longer pages, the longest (page 1) being 63 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 119: '...packets MAY be either asynchronous or ...' RFC 2119 keyword, line 120: '...lementations and MAY range from one oc...' RFC 2119 keyword, line 141: '...re design models MAY also be implement...' RFC 2119 keyword, line 149: '...d interpretation MAY be specified by f...' RFC 2119 keyword, line 150: '...rds. A RESERVED object SHALL be zeroed...' (162 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 1190, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1195, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1198, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Johansson 3 Internet-Draft Congruent Software, Inc. 4 5 Expires: November 1999 7 IPv4 over IEEE 1394 9 STATUS OF THIS DOCUMENT 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC 2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, and 14 its working groups. Note that other groups may also distribute working 15 documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 ABSTRACT 30 This document specifies how to use IEEE Std 1394-1995, Standard for a 31 High Performance Serial Bus (and its supplements), for the transport of 32 Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary 33 methods, data structures and codes for that purpose and additionally 34 defines a method for Address Resolution Protocol (ARP). 36 TABLE OF CONTENTS 38 1. INTRODUCTION........................................................3 39 2. DEFINITIONS AND NOTATION............................................4 40 2.1 Conformance.....................................................4 41 2.2 Glossary........................................................4 42 2.3 Abbreviations...................................................5 43 2.4 Numeric values..................................................5 44 3. IP-CAPABLE NODES....................................................6 45 4. LINK ENCAPSULATION AND FRAGMENTATION................................6 46 4.1 Global asynchronous stream packet (GASP) format.................7 47 4.2 Encapsulation header............................................8 48 4.3 Link fragment reassembly.......................................10 49 5. ADDRESS RESOLUTION PROTOCOL (ARP)..................................11 50 6. CONFIGURATION ROM..................................................12 51 6.1 Unit_Spec_ID entry.............................................13 52 6.2 Unit_SW_Version entry..........................................13 53 6.3 Textual descriptors............................................13 54 7. IP UNICAST.........................................................14 55 7.1 Asynchronous IP unicast........................................15 56 7.2 Isochronous IP unicast.........................................16 57 8. IP BROADCAST.......................................................16 58 9. IP MULTICAST.......................................................16 59 9.1 MCAP message format............................................17 60 9.2 MCAP message domain............................................19 61 9.3 Multicast receive..............................................19 62 9.4 Multicast transmit.............................................20 63 9.5 Advertisement of channel mappings..............................20 64 9.6 Overlapped channel mappings....................................21 65 9.7 Transfer of channel ownership..................................21 66 9.8 Expired channel mappings.......................................22 67 9.9 Bus reset......................................................22 68 10. IANA CONSIDERATIONS...............................................23 69 11. SECURITY CONSIDERATIONS...........................................23 70 12. ACKNOWLEDGEMENTS..................................................24 71 13. REFERENCES........................................................24 72 14. EDITOR�S ADDRESS..................................................24 73 1. INTRODUCTION 75 This document specifies how to use IEEE Std 1394-1995, Standard for a 76 High Performance Serial Bus (and its supplements), for the transport of 77 Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary 78 methods, data structures and codes for that purpose and additionally 79 defines a method for Address Resolution Protocol (ARP). 81 The group of IEEE standards and supplements, draft or approved, related 82 to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as 83 Serial Bus. 85 1394 is an interconnect (bus) that conforms to the CSR architecture, 86 ISO/IEC 13213:1994. Serial Bus permits communications between nodes over 87 shared physical media at speeds that range, at present, from 100 to 88 400 Mbps. Both consumer electronic applications (such as digital VCRs, 89 stereo systems, televisions and camcorders) and traditional desktop 90 computer applications (e.g., mass storage, printers and tapes), have 91 adopted 1394. Serial Bus is unique in its relevance to both consumer 92 electronic and computer domains and is EXPECTED to form the basis of a 93 home or small office network that combines both types of devices. 95 The CSR architecture describes a memory-mapped address space that Serial 96 Bus implements as a 64-bit fixed addressing scheme. Within the address 97 space, ten bits are allocated for bus ID (up to a maximum of 1,023 98 buses), six are allocated for node physical ID (up to 63 per bus) while 99 the remaining 48 bits (offset) describe a per node address space of 256 100 terabytes. The CSR architecture, by convention, splits a node�s address 101 space into two regions with different behavioral characteristics. The 102 lower portion, up to but NOT including 0xFFFF F000 0000, is EXPECTED to 103 behave as memory in response to read and write transactions. The upper 104 portion is more like a traditional IO space: read and write transactions 105 in this area usually have side effects. Control and status registers 106 (CSRs) that have FIFO behavior customarily are implemented in this 107 region. 109 Within the 64-bit address, the 16-bit node ID (bus ID and physical ID) 110 is analogous to a network hardware address---but 1394 node IDs are 111 variable and subject to reassignment each time one or more nodes are 112 added to or removed from the bus. 114 The 1394 link layer provides a packet delivery service with both 115 confirmed (acknowledged) and unconfirmed packets. Two levels of service 116 are available: "asynchronous" packets are sent on a best-effort basis 117 while "isochronous" packets are guaranteed to be delivered with bounded 118 latency. Confirmed packets are always asynchronous but unconfirmed 119 packets MAY be either asynchronous or isochronous. Data payloads vary 120 with implementations and MAY range from one octet up to a maximum 121 determined by the transmission speed (at 100 Mbps, named S100, the 122 maximum asynchronous data payload is 512 octets while at S400 it is 2048 123 octets). 125 NOTE: Extensions underway in IEEE P1394b contemplate additional speeds 126 of 800, 1600 and 3200 Mbps. 128 2. DEFINITIONS AND NOTATION 130 2.1 Conformance 132 When used in this document, the keywords "MAY", "OPTIONAL", 133 "RECOMMENDED", "REQUIRED", "SHALL" and "SHOULD" differentiate levels of 134 requirements and optionality and are to be interpreted as described in 135 RFC 2119. 137 Several additional keywords are employed, as follows: 139 EXPECTED: A keyword used to describe the behavior of the hardware or 140 software in the design models assumed by this standard. Other hardware 141 and software design models MAY also be implemented. 143 IGNORED: A keyword that describes bits, octets, quadlets or fields whose 144 values are NOT checked by the recipient. 146 RESERVED: A keyword used to describe objects---bits, octets, quadlets 147 and fields---or the code values assigned to these objects in cases where 148 either the object or the code value is set aside for future 149 standardization. Usage and interpretation MAY be specified by future 150 extensions to this or other standards. A RESERVED object SHALL be zeroed 151 or, upon development of a future standard, set to a value specified by 152 such a standard. The recipient of a RESERVED object SHALL NOT check its 153 value. The recipient of an object defined by this standard as other than 154 RESERVED SHALL check its value and reject RESERVED code values. 156 2.2 Glossary 158 The following terms are used in this standard: 160 address resolution protocol: A method for a requester to determine the 161 hardware (1394) address of an IP node from the IP address of the node. 163 bus ID: A 10-bit number that uniquely identifies a particular bus within 164 a group of multiple interconnected buses. The bus ID is the most 165 significant portion of a node's 16-bit node ID. The value 0x3FF 166 designates the local bus; a node SHALL respond to requests addressed to 167 its 6-bit physical ID if the bus ID in the request is either 0x3FF or 168 the bus ID explicitly assigned to the node. 170 encapsulation header: A structure that precedes all IP data transmitted 171 over 1394. See also link fragment. 173 IP datagram: An Internet message that conforms to the format specified 174 by RFC 791. 176 link fragment: A portion of an IP datagram transmitted within a single 177 1394 packet. The data payload of the 1394 packet contains both an 178 encapsulation header and its associated link fragment. It is possible to 179 transmit datagrams without link fragmentation. 181 multicast channel owner: A multicast source that has allocated a channel 182 for one or more multicast addresses and transmits MCAP advertisements to 183 communicate these channel mapping(s) to other participants in the 184 multicast group. When more than one source transmits MCAP advertisements 185 for the same channel number, the source with the largest physical ID is 186 the owner. 188 node ID: A 16-bit number that uniquely identifies a Serial Bus node 189 within a group of multiple interconnected buses. The most significant 190 ten bits are the bus ID and the least significant six bits are the 191 physical ID. 193 node unique ID: A 64-bit number that uniquely identifies a node among 194 all the Serial Bus nodes manufactured worldwide; also known as the 195 EUI-64 (Extended Unique Identifier, 64-bits). 197 octet: Eight bits of data. 199 packet: Any of the 1394 primary packets; these MAY be read, write or 200 lock requests (and their responses) or stream data. The term "packet" is 201 used consistently to differentiate 1394 packets from ARP 202 requests/responses, IP datagrams or MCAP advertisements/solicitations. 204 physical ID: On a particular bus, this 6-bit number is dynamically 205 assigned during the self-identification process and uniquely identifies 206 a node on that bus. 208 quadlet: Four octets, or 32 bits, of data. 210 stream packet: A 1394 primary packet with a transaction code of 0x0A 211 that contains a block data payload. Stream packets MAY be either 212 asynchronous or isochronous according to the type of 1394 arbitration 213 employed. 215 2.3 Abbreviations 217 The following are abbreviations that are used in this standard: 219 ARP Address resolution protocol 220 BCM Broadcast channel manager 221 CSR Control and status register 222 CRC Cyclical redundancy checksum 223 EUI-64 Extended Unique Identifier, 64-bits 224 GASP Global asynchronous stream packet 225 IP Internet protocol (within the context of this document, IPv4) 226 MCAP Multicast channel allocation protocol 228 2.4 Numeric values 230 Decimal and hexadecimal numbers are used within this standard. By 231 editorial convention, decimal numbers are most frequently used to 232 represent quantities or counts. Addresses are uniformly represented by 233 hexadecimal numbers, which are also used when the value represented has 234 an underlying structure that is more apparent in a hexadecimal format 235 than in a decimal format. 237 Decimal numbers are represented by Arabic numerals or by their English 238 names. Hexadecimal numbers are prefixed by 0x and represented by digits 239 from the character set 0 � 9 and A � F. For the sake of legibility, 240 hexadecimal numbers are separated into groups of four digits separated 241 by spaces. 243 For example, both 42 and 0x2A represent the same numeric value. 245 3. IP-CAPABLE NODES 247 Not all 1394 devices are capable of the reception and transmission of 248 ARP requests/responses or IP datagrams. An IP-capable node SHALL fulfill 249 the following minimum requirements: 251 - it SHALL implement configuration ROM in the general format 252 specified by ISO/IEC 13213:1994 and SHALL implement the bus 253 information block specified by IEEE P1394a and a unit directory 254 specified by this standard; 256 - the max_rec field in its bus information block SHALL be at least 8; 257 this indicates an ability to accept block write requests and 258 asynchronous stream packets with data payload of 512 octets. The 259 same ability SHALL also apply to read requests; that is, the node 260 SHALL be able to transmit a block response packet with a data 261 payload of 512 octets; 263 - it SHALL be isochronous resource manager capable, as specified by 264 IEEE Std 1394-1995; 266 - it SHALL support both reception and transmission of asynchronous 267 streams as specified by IEEE P1394a; 269 - it SHALL implement the BROADCAST_CHANNEL register as specified by 270 IEEE P1394a; and 272 - it SHALL be broadcast channel manager (BCM) capable as specified by 273 IEEE P1394a. 275 4. LINK ENCAPSULATION AND FRAGMENTATION 277 All IP datagrams (broadcast, unicast or multicast), ARP 278 requests/responses and MCAP advertisements/solicitations that are 279 transferred via 1394 block write requests or stream packets SHALL be 280 encapsulated within the packet's data payload. The maximum size of data 281 payload, in octets, is constrained by the speed at which the packet is 282 transmitted. 284 Table 1 - Maximum data payloads (octets) 286 Speed Asynchronous Isochronous 287 +------------------------------------+ 288 | S100 | 512 | 1024 | 289 | S200 | 1024 | 2048 | 290 | S400 | 2048 | 4096 | 291 | S800 | 4096 | 8192 | 292 | S1600 | 8192 | 16384 | 293 | S3200 | 16384 | 32768 | 294 +------------------------------------+ 296 NOTE: The maximum data payloads at speeds of S800 and faster MAY be 297 reduced (but will not be increased) as a result of standardization by 298 IEEE P1394b. 300 The maximum data payload for asynchronous requests and responses MAY 301 also be restricted by the capabilities of the sending or receiving 302 node(s); this is specified by max_rec in either the bus information 303 block or ARP response. 305 For either of these reasons, the maximum data payload transmissible 306 between IP-capable nodes MAY be less than the 1500 octet maximum 307 transmission unit (MTU) specified by this document. This requires that 308 the encapsulation format also permit 1394 link-level fragmentation and 309 reassembly of IP datagrams. 311 4.1 Global asynchronous stream packet (GASP) format 313 Some IP datagrams, as well as ARP requests and responses, MAY be 314 transported via asynchronous stream packets. When asynchronous stream 315 packets are used, their format SHALL conform to the global asynchronous 316 stream packet (GASP) format specified by IEEE P1394a. The GASP format 317 illustrated below is INFORMATIVE and reproduced for ease of reference, 318 only. 320 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | data_length |tag| channel | 0x0A | sy | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | header_CRC | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | source_ID | specifier_ID_hi | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |specifier_ID_lo| version | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 +--- data ---+ 333 | | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | data_CRC | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 1 - GASP format 340 The source_ID field SHALL specify the node ID of the sending node and 341 SHALL be equal to the most significant 16 bits of the sender�s NODE_IDS 342 register. 344 The specifier_ID_hi and specifier_ID_lo fields together SHALL contain 345 the value 0x00005E, the 24-bit organizationally unique identifier (OUI) 346 assigned by the IEEE Registration Authority (RA) to IANA. 348 The version field SHALL be zero. 350 NOTE: Because the GASP format utilizes the first two quadlets of data 351 payload in an asynchronous stream packet format, the maximum payloads 352 cited in Table 1 are effectively reduced by eight octets. In the clauses 353 that follow, references to the first quadlet of data payload mean the 354 first quadlet usable for an IP datagram or ARP request or response. When 355 the GASP format is used, this is the third quadlet of the data payload 356 for the packet. 358 4.2 Encapsulation header 360 All IP datagrams transported over 1394 are prefixed by an encapsulation 361 header with one of the formats illustrated below. 363 If an entire IP datagram MAY be transmitted within a single 1394 packet, 364 it is unfragmented and the first quadlet of the data payload SHALL 365 conform to the format illustrated below. 367 1 2 3 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | lf| reserved | ether_type | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 2 - Unfragmented encapsulation header format 374 The lf field SHALL be zero. 376 The ether_type field SHALL indicate the nature of the datagram that 377 follows, as specified by the following table. 379 ether_type Datagram 380 +-----------------------+ 381 | 0x800 | IPv4 | 382 | 0x806 | ARP | 383 | 0x8861 | MCAP | 384 +-----------------------+ 386 NOTE: Other network protocols, identified by different values of 387 ether_type, MAY use the encapsulation formats defined herein but such 388 use is outside of the scope of this document. 390 In cases where the length of the datagram exceeds the maximum data 391 payload supported by the sender and all recipients, the datagram SHALL 392 be broken into link fragments; the first two quadlets of the data 393 payload for the first link fragment SHALL conform to the format shown 394 below. 396 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | lf|rsv| buffer_size | ether_type | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | dgl | reserved | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 Figure 3 - First fragment encapsulation header format 406 The second and subsequent link fragments (up to and including the last) 407 SHALL conform to the format shown below. 409 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | lf|rsv| buffer_size | rsv | fragment_offset | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | dgl | reserved | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 4 - Subsequent fragment(s) encapsulation header format 419 The definition and usage of the fields is as follows: 421 The lf field SHALL specify the relative position of the link fragment 422 within the IP datagram, as encoded by the following table. 424 lf Position 425 +------------------------+ 426 | 0 | Unfragmented | 427 | 1 | First | 428 | 2 | Last | 429 | 3 | Interior | 430 +------------------------+ 432 buffer_size: The size of the buffer, expressed as buffer_size + 1 433 octets, necessary for the recipient to reassemble the entire IP 434 datagram from all of the link fragments. The value of buffer_size 435 SHALL be the same for all link fragments of an IP datagram. 437 ether_type: This field is present only in the first link fragment and 438 SHALL have a value of 0x800, which indicates an IPv4 datagram. 440 fragment_offset: This field is present only in the second and 441 subsequent link fragments and SHALL specify the offset, in octets, of 442 the fragment from the beginning of the IP datagram. The first octet 443 of the datagram (the start of the IP header) has an offset of zero; 444 the implicit value of fragment_offset in the first link fragment is 445 zero. 447 dgl: The value of dgl (datagram label) SHALL be the same for all link 448 fragments of an IP datagram. The sender SHALL increment dgl for 449 successive, fragmented datagrams; the incremented value of dgl SHALL 450 wrap from 65,535 back to zero. 452 All IP datagrams, regardless of the mode of transmission (block write 453 requests or stream packets) SHALL be preceded by one of the above 454 described encapsulation headers. This permits uniform software treatment 455 of datagrams without regard to the mode of their transmission. 457 4.3 Link fragment reassembly 459 The recipient of an IP datagram transmitted via more than one 1394 460 packet SHALL use both the sender's source_ID (obtained from either the 461 asynchronous packet header or the GASP header) and dgl to identify all 462 the link fragments from a single datagram. 464 Upon receipt of a link fragment, the recipient MAY place the data 465 payload (absent the encapsulation header) within an IP datagram 466 reassembly buffer at the location specified by fragment_offset. The size 467 of the reassembly buffer MAY be determined from buffer_size. 469 If a link fragment is received that overlaps another fragment identified 470 by the same source_ID and dgl, the fragment(s) already accumulated in 471 the reassembly buffer SHALL be discarded. A fresh reassembly MAY be 472 commenced with the most recently received link fragment. Fragment 473 overlap is determined by the combination of fragment_offset from the 474 encapsulation header and data_length from the 1394 packet header. 476 Upon detection of a Serial Bus reset, recipient(s) SHALL discard all 477 link fragments of all partially reassembled IP datagrams and sender(s) 478 SHALL discard all not yet transmitted link fragments of all partially 479 transmitted IP datagrams. 481 5. ADDRESS RESOLUTION PROTOCOL (ARP) 483 ARP requests SHALL be transmitted by the same means as broadcast IP 484 datagrams; ARP responses MAY be transmitted in the same way or they MAY 485 be transmitted as block write requests addressed to the 486 sender_unicast_FIFO address identified by the ARP request. An ARP 487 request/response is 32 octets and SHALL conform to the format 488 illustrated by Figure 5. 490 1 2 3 491 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 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | hardware_type (0x0018) | protocol_type (0x0800) | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | hw_addr_len | IP_addr_len | opcode | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 +--- sender_unique_ID ---+ 499 | | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | sender_max_rec| sspd | sender_unicast_FIFO_hi | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | sender_unicast_FIFO_lo | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | sender_IP_address | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | target_IP_address | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 Figure 5 - ARP request/response format 512 ARP requests and responses transported by asynchronous stream packets 513 SHALL be encapsulated within the GASP format specified by IEEE P1394a 514 (see also 4.1). The recipient of an ARP request or response SHALL ignore 515 it unless the most significant ten bits of the source_ID field (whether 516 obtained from the GASP header of an asynchronous stream packet or the 517 packet header of a block write request) are equal to either 0x3FF or the 518 most significant ten bits of the recipient�s NODE_IDS register. 520 Field usage in an ARP request/response is as follows: 522 hardware_type: This field indicates 1394 and SHALL have a value of 523 0x0018. 525 protocol_type: This field SHALL have a value of 0x0800; this 526 indicates that the protocol addresses in the ARP request/response 527 conform to the format for IP addresses. 529 hw_addr_len: This field indicates the size, in octets, of the 530 1394-dependent hardware address associated with an IP address and 531 SHALL have a value of 16. 533 IP_addr_len: This field indicates the size, in octets, of an IP 534 version 4 (IPv4) address and SHALL have a value of 4. 536 opcode: This field SHALL be one to indicate an ARP request and two to 537 indicate an ARP response. 539 sender_unique_ID: This field SHALL contain the node unique ID of the 540 sender and SHALL be equal to that specified in the sender's bus 541 information block. 543 sender_max_rec: This field SHALL be equal to the value of max_rec in 544 the sender�s configuration ROM bus information block. 546 sspd: This field SHALL be set to the lesser of the sender�s link 547 speed and PHY speed. The link speed is the maximum speed at which the 548 link MAY send or receive packets; the PHY speed is the maximum speed 549 at which the PHY MAY send, receive or repeat packets. The table below 550 specifies the encoding used for sspd; all values NOT specified are 551 RESERVED. 553 Table 2 - Speed codes 555 Value Speed 556 +---------------+ 557 | 0 | S100 | 558 | 1 | S200 | 559 | 2 | S400 | 560 | 3 | S800 | 561 | 4 | S1600 | 562 | 5 | S3200 | 563 +---------------+ 565 sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields 566 together SHALL specify the 48-bit offset of the sender's FIFO 567 available for the receipt of IP datagrams in the format specified by 568 section 6. The offset of a sender's unicast FIFO SHALL NOT change, 569 except as the result of a power reset. 571 sender_IP_address: This field SHALL specify the IP address of the 572 sender. 574 target_IP_address: In an ARP request, this field SHALL specify the IP 575 address from which the sender desires a response. In an ARP response, 576 it SHALL be IGNORED. 578 6. CONFIGURATION ROM 580 Configuration ROM for IP-capable nodes SHALL contain a unit directory in 581 the format specified by this standard. The unit directory SHALL contain 582 Unit_Spec_ID and Unit_SW_Version entries, as specified by ISO/IEC 583 13213:1994. 585 The unit directory MAY also contain other entries permitted by ISO/IEC 586 13213:1994 or IEEE P1212r. 588 6.1 Unit_Spec_ID entry 590 The Unit_Spec_ID entry is an immediate entry in the unit directory that 591 specifies the organization responsible for the architectural definition 592 of the Internet Protocol capabilities of the device. 594 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | 0x12 | unit_spec_ID (0x00005E) | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 Figure 6 - Unit_Spec_ID entry format 602 0x12 is the concatenation of key_type and key_value for the Unit_Spec_ID 603 entry. 605 The value of unit_spec_ID SHALL be 0x00005E, the registration ID (RID) 606 obtained by IANA from the IEEE RA. The value indicates that IANA and its 607 technical committees are responsible for the maintenance of this 608 standard. 610 6.2 Unit_SW_Version entry 612 The Unit_SW_Version entry is an immediate entry in the unit directory 613 that, in combination with the unit_spec_ID, specifies the document that 614 defines the software interface of the unit. 616 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | 0x13 | unit_sw_version | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 Figure 7 - Unit_SW_Version entry format 624 0x13 is the concatenation of key_type and key_value for the 625 Unit_SW_Version entry. 627 A value for unit_sw_version is NOT yet specified. When this standard is 628 approved it is EXPECTED that unit_sw_version will assume the value of 629 the RFC number assigned at that time. This assignment algorithm for 630 unit_sw_version (or a similar method ratified by IANA) permits the 631 unique identification of future standards that MAY define, for example, 632 IPv6 or extensions to the IPv4 protocol that operate across Serial Bus 633 bridges. 635 6.3 Textual descriptors 637 Textual descriptors within configuration ROM are OPTIONAL; when present 638 they provide additional descriptive information intended to be 639 intelligible to a human user. IP-capable nodes SHOULD associate a 640 textual descriptor with a content of "IANA" with the Unit_Spec_ID entry 641 and a textual descriptor with a content of "IPv4" for the 642 Unit_SW_Version entry. 644 The figure below illustrates a unit directory implemented by an 645 IP-capable node; it includes OPTIONAL textual descriptors. Although the 646 textual descriptor leaves are NOT part of the unit directory, for the 647 sake of simplicity they are shown immediately following the unit 648 directory. 650 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | directory_length (4) | CRC | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | 0x12 | unit_spec_ID (0x00005E) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | 0x81 | textual descriptor offset (3) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | 0x13 | unit_sw_version | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | 0x81 | textual descriptor offset (5) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | textual_descriptor_length (3) | CRC | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | | 666 +--- zeros ---+ 667 | | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | "I" | "A" | "N" | "A" | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | textual_descriptor_length (3) | CRC | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 +--- zeros ---+ 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | "I" | "P" | "v" | "4" | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Figure 9 � Sample unit directory and textual descriptors 682 7. IP UNICAST 684 A unicast IP datagram MAY be transmitted to a recipient within a 1394 685 primary packet that has one of the following transaction codes: 687 tcode Description Arbitration 688 +--------------------------------------+ 689 | 0x01 | Block write | Asynchronous | 690 | 0x0A | Stream packet | Isochronous | 691 | 0x0A | Stream packet | Asynchronous | 692 +--------------------------------------+ 693 Block write requests are suitable when 1394 link-level acknowledgement 694 is desired but there is no need for bounded latency in the delivery of 695 the packet (quality of service). 697 Isochronous stream packets provide quality of service guarantees but no 698 1394 link-level acknowledgement. 700 The last method, asynchronous stream packets, is mentioned only for the 701 sake of completeness. This method SHOULD NOT be used for IP unicast, 702 since it provides for neither 1394 link-level acknowledgment nor quality 703 of service---and consumes a valuable resource, a channel number. 705 Regardless of the IP unicast method employed, asynchronous or 706 isochronous, it is the responsibility of the sender of a unicast IP 707 datagram to determine the maximum data payload that MAY be used in each 708 packet. The necessary information MAY be obtained from: 710 - the SPEED_MAP maintained by the 1394 bus manager, which provides 711 the maximum transmission speed between any two nodes on the local 712 Serial Bus. The bus manager analyzes bus topology in order to 713 construct the speed map; the maximum transmission speed between 714 nodes reflects the capabilities of the intervening nodes. The 715 speed in turn implies a maximum data payload (see Table 1); 717 - the target_max_rec field in an ARP response. This document requires 718 a minimum value of 8 (equivalent to a data payload of 512 octets). 719 Nodes that operate at S200 and faster are encouraged but NOT 720 REQUIRED to implement correspondingly larger values for 721 target_max_rec; or 723 - other methods beyond the scope of this standard. 725 The maximum data payload SHALL be the minimum of the largest data 726 payload implemented by the sender, the recipient and the PHYs of all 727 intervening nodes (the last is implicit in the SPEED_MAP entry indexed 728 by sender and recipient). 730 NOTE: The SPEED_MAP is derived from the self-ID packets transmitted by 731 all 1394 nodes subsequent to a bus reset. An IP-capable node MAY observe 732 the self-ID packets directly. 734 7.1 Asynchronous IP unicast 736 Unicast IP datagrams that do NOT require any quality of service SHALL be 737 contained within the data payload of 1394 block write transactions 738 addressed to the source_ID and sender_unicast_FIFO obtained from an ARP 739 response. 741 If no acknowledgement is received in response to a unicast block write 742 request the state of the target is ambiguous. 744 NOTE: An acknowledgment MAY be absent because the target is no longer 745 functional, MAY NOT have received the packet because of a header CRC 746 error or MAY have received the packet successfully but the acknowledge 747 sent in response was corrupted. 749 7.2 Isochronous IP unicast 751 Unicast IP datagrams that require quality of service SHALL be contained 752 within the data payload of 1394 isochronous stream packets. 753 The details of coordination between nodes with respect to allocation of 754 channel number(s) and bandwidth are beyond the scope of this standard. 756 8. IP BROADCAST 758 Broadcast IP datagrams are encapsulated according to the specifications 759 of section 4 and are transported by asynchronous stream packets. There 760 is no quality of service provision for IP broadcast over 1394. The 761 channel number used for IP broadcast is specified by the 762 BROADCAST_CHANNEL register. 764 All broadcast IP datagrams SHALL use asynchronous stream packets whose 765 channel number is equal to the channel field from the BROADCAST_CHANNEL 766 register. 768 Although 1394 permits the use of previously allocated channel number(s) 769 for up to one second subsequent to a bus reset, IP-capable nodes SHALL 770 NOT transmit asynchronous stream packets at any time the valid bit in 771 their BROADCAST_CHANNEL register is zero. Since the valid bit is 772 automatically cleared to zero by a bus reset, this prohibits the use of 773 ARP or broadcast IP until the BCM allocates a channel number. 775 9. IP MULTICAST 777 Multicast IP datagrams are encapsulated according to the specifications 778 of section 4 and are transported by stream packets. Asynchronous streams 779 are used for best-effort IP multicast while isochronous streams are used 780 for IP multicast that requires quality of service. 782 CAUTION: This document does not define facilities and methods for the 783 provision of quality of service for IP multicast. 785 By default, all best-effort IP multicast SHALL use asynchronous stream 786 packets whose channel number is equal to the channel field from the 787 BROADCAST_CHANNEL register. In particular, datagrams addressed to 788 224.0.0.1 and 224.0.0.2 SHALL use this channel number. Best-effort IP 789 multicast for other multicast group addresses MAY utilize a different 790 channel number if such a channel number is allocated and advertised 791 prior to use, as described below. 793 IP-capable nodes MAY transmit best-effort IP multicast only if one of 794 the following two conditions is met: 796 - the channel number in the stream packet is equal to the channel 797 number field in the BROADCAST_CHANNEL register and the valid bit in 798 the same register is one; or 799 - for other channel number(s), some source of IP multicast has 800 allocated and is advertising the channel number used. 802 The remainder of this section describes a multicast channel allocation 803 protocol (MCAP) employed by both IP multicast sources and recipients 804 whenever a channel number other than the default is used. MCAP is a 805 cooperative protocol; the participants exchange messages over the 806 broadcast channel used by all IP-capable nodes on a particular Serial 807 Bus. 809 CAUTION: This document does not define facilities and methods for shared 810 use of a single channel number (other than the default channel number 811 specified by the BROADCAST_CHANNEL register) by more than one IP 812 multicast address. 814 9.1 MCAP message format 816 MCAP messages, whether sent by a multicast channel owner or recipient, 817 have the format illustrated below. The first four octets of the message 818 are fixed; the remainder consists of variable-length tuples, each of 819 which encodes information about a particular multicast group. Individual 820 MCAP messages SHALL NOT be fragmented and SHALL be encapsulated within a 821 stream packet as ether_type 0x8861. 823 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | length | reserved | opcode | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | | 829 + message data + 830 | | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 Figure 10 - MCAP message format 835 Field usage in an MCAP message is as follows: 837 length: This field SHALL contain the size, in octets, of the entire 838 MCAP message. 840 opcode: This field SHALL have one of the values specified by the 841 table below. 843 opcode Name Comment 844 +----------------------------------------------------------------+ 845 | 0 | Advertise | Sent by a multicast channel owner to | 846 | | | broadcast the current mapping(s) from one | 847 | | | or more group addresses to their | 848 | | | corresponding channel number(s). | 849 | 1 | Solicit | Sent to request multicast channel owner(s) | 850 | | | to advertise the indicated channel | 851 | | | mapping(s) as soon as possible. | 852 +----------------------------------------------------------------+ 853 message data: The remainder of the MCAP message is variable in length 854 and SHALL consist of zero or more group address descriptors with the 855 format illustrated below. 857 1 2 3 858 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 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | length | type | reserved | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | expiration | channel | speed | reserved | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | bandwidth | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | 867 + group_address + 868 | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 11 - MCAP group address descriptor format 873 length: This field SHALL contain the size, in octets, of the MCAP 874 group address descriptor. 876 type: This field SHALL have a value of one, which indicates a group 877 address descriptor. 879 expiration: The usage of this field varies according to opcode. For 880 solicit messages the expiration field SHALL be IGNORED. Otherwise, 881 for advertisements, this field SHALL contain a time-stamp, in 882 seconds, that specifies a future time after which the channel number 883 specified by channel MAY no longer be used. 885 channel: This field is valid only for advertise messages, in which 886 case it SHALL specify an allocated channel number, in the range zero 887 to 63 inclusive. All other values are RESERVED. 889 speed: This field is valid only for advertise messages, in which case 890 it SHALL specify the speed at which stream packets for the indicated 891 channel are transmitted. Table 2 specifies the encoding used for 892 speed. 894 bandwidth: This field SHALL be zero; it is allocated in the group 895 address descriptor to accommodate future extensions to MCAP that 896 specify quality of service and utilize the isochronous capabilities 897 of Serial Bus. 899 group_address: This variable length field SHALL specify the IP 900 address of a particular multicast group. The length of group_address, 901 in octets, is derived from the length of the group address descriptor 902 by subtracting 12 from the length field. 904 9.2 MCAP message domain 906 MCAP messages carry information valid only for the local Serial Bus on 907 which they are transmitted. Recipients of MCAP messages SHALL IGNORE all 908 MCAP messages from other than the local bus, as follows. The source_ID 909 of the sender is contained in the GASP header that precedes the 910 encapsulated MCAP message. A recipient of an MCAP message SHALL examine 911 the most significant ten bits of source_ID from the GASP header; if they 912 are NOT equal to either 0x3FF or the most significant ten bits of the 913 recipient's NODE_IDS register, the recipient SHALL IGNORE the message. 915 Within an MCAP message domain, the owner of a channel mapping is 916 identified by the source_ID field in the GASP header of an MCAP 917 advertisement. The owner is the node with the largest physical ID, the 918 least significant six bits of source_ID. 920 9.3 Multicast receive 922 An IP-capable device that wishes to receive multicast data SHALL first 923 ascertain the channel mapping (if any) that exists between a group 924 address and a channel number other than the default channel specified by 925 the BROADCAST_CHANNEL register. Such a device MAY observe the MCAP 926 advertisements on the broadcast channel for the desired channel 927 mapping(s). 929 An intended multicast recipient MAY transmit MCAP solicitation requests 930 in order to request multicast channel owner(s) to broadcast 931 advertisements sooner than the next ten second interval. Originators of 932 MCAP solicitation requests SHALL limit the rate at which they are 933 transmitted. Subsequent to sending a solicitation request, the 934 originator SHALL NOT send another MCAP solicitation request until ten 935 seconds have elapsed. 937 In either case, if a mapping exists for the group address for other than 938 the default channel, an MCAP advertise message is EXPECTED within ten 939 seconds. Upon receipt of an MCAP advertise message that describes one or 940 more channel mappings, the intended multicast recipient MAY receive IP 941 datagrams on the indicated channel number(s) until the expiration time. 943 If multiple MCAP advertise messages are observed that specify the same 944 group address, the channel number SHALL be obtained from the 945 advertisement message with the largest physical ID, which SHALL be 946 obtained from the least significant six bits of source_ID from the GASP 947 header. 949 If no MCAP advertise message is received for a particular group address 950 within ten seconds, no multicast source(s) are active for channel(s) 951 other than the default. Either there is there is no multicast data or it 952 is being transmitted on the default channel. 954 Once a multicast recipient has observed an advertisement for the desired 955 group address, it SHALL continue to monitor the broadcast channel for 956 MCAP advertisements for the same group address in order to refresh the 957 expiration time of channel number(s) in use. 959 9.4 Multicast transmit 961 An IP-capable device that wishes to transmit multicast data on other 962 than the default channel SHALL first ascertain whether or NOT another 963 multicast source has already allocated a channel number for the group 964 address. The intended multicast source MAY transmit an MCAP solicitation 965 request with one or more group address descriptors. 967 Whether or NOT a solicitation request has been transmitted, the intended 968 multicast source SHALL monitor the broadcast channel for MCAP 969 advertisements. If a channel mapping already exists for the group 970 address, an MCAP advertisement SHOULD be received within ten seconds. In 971 this case the intended multicast source MAY commence transmission of IP 972 datagrams on the indicated channel number(s) and MAY continue to do so 973 until their expiration time. The multicast source SHALL monitor MCAP 974 advertisements in order to refresh the expiration time of channel 975 number(s) in use. 977 When no other multicast source has established a channel mapping for the 978 group address, the intended multicast source MAY attempt to allocate a 979 channel number from the isochronous resource manager's 980 CHANNELS_AVAILABLE register according to the procedures described in 981 IEEE P1394a. If the channel number allocation is successful, the 982 multicast source SHALL advertise the new channel mapping(s) as soon as 983 possible; once such advertisement has been made, the multicast source 984 MAY transmit IP datagrams using the channel number obtained. 986 Multicast IP datagrams MAY be transmitted on the default channel until 987 the sender observes (or transmits) an advertisement that specifies non- 988 default channel mapping(s) for the multicast addresses. This permits the 989 smooth transition of multicast from the default channel to an explicitly 990 allocated channel. 992 Once a multicast source has advertised a channel mapping, it SHALL 993 continue to transmit MCAP advertisements for the channel mapping unless 994 it either a) transfers ownership to another multicast source, b) permits 995 the channel mapping to expire without transfer or c) in the case of 996 overlapped channel mappings, relinquishes control of the channel mapping 997 to another multicast source. 999 9.5 Advertisement of channel mappings 1001 Each multicast source SHALL periodically broadcast an advertisement of 1002 all multicast group addresses for which it has allocated a channel 1003 number different from the default multicast channel number. An 1004 advertisement SHALL consist of a single MCAP message with an opcode of 1005 zero that contains one or more group address descriptors (one for each 1006 group address assigned a channel number other than that specified by the 1007 BROADCAST_CHANNEL register). 1009 Within each group address descriptor, the group_address and channel 1010 fields associate a multicast group address with a Serial Bus channel 1011 number. The speed field specifies the maximum 1394 speed at which any of 1012 the senders within the multicast group is permitted to transmit data. 1013 The expiration field specifies the current time or a future time after 1014 which the channel mapping(s) are no longer valid. Except when a channel 1015 owner intends to relinquish ownership (as described in 9.7 below), the 1016 expiration time SHALL be at least 60 seconds in the future measured from 1017 the time the advertisement is transmitted. 1019 No more than ten seconds SHALL elapse from the transmission of its most 1020 recent advertisement before the owner of a channel mapping initiates 1021 transmission of the subsequent advertisement. The owner of a channel 1022 mapping SHOULD transmit an MCAP advertisement in response to a 1023 solicitation as soon as possible after the receipt of the request. 1025 9.6 Overlapped channel mappings 1027 When two intended multicast sources wish to transmit to the same 1028 multicast group and no channel mapping exists for the group address, 1029 there is a chance that both will allocate channel numbers and both will 1030 advertise the channel mappings. These channel mappings overlap, i.e., 1031 the same group address is mapped to more than one channel number in MCAP 1032 advertisements with nonzero expiration times. 1034 Multicast channel owners SHALL monitor MCAP advertisements in order to 1035 detect overlapped channel mappings. When an overlapped channel mapping 1036 is detected, the owner with the largest physical ID (as determined by 1037 the least significant six bits of source_ID from the GASP header) is NOT 1038 REQUIRED to take any action. The owner(s) with smaller physical IDs 1039 SHALL cease transmission of MCAP advertisements for the overlapped 1040 channel number. As soon as these channel mapping(s) are no longer valid, 1041 their owners SHALL deallocate any unused channel numbers as described in 1042 9.8 below. 1044 Recipients of MCAP advertisements that detect overlapped channel 1045 mappings SHALL ignore the advertisements from multicast channel owner(s) 1046 with the smaller physical IDs. It is possible for some channel mappings 1047 in a single MCAP advertisement to be valid even if others SHALL be 1048 IGNORED as a result of overlap. 1050 9.7 Transfer of channel ownership 1052 The owner of a channel mapping MAY cease multicast transmission on a 1053 particular channel, in which case it SHOULD invalidate the channel 1054 mapping and in some cases deallocate the channel number. Because other 1055 multicast sources MAY be using the same channel mapping, an orderly 1056 process is defined to transfer channel ownership. 1058 The owner of an existing channel mapping that wishes to release the 1059 mapping SHALL commence a timer to measure the time remaining before the 1060 anticipated release of the mapping and its associated channel. Until the 1061 timer counts down to zero, the owner SHOULD continue to transmit MCAP 1062 advertisements for the affected channel but SHALL adjust expiration in 1063 each advertisement to reflect the time remaining until the channel is to 1064 be deallocated. If the owner is unable to transmit MCAP advertisements 1065 until the timer reaches zero, it SHALL initiate a bus reset. Otherwise, 1066 the sequence of expiration times transmitted by the owner intending to 1067 release the mapping SHALL decrease with each succeeding advertisement. 1068 If other multicast source(s) are using the same channel mapping and 1069 observe an expiration time less than or equal to 30 seconds, they SHALL 1070 commence transmitting MCAP advertisements for the channel mapping with 1071 refreshed expiration times greater than or equal to 30 seconds that 1072 maintain the channel mapping. Any contention that occurs between 1073 multiple sources that attempt to claim ownership of the channel mapping 1074 SHALL be resolved as described in 9.6. If the original owner observes an 1075 MCAP advertisement for the channel to be relinquished before its own 1076 timer has expired, it SHALL NOT deallocate the channel number. 1078 Otherwise, if the owner's timer expires without the observation of a 1079 MCAP advertisement by another node, the owner of the channel number 1080 SHALL subsequently deallocate the channel as described in 9.8. If the 1081 intended owner of the channel mapping observes an MCAP advertisement 1082 whose expiration field is zero, orderly transfer of the channel(s) from 1083 the former owner has failed. The intended owner SHALL either stop 1084 reception and transmission on the expired channel number(s) or allocate 1085 different channel number(s) as specified by 9.4. 1087 9.8 Expired channel mappings 1089 A channel mapping expires when expiration seconds have elapsed since the 1090 most recent MCAP advertisement. At this time, multicast recipients SHALL 1091 stop reception on the expired channel number(s). Also at this time, the 1092 owner of the channel mapping(s) SHALL transmit an MCAP advertisement 1093 with expiration cleared to zero and SHALL continue to transmit such 1094 advertisements until 30 seconds have elapsed since the expiration of the 1095 channel mapping. Once this additional 30-second period has elapsed, the 1096 owner of the channel mapping(s) SHALL deallocate the channel number(s) 1097 and indicate their availability in the isochronous resource manager's 1098 CHANNELS_AVAILABLE register. 1100 If an IP-capable device observes an MCAP advertisement whose expiration 1101 field is zero, it SHALL NOT attempt to allocate any of the channel 1102 number(s) specified until 30 seconds have elapsed since the most recent 1103 such advertisement. 1105 9.9 Bus reset 1107 A bus reset SHALL invalidate all multicast channel mappings and SHALL 1108 cause all multicast recipients and senders to zero all MCAP 1109 advertisement interval timers. 1111 Prior owners of multicast channel mappings MAY reallocate a channel 1112 number from the isochronous resource manager's CHANNELS_AVAILABLE 1113 register and resume broadcast of MCAP advertisements as soon as a 1114 channel is allocated. If channel reallocation is attempted, the prior 1115 owner SHOULD use the same channel number allocated prior to the bus 1116 reset and MAY commence reallocation immediately upon completion of the 1117 bus reset so long as the same channel number is reused. If the prior 1118 owner elects to allocate a different channel number, it SHALL wait until 1119 at least one second has elapsed since the completion of the bus reset 1120 before attempting to allocate a new channel number. 1122 Intended or prior recipients or transmitters of multicast on other than 1123 the default channel SHALL NOT transmit MCAP solicitation requests until 1124 at least ten seconds have elapsed since the completion of the bus reset. 1125 Multicast data on other than the default channel SHALL NOT be received 1126 or transmitted until an MCAP advertisement is observed or transmitted 1127 for the multicast group address. 1129 Intended or prior transmitters of multicast on other than the default 1130 channel that did not own a channel mapping for the multicast group 1131 address prior to the bus reset SHALL NOT attempt to allocate a channel 1132 number from the isochronous resource manager's CHANNELS_AVAILABLE 1133 register until at least ten seconds have elapsed since the completion of 1134 the bus reset. Subsequent to this ten second delay, intended or prior 1135 transmitters of multicast MAY follow the procedures specified by 9.4 to 1136 allocate a channel number and advertise the channel mapping. 1138 10. IANA CONSIDERATIONS 1140 This document is likely the first that necessitates the creation and 1141 management of a new name space (registry) by IANA. The need for such a 1142 registry arises out of the method by which protocol interfaces are 1143 uniquely identified by bus standards compliant with ISO/IEC 13213:1994, 1144 CSR Architecture. This is explained in more detail in section 6; the 1145 essence is that a globally unique 48-bit number SHALL identify the 1146 document that specifies the protocol interface. The 48-bit number is the 1147 concatenation of a 24-bit number granted to IANA by the IEEE 1148 Registration Authority (referred to as a registration ID, or RID) and a 1149 second 24-bit number administered by IANA. 1151 The IEEE RA RECOMMENDS that the policy for management of the second 1152 24-bit number be chosen to maximize the quantity of usable numbers with 1153 the range of possible values. By way of a concrete example, the IEEE RA 1154 RECOMMENDS that the assignment scheme NOT apply a structure to the 1155 number since this would tend to waste large portions of the range. 1157 In accordance with this guidance, this document suggests that the RFC 1158 number of this document be assigned as the version number (the second 1159 24-bit number) and that this same method be used to assign version 1160 numbers to future standards. Requests for version numbers other than RFC 1161 numbers should be refereed to a committee of experts selected by IANA. 1163 Regardless of the assignment method elected by IANA, a registry of all 1164 assigned version numbers SHOULD be maintained at one or more Internet 1165 sites and should clearly identify the relevant standard identified by 1166 the combination of the RID and version number. 1168 11. SECURITY CONSIDERATIONS 1170 This document specifies the use of an unsecured link layer, Serial Bus, 1171 for the transport of IPv4 datagrams. Serial Bus is vulnerable to denial 1172 of service attacks; it is also possible for devices to eavesdrop on data 1173 or present forged identities. Implementers who utilize Serial Bus for 1174 IPv4 SHOULD consider appropriate counter-measures within application or 1175 other layers. 1177 12. ACKNOWLEDGEMENTS 1179 This document represents work in progress by the IP/1394 Working Group. 1180 The editor wishes to acknowledge the contributions made by all the 1181 active participants, either on the reflector or at face-to-face 1182 meetings, which have advanced the technical content. 1184 13. REFERENCES 1186 Normative reference to standards under development at the time of this 1187 document�s publication shall utilize the most current draft until such 1188 time as it is replaced by an approved standard. 1190 [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus 1192 [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture 1193 for Microcomputer Buses 1195 [3] IEEE Project P1394a, Draft Standard for a High Performance Serial 1196 Bus (Supplement) 1198 [4] IEEE Project P1394b, Draft Standard for a High Performance Serial 1199 Bus (Supplement) 1201 14. EDITOR�S ADDRESS 1203 Peter Johansson 1204 Congruent Software, Inc. 1205 98 Colorado Avenue 1206 Berkeley, CA 94602 1208 (510) 527-3926 1209 (510) 527-3856 FAX 1210 pjohansson@aol.com