idnits 2.17.1 draft-ietf-ip1394-ipv4-12.txt: -(65): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(81): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(93): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(99): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(664): 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): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 9 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 23 longer pages, the longest (page 1) being 62 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 530 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == 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 13: '...hat other groups MAY also distribute w...' RFC 2119 keyword, line 17: '... and MAY be updated, replaced, or...' RFC 2119 keyword, line 112: '... packets MAY be either asynchrono...' RFC 2119 keyword, line 113: '...lementations and MAY range from one oc...' RFC 2119 keyword, line 134: '...re design models MAY also be implement...' (194 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 exact meaning of the all-uppercase expression 'NOT REQUIRED' 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: 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, IP datagrams or MCAP advertisements/solicitations; 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, IP datagrams or MCAP advertisements/solicitations; 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 an NPM has been elected but MAY NOT have allocated a channel. 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); == 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 1137, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1139, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1142, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1145, 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: 11 errors (**), 0 flaws (~~), 10 warnings (==), 8 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: May 1999 7 IPv4 over IEEE 1394 9 STATUS OF THIS DOCUMENT 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups MAY also distribute working 14 documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and MAY be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 To view the entire list of current Internet-Drafts, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 ABSTRACT 29 This document specifies how to use IEEE Std 1394-1995, Standard for a 30 High Performance Serial Bus (and its supplements), for the transport of 31 Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary 32 methods, data structures and codes for that purpose and additionally 33 defines a method for Address Resolution Protocol (ARP). 35 TABLE OF CONTENTS 37 1. INTRODUCTION.......................................................3 38 2. DEFINITIONS AND NOTATION...........................................4 39 2.1 Conformance....................................................4 40 2.2 Glossary.......................................................4 41 2.3 Abbreviations..................................................5 42 2.4 Numeric values.................................................5 43 3. IP-CAPABLE NODES...................................................6 44 4. NETWORK_CHANNELS REGISTER..........................................6 45 5. NETWORK PROTOCOL MANAGER (NPM).....................................7 46 6. LINK ENCAPSULATION AND FRAGMENTATION...............................9 47 6.1 Encapsulation header..........................................10 48 6.2 Link fragment reassembly......................................12 49 7. ADDRESS RESOLUTION PROTOCOL (ARP).................................12 50 8. IP UNICAST........................................................15 51 8.1 Asynchronous IP unicast.......................................16 52 8.2 Isochronous IP unicast........................................16 53 9. IP BROADCAST......................................................16 54 10. IP MULTICAST.....................................................17 55 10.1 MCAP Message Format..........................................17 56 10.2 Multicast receive............................................19 57 10.3 Multicast transmit...........................................20 58 10.4 Advertisement of channel mappings............................21 59 10.5 Overlapped channel mappings..................................21 60 10.6 Transfer of channel ownership................................22 61 10.7 Expired channel mappings.....................................22 62 11. SECURITY CONSIDERATIONS..........................................22 63 12. ACKNOWLEDGEMENTS.................................................23 64 13. REFERENCES.......................................................23 65 14. EDITOR�S ADDRESS.................................................23 66 1. INTRODUCTION 68 This document specifies how to use IEEE Std 1394-1995, Standard for a 69 High Performance Serial Bus (and its supplements), for the transport of 70 Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary 71 methods, data structures and codes for that purpose and additionally 72 defines a method for Address Resolution Protocol (ARP). 74 The group of IEEE standards and supplements, draft or approved, related 75 to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as 76 Serial Bus. 78 1394 is an interconnect (bus) that conforms to the CSR architecture, 79 ISO/IEC 13213:1994. Serial Bus permits communications between nodes over 80 shared physical media at speeds that range, at present, from 100 to 81 400 Mbps. Both consumer electronic applications (such as digital VCR�s, 82 stereo systems, televisions and camcorders) and traditional desktop 83 computer applications (e.g., mass storage, printers and tapes), have 84 adopted 1394. Serial Bus is unique in its relevance to both consumer 85 electronic and computer domains and is EXPECTED to form the basis of a 86 home or small office network that combines both types of devices. 88 The CSR architecture describes a memory-mapped address space that Serial 89 Bus implements as a 64-bit fixed addressing scheme. Within the address 90 space, ten bits are allocated for bus ID (up to a maximum of 1,023 91 buses), six are allocated for node physical ID (up to 63 per bus) while 92 the remaining 48 bits (offset) describe a per node address space of 256 93 terabytes. The CSR architecture, by convention, splits a node�s address 94 space into two regions with different behavioral characteristics. The 95 lower portion, up to but NOT including 0xFFFF F000 0000, is EXPECTED to 96 behave as memory in response to read and write transactions. The upper 97 portion is more like a traditional IO space: read and write transactions 98 in this area usually have side effects. Control and status registers 99 (CSR�s) that have FIFO behavior customarily are implemented in this 100 region. 102 Within the 64-bit address, the 16-bit node ID (bus ID and physical ID) 103 is analogous to a network hardware address---but 1394 node ID's are 104 variable and subject to reassignment each time one or more nodes are 105 added to or removed from the bus. 107 The 1394 link layer provides a packet delivery service with both 108 confirmed (acknowledged) and unconfirmed packets. Two levels of service 109 are available: "asynchronous" packets are sent on a best-effort basis 110 while "isochronous" packets are guaranteed to be delivered with bounded 111 latency. Confirmed packets are always asynchronous but unconfirmed 112 packets MAY be either asynchronous or isochronous. Data payloads vary 113 with implementations and MAY range from one octet up to a maximum 114 determined by the transmission speed (at 100 Mbps, named S100, the 115 maximum asynchronous data payload is 512 octets while at S400 it is 2048 116 octets). 118 NOTE: Extensions underway in IEEE P1394b contemplate additional speeds 119 of 800, 1600 and 3200 Mbps. 121 2. DEFINITIONS AND NOTATION 123 2.1 Conformance 125 When used in this document, the keywords "MAY", "OPTIONAL", 126 "RECOMMENDED", "REQUIRED", "SHALL" and "SHOULD" differentiate levels of 127 requirements and optionality and are to be interpreted as described in 128 RFC 2119. 130 Several additional keywords are employed, as follows: 132 EXPECTED: A keyword used to describe the behavior of the hardware or 133 software in the design models assumed by this standard. Other hardware 134 and software design models MAY also be implemented. 136 IGNORED: A keyword that describes bits, octets, quadlets or fields whose 137 values are NOT checked by the recipient. 139 RESERVED: A keyword used to describe objects---bits, octets, quadlets 140 and fields---or the code values assigned to these objects in cases where 141 either the object or the code value is set aside for future 142 standardization. Usage and interpretation MAY be specified by future 143 extensions to this or other standards. A RESERVED object SHALL be zeroed 144 or, upon development of a future standard, set to a value specified by 145 such a standard. The recipient of a RESERVED object SHALL NOT check its 146 value. The recipient of an object defined by this standard as other than 147 RESERVED SHALL check its value and reject RESERVED code values. 149 2.2 Glossary 151 The following terms are used in this standard: 153 address resolution protocol: A method for a requester to determine the 154 hardware (1394) address of an IP node from the IP address of the node. 156 bus ID: A 10-bit number that uniquely identifies a particular bus within 157 a group of multiple interconnected buses. The bus ID is the most 158 significant portion of a node's 16-bit node ID. The value 0x3FF 159 designates the local bus; a node SHALL respond to requests addressed to 160 its 6-bit physical ID if the bus ID in the request is either 0x3FF or 161 the bus ID explicitly assigned to the node. 163 encapsulation header: A structure that precedes all IP data transmitted 164 over 1394. See also link fragment. 166 IP datagram: An Internet message that conforms to the format specified 167 by RFC 791. 169 link fragment: A portion of an IP datagram transmitted within a single 170 1394 packet. The data payload of the 1394 packet contains both an 171 encapsulation header and its associated link fragment. It is possible to 172 transmit datagrams without link fragmentation. 174 multicast channel owner: A multicast source that has allocated a channel 175 for one or more multicast addresses and transmits MCAP advertisements to 176 communicate these channel mapping(s) to other participants in the 177 multicast group. When more than one source transmits MCAP advertisements 178 for the same channel number, the source with the largest physical ID is 179 the owner. 181 node ID: A 16-bit number that uniquely identifies a Serial Bus node 182 within a group of multiple interconnected buses. The most significant 10 183 bits are the bus ID and the least significant 6 bits are the physical 184 ID. 186 node unique ID: A 64-bit number that uniquely identifies a node among 187 all the Serial Bus nodes manufactured worldwide; also known as the 188 EUI-64 (Extended Unique Identifier, 64-bits). 190 octet: Eight bits of data. 192 packet: Any of the 1394 primary packets; these MAY be read, write or 193 lock requests (and their responses) or stream data. The term "packet" is 194 used consistently to differentiate 1394 packets from ARP 195 requests/responses, IP datagrams or MCAP advertisements/solicitations. 197 physical ID: On a particular bus, this 6-bit number is dynamically 198 assigned during the self-identification process and uniquely identifies 199 a node on that bus. 201 quadlet: Four octets, or 32 bits, of data. 203 stream packet: A 1394 primary packet with a transaction code of 0x0A 204 that contains a block data payload. Stream packets MAY be either 205 asynchronous or isochronous according to the type of 1394 arbitration 206 employed. 208 2.3 Abbreviations 210 The following are abbreviations that are used in this standard: 212 ARP Address resolution protocol 213 CSR Control and status register 214 CRC Cyclical redundancy checksum 215 EUI-64 Extended Unique Identifier, 64-bits 216 IP Internet protocol (within the context of this document, IPv4) 217 MCAP Multicast channel allocation protocol 219 2.4 Numeric values 221 Decimal and hexadecimal numbers are used within this standard. By 222 editorial convention, decimal numbers are most frequently used to 223 represent quantities or counts. Addresses are uniformly represented by 224 hexadecimal numbers. Hexadecimal numbers are also used when the value 225 represented has an underlying structure that is more apparent in a 226 hexadecimal format than in a decimal format. 228 Decimal numbers are represented by Arabic numerals or by their English 229 names. Hexadecimal numbers are prefixed by 0x and represented by digits 230 from the character set 0 � 9 and A � F. For the sake of legibility, 231 hexadecimal numbers are separated into groups of four digits separated 232 by spaces. 234 For example, both 42 and 0x2A represent the same numeric value. 236 3. IP-CAPABLE NODES 238 Not all 1394 devices are capable of the reception and transmission of 239 ARP requests/responses or IP datagrams. An IP-capable node SHALL fulfill 240 the following minimum requirements: 242 - it SHALL implement configuration ROM in the general format 243 specified by ISO/IEC 13213:1994 and SHALL implement the bus 244 information block specified by P1394a; 246 - the max_rec field in its bus information block SHALL be at least 8; 247 this indicates an ability to accept block write requests and 248 asynchronous stream packets with data payload of 512 octets. The 249 same ability SHALL also apply to read requests; that is, the node 250 SHALL be able to transmit a block response packet with a data 251 payload of 512 octets; 253 - it SHALL be isochronous resource manager capable, as specified by 254 1394; 256 - it SHALL support both reception and transmission of asynchronous 257 streams as specified by P1394a; 259 - it SHALL implement the NETWORK_CHANNELS register; and 261 - it SHALL be network protocol manager (NPM) capable. 263 4. NETWORK_CHANNELS REGISTER 265 This register is REQUIRED for IP-capable nodes. It SHALL be located at 266 offset 0xFFFF F000 0234 within the node's address space and SHALL 267 support quadlet read and write requests, only. The format of the 268 register is shown below. 270 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |1|v| npm_ID | reserved | channel | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1 - NETWORK_CHANNELS format 278 Upon a node power reset or a bus reset, the entire register (with the 279 exception of the most significant bit and the npm_ID field) SHALL be 280 cleared to zero; the npm_ID field SHALL be set to ones. 282 The most significant bit (a constant one) differentiates the presence of 283 the NETWORK_CHANNELS register in an IP-capable node from the value (all 284 zeros) possibly returned when offset 0xFFFF F000 0234 is read at node(s) 285 that do NOT implement this register. 287 NOTE: Nodes compliant with P1394a return an address error response when 288 unimplemented addresses are accessed---but some 1394 implementations are 289 known to return zeros. 291 The valid bit (abbreviated as v above), when set to one, indicates that 292 the channel field contains meaningful information. IP-capable nodes 293 SHALL NOT transmit stream packets that specify this channel while the 294 valid bit is zero. This includes (but is NOT limited to) ARP, broadcast 295 IP, default multicast and MCAP. 297 The npm_ID field identifies the physical ID of the network protocol 298 manager (NPM). When npm_ID is equal to 0x3F the physical ID of the NPM 299 is NOT specified; otherwise it SHALL be initialized (by the NPM) to the 300 6-bit physical ID assigned during the self-identification process. 302 The channel field SHALL be initialized by the NPM (see below) to 303 identify the channel number shared by IP-capable nodes for ARP, IP 304 broadcast, default multicast and MCAP. 306 Only the valid bit and the npm_ID and channel fields MAY be changed by 307 quadlet write requests; the data value in the write request SHALL be 308 IGNORED for all other bit positions. 310 5. NETWORK PROTOCOL MANAGER (NPM) 312 In order for ARP or broadcast IP to function on 1394, a prerequisite is 313 the presence of a network protocol manager (NPM). The domain of the NPM 314 is limited to the local Serial Bus; the functions of the NPM are as 315 follows: 317 - the allocation of a channel number for ARP and broadcast IP; and 319 - the communication of that channel number to all IP-capable nodes on 320 the same bus. 322 All IP-capable nodes SHALL be capable of functioning as the NPM. 324 Subsequent to a Serial Bus reset a single NPM SHALL be determined by a 325 distributed algorithm executed by all the NPM-capable nodes. The 326 algorithm is straightforward: the NPM-capable node with the largest 327 6-bit physical ID SHALL be the NPM. The steps in the algorithm are as 328 follows: 330 a) An NPM-capable node SHALL also be a contender for the role of 331 isochronous resource manager. The C (contender) and L (link active) 332 bits in its self-ID packet SHALL be set to one; 333 b) Subsequent to a bus reset, isochronous resource manager contention 334 takes place during the self-identification process specified by 335 1394; 336 c) An NPM-capable node that wins the contention process referenced in 337 b) is the NPM and SHALL proceed with g). Other NPM-capable node(s) 338 NOT selected as the isochronous resource manager (hereafter 339 referred to as candidates) SHALL continue with d); 340 d) A candidate NPM SHALL delay before it attempts to become the NPM. 341 The delay time SHALL be equal to 15 ms * (irm_ID - candidate_ID), 342 where irm_ID and candidate_ID are the physical ID�s of the 343 isochronous resource manager and the candidate NPM, respectively. 344 After the delay time has elapsed, the candidate NPM SHALL examine 345 the npm_ID field in its own NETWORK_CHANNELS register; if it is NOT 346 equal to 0x3F, another node is the NPM. The losing candidate SHALL 347 wait for the valid bit of its own register to be set before 348 transmitting any ARP requests/responses, IP datagrams or MCAP 349 advertisements/solicitations; 350 e) Otherwise, the candidate NPM SHALL attempt to read the 351 NETWORK_CHANNELS register of any contenders with a larger physical 352 ID (these nodes were identified by the C bit in their self-ID 353 packets). The candidate NPM SHALL read the NETWORK_CHANNELS 354 register in the contender with the largest physical ID and progress 355 downward. If the register is implemented, the NPM is determined to 356 be a different node. The losing candidate SHALL ignore the contents 357 of NETWORK_CHANNELS returned in the read response and SHALL wait 358 for the valid bit of its own register to be set before transmitting 359 any ARP requests/responses, IP datagrams or MCAP 360 advertisements/solicitations; 361 f) If no contender with a physical ID larger than the candidate NPM's 362 physical ID implements the NETWORK_CHANNELS register, the search is 363 complete and the candidate becomes the new NPM; 364 g) Once elected, the NPM SHALL update the npm_ID field in the 365 NETWORK_CHANNELS register of all the IP-capable nodes on the bus 366 (including itself) with its own physical ID. This signals to other 367 candidates that an NPM has been elected but MAY NOT have allocated 368 a channel. Either a broadcast write request or a series of write 369 requests addressed to individual nodes MAY be used; 370 h) The NPM SHALL attempt to allocate a channel number from the 371 CHANNELS_AVAILABLE register (note that the NPM MAY also be the 372 isochronous resource manager). If no channel number had been 373 allocated prior to the bus reset, the NPM SHALL wait one second 374 before it attempts to allocate a channel number. Otherwise, the NPM 375 SHALL attempt to reallocate the same channel number in use before 376 the bus reset; if the same channel number is NOT available, the NPM 377 MAY allocate a different channel number. If no channel number is 378 available, the NPM SHALL take no additional action (all valid 379 bit(s) were cleared by the bus reset); 381 NOTE: Parts of the preceding step are still under discussion within the 382 working group; there is as yet no consensus as to what time interval the 383 NPM SHALL wait (if any) before attempting to allocate a new channel 384 number if the previously allocated channel number is unavailable after a 385 bus reset. 387 i) Otherwise, the NPM SHALL update its own NETWORK_CHANNELS register 388 with the allocated channel number and set the valid bit to one. The 389 NPM SHALL then write the updated value of the entire register to 390 the NETWORK_CHANNELS register of all the IP-capable nodes on the 391 bus. Either a broadcast write request (with the most significant 10 392 bits of destination_ID equal to the most significant 10 bits of the 393 NPM's NODE_IDS register and the most significant 10 bits of 394 source_ID equal to 0x3FF) or a series of write requests addressed 395 to individual nodes SHALL be used to propagate the information. 397 In the case that the NPM is unable to allocate a channel number for ARP 398 and broadcast IP, a warning SHOULD be communicated to a user that IP 399 initialization could NOT complete because of a lack of Serial Bus 400 resources. The user SHOULD be advised to reconfigure or remove other 401 devices if she wishes to make use of IP. 403 NOTE: If the NPM is unable to allocate a channel number, IP-capable 404 nodes are unable to use the ARP and broadcast IP methods specified by 405 this document. If other methods (e.g., a search of configuration ROM) 406 permit IP-capable nodes to discover each other, they MAY be able to send 407 and receive IP datagrams. 409 An IP-capable node that is NOT the NPM typically awaits a write to its 410 NETWORK_CHANNELS that sets the valid bit to one; this indicates that the 411 channel field is valid for ARP and IP broadcast. If some time-out 412 elapses without this occurrence, an IP-capable node MAY attempt to 413 locate the NPM and retrieve valid information from the NETWORK_CHANNELS 414 register. If the npm_ID field in its own NETWORK_CHANNELS register is 415 NOT equal to 0x3F, the address of the NPM is known; otherwise the node 416 MAY search for the NPM as described in e) above. In either case, it is 417 RECOMMENDED that reads of the NETWORK_CHANNELS register NOT be performed 418 within a tight loop, as this could adversely affect both IP and overall 419 1394 performance on the local bus. 421 6. LINK ENCAPSULATION AND FRAGMENTATION 423 All IP datagrams (broadcast, unicast or multicast), ARP 424 requests/responses and MCAP advertisements/solicitations, that are 425 transferred via 1394 block write requests or stream packets SHALL be 426 encapsulated within the packet's data payload. The maximum size of data 427 payload, in octets, is constrained by the speed at which the packet is 428 transmitted. 430 Table 1 - Maximum data payloads (octets) 432 Speed Asynchronous Isochronous 433 +------------------------------------+ 434 | S100 | 512 | 1024 | 435 | S200 | 1024 | 2048 | 436 | S400 | 2048 | 4096 | 437 | S800 | 4096 | 8192 | 438 | S1600 | 8192 | 16384 | 439 | S3200 | 16384 | 32768 | 440 +------------------------------------+ 442 NOTE: The maximum data payloads at speeds of S800 and faster are to be 443 standardized by IEEE P1394b. Current discussion in that working group 444 indicates a likelihood that the maximum data payload of all packets will 445 be limited to 4096 bytes. 447 The maximum data payload for asynchronous requests and responses MAY 448 also be restricted by the capabilities of the sending or receiving 449 node(s); this is specified by max_rec in either the bus information 450 block or ARP response. 452 For either of these reasons, the maximum data payload transmissible 453 between IP-capable nodes MAY be less than the 1500 octet maximum 454 transmission unit (MTU) specified by this document. This requires that 455 the encapsulation format also permit 1394 link-level fragmentation and 456 reassembly of IP datagrams. 458 6.1 Encapsulation header 460 All IP datagrams transported over 1394 are prefixed by an encapsulation 461 header with one of the formats illustrated below. 463 If an entire IP datagram MAY be transmitted within a single 1394 packet, 464 it is unfragmented and the first quadlet of the data payload SHALL 465 conform to the format illustrated below. 467 1 2 3 468 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 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | lf| reserved | ether_type | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 2 - Unfragmented encapsulation header format 475 The lf field SHALL be zero . 477 The ether_type field SHALL indicate the nature of the datagram that 478 follows, as specified by the following table. 480 ether_type Datagram 481 +-----------------------+ 482 | 0x800 | IPv4 | 483 | 0x806 | ARP | 484 | 0x8861 | MCAP | 485 +-----------------------+ 487 NOTE: Other network protocols, identified by different values of 488 ether_type, MAY use the encapsulation formats defined herein but such 489 use is outside of the scope of this document. 491 In cases where the length of the datagram exceeds the maximum data 492 payload supported by the sender and all recipients, the datagram SHALL 493 be broken into link fragments; the first two quadlets of the data 494 payload for the first link fragment SHALL conform to the format shown 495 below. 497 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | lf|rsv| buffer_size | ether_type | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | dgl | signature | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 3 - First fragment encapsulation header format 507 The second and subsequent link fragments (up to and including the last) 508 SHALL conform to the format shown below. 510 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | lf|rsv| buffer_size | rsv | fragment_offset | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | dgl | signature | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 Figure 4 - Subsequent fragment(s) encapsulation header format 520 The definition and usage of the fields is as follows: 522 The lf field SHALL specify the relative position of the link fragment 523 within the IP datagram, as encoded by the following table. 525 lf Position 526 +------------------------+ 527 | 0 | Unfragmented | 528 | 1 | First | 529 | 2 | Last | 530 | 3 | Interior | 531 +------------------------+ 533 buffer_size: The size of the buffer, expressed as buffer_size + 1 534 octets, necessary for the recipient to reassemble the link fragments. 536 ether_type: This field is present only in the first link fragment and 537 SHALL have a value of 0x800, which indicates an IPv4 datagram. 539 fragment_offset: This field is present only in the second and 540 subsequent link fragments and SHALL specify the offset, in octets, of 541 the fragment from the beginning of the IP datagram. The first octet 542 of the datagram (the start of the IP header) has an offset of zero; 543 the implicit value of fragment_offset in the first link fragment is 544 zero. 546 dgl: The value of dgl (datagram label) SHALL be the same for all link 547 fragments of an IP datagram. The sender SHALL increment dgl for 548 successive, fragmented datagrams; the incremented value of dgl SHALL 549 wrap from 65,535 back to zero. 551 signature: The sender SHALL set this field to the most significant 552 16-bits of its own NODE_IDS register. 554 All IP datagrams, regardless of the mode of transmission (block write 555 requests or stream packets) SHALL be preceded by one of the above 556 described encapsulation headers. This permits uniform software treatment 557 of datagrams without regard to the mode of their transmission. 559 6.2 Link fragment reassembly 561 The recipient of an IP datagram transmitted via more than one 1394 562 packet SHALL use both signature and dgl to identify all the link 563 fragments from a single datagram. Subsequent to reassembly, the 564 recipient SHALL verify the IP header checksum of the datagram. 566 NOTE: The use of signature for any purpose other than link fragment 567 reassembly is fraught with error and is strongly discouraged. 569 Upon receipt of a link fragment, the recipient MAY place the data 570 payload (absent the encapsulation header) within an IP datagram 571 reassembly buffer at the location specified by fragment_offset. The size 572 of the reassembly buffer MAY be determined from buffer_size. 574 If a link fragment is received that overlaps another fragment for the 575 same signature and dgl, the fragment(s) already accumulated in the 576 reassembly buffer SHALL be discarded. A fresh reassembly MAY be 577 commenced with the most recently received link fragment. Fragment 578 overlap is determined by the combination of fragment_offset from the 579 encapsulation header and data_length from the 1394 packet header. 581 Upon detection of a Serial Bus reset, recipient(s) SHALL discard all 582 link fragments of all partially reassembled IP datagrams and sender(s) 583 SHALL discard all not yet transmitted link fragments of all partially 584 transmitted IP datagrams. 586 7. ADDRESS RESOLUTION PROTOCOL (ARP) 588 ARP requests SHALL be transmitted by the same means as broadcast IP 589 datagrams; ARP responses MAY be transmitted in the same way or they MAY 590 be transmitted as block write requests addressed to the 591 sender_unicast_FIFO address identified by the ARP request . An ARP 592 request/response is 56 octets and SHALL conform to the format 593 illustrated below. 595 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | hardware_type (0x0018) | protocol_type (0x0800) | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | hw_addr_len | IP_addr_len | opcode | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 +--- sender_unique_ID ---+ 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 | sender_node_ID | sender_unicast_FIFO_hi | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | sender_unicast_FIFO_lo | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | sender_max_rec| sspd | reserved | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | sender_IP_address | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 +--- target_unique_ID ---+ 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | target_node_ID | target_unicast_FIFO_hi | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | target_unicast_FIFO_lo | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | target_max_rec| tspd | reserved | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | target_IP_address | 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 5 - ARP request/response format 629 Field usage in an ARP request/response is as follows: 631 hardware_type: This field indicates 1394 and SHALL have a value of 632 0x0018. 634 protocol_type: This field SHALL have a value of 0x0800; this 635 indicates that the protocol addresses in the ARP request/response 636 conform to the format for IP addresses. 638 hw_addr_len: This field indicates the size, in octets, of the 1394- 639 dependent hardware address associated with an IP address and SHALL 640 have a value of 20. 642 IP_addr_len: This field indicates the size, in octets, of an IP 643 version 4 (IPv4) address and SHALL have a value of 4. 645 opcode: This field SHALL be one to indicate an ARP request and two to 646 indicate an ARP response. 648 sender_unique_ID: This field SHALL contain the node unique ID of the 649 sender and SHALL be equal to that specified in the sender's bus 650 information block. 652 sender_node_ID: This field SHALL contain the most significant 16 bits 653 of the sender's NODE_IDS register. 655 sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields 656 together SHALL specify the 48-bit offset of the sender's FIFO 657 available for the receipt of IP datagrams in the format specified by 658 section 8. The offset of a sender's unicast FIFO SHALL NOT change, 659 except as the result of a power reset . 661 sender_max_rec: This field SHALL be equal to the value of max_rec in 662 the sender�s configuration ROM bus information block. 664 sspd: This field SHALL be set to the lesser of the sender�s link 665 speed and PHY speed. The link speed is the maximum speed at which the 666 link MAY send or receive packets; the PHY speed is the maximum speed 667 at which the PHY MAY send, receive or repeat packets. The encoding 668 used for sspd is specified by the table below; all values NOT 669 specified are RESERVED. 671 Table 2 - Speed codes 673 Value Speed 674 +---------------+ 675 | 0 | S100 | 676 | 1 | S200 | 677 | 2 | S400 | 678 | 3 | S800 | 679 | 4 | S1600 | 680 | 5 | S3200 | 681 +---------------+ 683 sender_IP_address: This field SHALL specify the IP address of the 684 sender. 686 target_unique_ID: In an ARP request, the value of this field is NOT 687 specified; it SHALL be IGNORED by the recipient. In an ARP response, 688 it SHALL be set to the value of sender_unique_ID from the 689 corresponding ARP request. 691 target_node_ID: In an ARP request, the value of this field is NOT 692 specified; it SHALL be IGNORED by the recipient. In an ARP response, 693 it SHALL be set to the value of sender_node_ID from the corresponding 694 ARP request. 696 target_unicast_FIFO_hi and target_unicast_FIFO_lo: In an ARP request, 697 the value of these fields is NOT specified; they SHALL be IGNORED by 698 the recipient. In an ARP response, they SHALL be set to the value of 699 sender_unicast_FIFO_hi and sender_unicast_FIFO_lo from the 700 corresponding ARP request. 702 target_max_rec: In an ARP request, the value of this field is NOT 703 specified; it SHALL be IGNORED by the recipient. In an ARP response, 704 it SHALL be equal to the value of max_rec from the corresponding ARP 705 request. 707 tspd: In an ARP request, the value of this field is NOT specified; it 708 SHALL be IGNORED by the recipient. In an ARP response, it SHALL be 709 equal to the value of sspd from the corresponding ARP request. 711 target_IP_address: In an ARP request, this field SHALL specify the IP 712 address from which the responder desires a response. In an ARP 713 response, it SHALL be set to the value of sender_IP_address from the 714 corresponding ARP request. 716 8. IP UNICAST 718 A unicast IP datagram MAY be transmitted to a recipient within a 1394 719 primary packet that has one of the following transaction codes: 721 tcode Description Arbitration 722 +--------------------------------------+ 723 | 0x01 | Block write | Asynchronous | 724 | 0x0A | Stream packet | Isochronous | 725 | 0x0A | Stream packet | Asynchronous | 726 +--------------------------------------+ 728 Block write requests are suitable when 1394 link-level acknowledgement 729 is desired but there is no need for bounded latency in the delivery of 730 the packet (quality of service). 732 Isochronous stream packets provide quality of service guarantees but no 733 1394 link-level acknowledgement. 735 The last method, asynchronous stream packets, is mentioned only for the 736 sake of completeness. This method SHOULD NOT be used for IP unicast, 737 since it provides for neither 1394 link-level acknowledgment nor quality 738 of service---and consumes a valuable resource, a channel number. 740 Regardless of the IP unicast method employed, asynchronous or 741 isochronous, it is the responsibility of the sender of a unicast IP 742 datagram to determine the maximum data payload that MAY be used in each 743 packet. The necessary information MAY be obtained from: 745 - the SPEED_MAP maintained by the 1394 bus manager, which provides 746 the maximum transmission speed between any two nodes on the local 747 Serial Bus. The bus manager analyzes bus topology in order to 748 construct the speed map; the maximum transmission speed between 749 nodes reflects the capabilities of the intervening nodes. The 750 speed in turn implies a maximum data payload (see Table 1); 752 - the target_max_rec field in an ARP response. This document requires 753 a minimum value of 8 (equivalent to a data payload of 512 octets). 754 Nodes that operate at S200 and faster are encouraged but NOT 755 REQUIRED to implement correspondingly larger values for 756 target_max_rec; or 758 - other methods beyond the scope of this standard. 760 The maximum data payload SHALL be the minimum of the largest data 761 payload implemented by the sender, the recipient and the PHYs of all 762 intervening nodes (the last is implicit in the SPEED_MAP entry indexed 763 by sender and recipient). 765 NOTE: The SPEED_MAP is derived from the self-ID packets transmitted by 766 all 1394 nodes subsequent to a bus reset. An IP-capable node MAY observe 767 the self-ID packets directly. 769 8.1 Asynchronous IP unicast 771 Unicast IP datagrams that do NOT require any quality of service SHALL be 772 contained within the data payload of 1394 block write transactions 773 addressed to the target_node_ID and target_unicast_FIFO obtained from an 774 ARP response . 776 If no acknowledgement is received in response to a unicast block write 777 request, the state of the target is ambiguous. 779 NOTE: An acknowledgment MAY be absent because the target is no longer 780 functional, MAY NOT have received the packet because of a header CRC 781 error or MAY have received the packet successfully but the acknowledge 782 sent in response was corrupted. 784 8.2 Isochronous IP unicast 786 Unicast IP datagrams that require quality of service SHALL be contained 787 within the data payload of 1394 isochronous stream packets. 788 The details of coordination between nodes with respect to allocation of 789 channel number(s) and bandwidth are beyond the scope of this standard. 791 9. IP BROADCAST 793 Broadcast IP datagrams are encapsulated according to the specifications 794 of section 6 and are transported by asynchronous stream packets. There 795 is no quality of service provision for IP broadcast over 1394. The 796 channel number used for IP broadcast is specified by the 797 NETWORK_CHANNELS register. 799 All broadcast IP datagrams SHALL use asynchronous stream packets whose 800 channel number is equal to the channel field from the NETWORK_CHANNELS 801 register. 803 Although 1394 permits the use of previously allocated channel number(s) 804 for up to one second subsequent to a bus reset, IP-capable nodes SHALL 805 NOT transmit asynchronous stream packets at any time the valid bit in 806 their NETWORK_CHANNELS register is zero. Since the valid bit is 807 automatically cleared to zero by a bus reset, this prohibits the use of 808 ARP or broadcast IP until the NPM allocates a channel number. 810 10. IP MULTICAST 812 Multicast IP datagrams are encapsulated according to the specifications 813 of section 6 and are transported by stream packets. Asynchronous streams 814 are used for best-effort IP multicast while isochronous streams are used 815 for IP multicast that requires quality of service. 817 CAUTION: The working group has yet to define facilities and methods for 818 the provision of quality of service for IP multicast. 820 By default, all best-effort IP multicast SHALL use asynchronous stream 821 packets whose channel number is equal to the channel field from the 822 NETWORK_CHANNELS register. In particular, datagrams addressed to 823 224.0.0.1 and 224.0.0.2 SHALL use this channel number. Best-effort IP 824 multicast for other multicast group addresses MAY utilize a different 825 channel number if such a channel number is allocated and advertised 826 prior to use, as described below. 828 IP-capable nodes MAY transmit best-effort IP multicast only if one of 829 the following two conditions is met: 831 - the channel number in the stream packet is equal to the channel 832 number field in the NETWORK_CHANNELS register and the valid bit in 833 the same register is one; or 835 - for other channel number(s), some source of IP multicast has 836 allocated and is advertising the channel number used. 838 The remainder of this section describes a multicast channel allocation 839 protocol (MCAP) employed by both IP multicast sources and recipients 840 whenever a channel number other than the default is used. MCAP is a 841 cooperative protocol; the participants exchange messages over the 842 broadcast channel used by all IP-capable nodes on a particular Serial 843 Bus. 845 CAUTION: The working group has yet to define facilities and methods for 846 shared use of a single channel number (other than the default channel 847 number specified by the NETWORK_CHANNELS register) by more than one IP 848 multicast address. 850 10.1 MCAP Message Format 852 MCAP messages, whether sent by a multicast channel owner or recipient, 853 have the format illustrated below. The first eight octets of the message 854 are fixed; the remainder consists of variable-length tuples, each of 855 which encodes information about a particular multicast group. Individual 856 MCAP messages SHALL NOT be fragmented and SHALL be encapsulated within a 857 stream packet as ether_type 0x8861. 859 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | length | reserved | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | bus_ID | phy_ID | reserved | opcode | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | | 867 + message data + 868 | | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 Figure 6 - MCAP message format 873 Field usage in an MCAP message is as follows: 875 length: This field SHALL contain the size, in octets, of the entire 876 MCAP message. 878 bus_ID: This field SHALL specify the 10-bit bus ID for which 879 information in the MCAP message is valid. The value of bus_ID SHALL 880 be equal to the most significant 10 bits of the sender's NODE_IDS 881 register. IP-capable nodes SHALL neither recognize nor respond to 882 MCAP messages that specify a bus_ID NOT equal to the most significant 883 10 bits of the recipient's NODE_IDS register. 885 phy_ID: This field is valid when opcode indicates an MCAP 886 advertisement. In this case, bus_ID and phy_ID together specify the 887 16-bit node ID of the owner of all channel number(s) present in the 888 message data. 890 opcode: This field SHALL have one of the values specified by the 891 table below. 893 opcode Name Comment 894 +----------------------------------------------------------------+ 895 | 0 | Advertise | Sent by a multicast channel owner to | 896 | | | broadcast the current mapping(s) from one | 897 | | | or more group addresses to their | 898 | | | corresponding channel number(s). | 899 | 1 | Solicit | Sent to request multicast channel owner(s) | 900 | | | to advertise the indicated channel | 901 | | | mapping(s) as soon as possible. | 902 +----------------------------------------------------------------+ 904 message data: The remainder of the MCAP message is variable in length 905 and SHALL consist of zero or more group address descriptors with the 906 format illustrated below. 908 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | length | type | reserved | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | expiration | channel | speed | reserved | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | bandwidth | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | | 918 + group_address + 919 | | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 Figure 7 - MCAP group address descriptor format 924 length: This field SHALL contain the size, in octets, of the MCAP 925 group address descriptor. 927 type: This field SHALL have a value of one, which indicates a group 928 address descriptor. 930 expiration: The usage of this field varies according to opcode. For 931 solicit messages the expiration field SHALL be IGNORED. Otherwise, 932 for advertisements, this field SHALL contain a time-stamp, in 933 seconds, that specifies a future time after which the channel number 934 specified by channel MAY no longer be used. 936 channel: This field is valid only for advertise messages, in which 937 case it SHALL specify a allocated channel number, in the range zero 938 to 63 inclusive. All other values are RESERVED. 940 speed: This field is valid only for advertise messages, in which case 941 it SHALL specify the speed at which stream packets for the indicated 942 channel are transmitted. The encoding used for speed is specified by 943 Table 2. 945 bandwidth: This field SHALL be zero; it is allocated in the group 946 address descriptor to accommodate future extensions to MCAP that 947 specify quality of service and utilize the isochronous capabilities 948 of Serial Bus. 950 group_address: This variable length field SHALL specify the IP 951 address of a particular multicast group. The length of group_address, 952 in octets, is derived from the length of the group address descriptor 953 by subtracting 12 from the length field. 955 10.2 Multicast receive 957 An IP-capable device that wishes to receive multicast data SHALL first 958 ascertain the channel mapping (if any) that exists between a group 959 address and a channel number other than the default channel specified by 960 the NETWORK_CHANNELS register. Such a device MAY observe the MCAP 961 advertisements on the broadcast channel for the desired channel 962 mapping(s). 964 An intended multicast recipient MAY transmit MCAP solicitation requests 965 in order to request multicast channel owner(s) to broadcast 966 advertisements sooner than the next ten second interval. Originators of 967 MCAP solicitation requests SHALL limit the rate at which they are 968 transmitted. Subsequent to sending a solicitation request, the 969 originator SHALL NOT send another MCAP solicitation request until 10 970 seconds have expired. 972 In either case, if a mapping exists for the group address for other than 973 the default channel, an MCAP advertise message is EXPECTED within ten 974 seconds. Upon receipt of an MCAP advertise message that describes one or 975 more channel mappings, the intended multicast recipient MAY receive IP 976 datagrams on the indicated channel number(s) until the expiration time. 977 If no MCAP advertise message is received for a particular group address 978 within 10 seconds, no multicast source(s) are active for channel(s) 979 other than the default. Either there is there is no multicast data or it 980 is being transmitted on the default channel. 982 If multiple MCAP advertise messages are observed that specify the same 983 group address, the channel number SHALL be obtained from the 984 advertisement message with the largest phy_ID. 986 If no MCAP advertise message is received for the desired group 987 addresses, no multicast sources are active and there is no data to 988 receive. 990 Once a multicast recipient has observed an advertisement for the desired 991 group address, it SHALL continue to monitor the broadcast channel for 992 MCAP advertisements for the same group address in order to refresh the 993 expiration time of channel number(s) in use. 995 10.3 Multicast transmit 997 An IP-capable device that wishes to transmit multicast data on other 998 than the default channel SHALL first ascertain whether or NOT another 999 multicast source has already allocated a channel number for the group 1000 address. The intended multicast source MAY transmit an MCAP solicitation 1001 request with one or more group address descriptors. 1003 Whether or NOT a solicitation request has been transmitted, the intended 1004 multicast source SHALL monitor the broadcast channel for MCAP 1005 advertisements. If a channel mapping already exists for the group 1006 address, an MCAP advertisement SHOULD be received within ten seconds. In 1007 this case the intended multicast source MAY commence transmission of IP 1008 datagrams on the indicated channel number(s) and MAY continue to do so 1009 until their expiration time. The multicast source SHALL monitor MCAP 1010 advertisements in order to refresh the expiration time of channel 1011 number(s) in use. 1013 When no other multicast source has established a channel mapping for the 1014 group address, the intended multicast source MAY attempt to allocate a 1015 channel number from the isochronous resource manager's 1016 CHANNELS_AVAILABLE register according to the procedures described in 1017 IEEE Std 1394-1995. If the channel number allocation is successful, the 1018 multicast source SHALL advertise the new channel mapping(s) as soon as 1019 possible; once such advertisement has been made, the multicast source 1020 MAY transmit IP datagrams using the channel number obtained. 1022 Multicast IP datagrams MAY be transmitted on the default channel until 1023 the sender observes (or transmits) an advertisement that specifies non- 1024 default channel mapping(s) for the multicast addresses. This permits the 1025 smooth transition of multicast from the default channel to an explicitly 1026 allocated channel. 1028 10.4 Advertisement of channel mappings 1030 Each multicast source SHALL periodically broadcast an advertisement of 1031 all multicast group addresses for which it has allocated a channel 1032 number different from the default multicast channel number. An 1033 advertisement SHALL consist of a single MCAP message with an opcode of 1034 zero which contains one or more group address descriptors (one for each 1035 group address assigned a channel number other than that specified by the 1036 NETWORK_CHANNELS register). 1038 Within each group address descriptor, the group_address and channel 1039 fields associate a multicast group address with a Serial Bus channel 1040 number. More than one multicast group address MAY be mapped to a single 1041 Serial Bus channel number by means of separate group address 1042 descriptors. The speed field specifies the maximum 1394 speed at which 1043 any of the senders within the multicast group is permitted to transmit 1044 data. The expiration field specifies a future time after which the 1045 channel mapping(s) are no longer valid. Except when a channel owner 1046 intends to relinquish ownership (as described in 10.6 below), the 1047 expiration time SHALL be at least 60 seconds in the future measured from 1048 the time the advertisement is transmitted. 1050 No more than ten seconds SHALL elapse from the transmission of its most 1051 recent advertisement before a the owner of a channel mapping initiates 1052 transmission of the subsequent advertisement. The owner of a channel 1053 mapping SHOULD transmit an MCAP advertisement in response to a 1054 solicitation as soon as possible after the receipt of the request. 1056 10.5 Overlapped channel mappings 1058 When two intended multicast sources wish to transmit to the same 1059 multicast group and no channel mapping exists for the group address, 1060 there is a chance that both will allocate channel numbers and both will 1061 advertise the channel mappings. These channel mappings overlap, i.e., 1062 the same group address is mapped to more than one channel number. 1064 Multicast channel owners SHALL monitor MCAP advertisements in order to 1065 detect overlapped channel mappings. When an overlapped channel mapping 1066 is detected, the owner with the largest phy_ID is NOT REQUIRED to take 1067 any action. The owner(s) with smaller physical ID's SHALL cease 1068 transmission of MCAP advertisements for the overlapped channel number. 1070 As soon as these channel mapping(s) are no longer valid, their owners 1071 SHALL deallocate any unused channel numbers as described in 10.7 below. 1073 Recipients of MCAP advertisements that detect overlapped channel 1074 mappings SHALL ignore the advertisements from multicast channel owner(s) 1075 with the smaller physical ID's. It is possible for some channel mappings 1076 in a single MCAP advertisement to be valid even if others SHALL be 1077 IGNORED as a result of overlap. 1079 10.6 Transfer of channel ownership 1081 The owner of a channel mapping MAY cease multicast transmission on a 1082 particular channel, in which case it SHOULD invalidate the channel 1083 mapping and in some cases deallocate the channel number. Because other 1084 multicast sources MAY be using the same channel mapping, an orderly 1085 process is defined to transfer channel ownership. 1087 The owner of an existing channel mapping that wishes to release the 1088 mapping SHALL commence a timer to measure the time remaining before the 1089 anticipated release of the mapping and its associated channel. Until the 1090 timer counts down to zero, the owner SHALL continue to transmit MCAP 1091 advertisements for the affected channel but SHALL adjust expiration in 1092 each advertisement to reflect the time remaining until the channel is to 1093 be deallocated. The sequence of expiration times transmitted by the 1094 owner intending to release the mapping SHALL decrease with each 1095 succeeding advertisement. If other multicast source(s) are using the 1096 same channel mapping and observe an expiration time less than or equal 1097 to 30 seconds, they SHALL commence transmitting MCAP advertisements for 1098 the channel mapping with refreshed expiration times greater than or 1099 equal to 30 seconds that maintain the channel mapping. Any contention 1100 that occurs between multiple sources that attempt to claim ownership of 1101 the channel mapping SHALL be resolved as described in 10.5. If the 1102 original owner observes an MCAP advertisement for the channel to be 1103 relinquished before its own timer has expired, it SHALL NOT deallocate 1104 the channel number. 1106 Otherwise, if the owner's timer expires without the observation of a 1107 MCAP advertisement by another node, the owner of the channel number 1108 SHALL deallocate the channel as described below. 1110 10.7 Expired channel mappings 1112 A channel mapping expires when expiration seconds have elapsed since the 1113 most recent MCAP advertisement. At this time, multicast recipients SHALL 1114 stop reception on the expired channel number(s). The owner of the 1115 channel mapping(s) SHALL deallocate the channel number and indicate its 1116 availability in the isochronous resource manager's CHANNELS_AVAILABLE 1117 register. 1119 11. SECURITY CONSIDERATIONS 1121 This document specifies the use of an unsecured link layer, Serial Bus, 1122 for the transport of IPv4 datagrams. Serial Bus is vulnerable to denial 1123 of service attacks; it is also possible for devices to eavesdrop on data 1124 or present forged identities. Implementers who utilize Serial Bus for 1125 IPv4 SHOULD consider appropriate counter-measures within application or 1126 other layers. 1128 12. ACKNOWLEDGEMENTS 1130 This document represents work in progress by the IP/1394 Working Group. 1131 The editor wishes to acknowledge the contributions made by all the 1132 active participants, either on the reflector or at face-to-face 1133 meetings, which have advanced the technical content. 1135 13. REFERENCES 1137 [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus 1139 [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture 1140 for Microcomputer Buses 1142 [3] IEEE Project P1394a, Draft Standard for a High Performance Serial 1143 Bus (Supplement) 1145 [4] IEEE Project P1394b, Draft Standard for a High Performance Serial 1146 Bus (Supplement) 1148 14. EDITOR�S ADDRESS 1150 Peter Johansson 1151 Congruent Software, Inc. 1152 98 Colorado Avenue 1153 Berkeley, CA 94602 1155 (510) 527-3926 1156 (510) 527-3856 FAX 1157 pjohansson@aol.com