idnits 2.17.1 draft-ietf-ip1394-ipv4-19.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 2) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 160: '...ined meaning and SHALL be zeroed by it...' RFC 2119 keyword, line 162: '...e recipient of a RESERVED object SHALL...' RFC 2119 keyword, line 164: '...by this standard SHALL check its value...' RFC 2119 keyword, line 177: '...ocal bus; a node SHALL respond to requ...' RFC 2119 keyword, line 263: '...IP datagrams. An IP-capable node SHALL...' (128 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 1218, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 1220, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1223, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1226, 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: 4 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IP1394 Working Group P. Johansson 2 Internet-Draft Congruent Software, Inc. 3 4 Expires: March 2000 6 IPv4 over IEEE 1394 8 STATUS OF THIS DOCUMENT 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 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 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt. 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 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. These include not 33 only packet formats and encapsulation methods for datagrams, but also an 34 address resolution protocol (1394 ARP) and a multicast channel 35 allocation protocol (MCAP). Both 1394 ARP and MCAP are specific to 36 Serial Bus; the latter permits management of Serial Bus resources when 37 used by IP multicast groups. 39 TABLE OF CONTENTS 41 1. INTRODUCTION........................................................3 42 2. DEFINITIONS AND NOTATION............................................4 43 2.1 Conformance.....................................................4 44 2.2 Glossary........................................................4 45 2.3 Abbreviations...................................................5 46 2.4 Numeric values..................................................6 47 3. IP-CAPABLE NODES....................................................6 48 4. LINK ENCAPSULATION AND FRAGMENTATION................................6 49 4.1 Global asynchronous stream packet (GASP) format.................7 50 4.2 Encapsulation header............................................8 51 4.3 Link fragment reassembly.......................................10 52 5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP)..................11 53 6. CONFIGURATION ROM..................................................13 54 6.1 Unit_Spec_ID entry.............................................13 55 6.2 Unit_SW_Version entry..........................................13 56 6.3 Textual descriptors............................................13 57 7. IP UNICAST.........................................................14 58 8. IP BROADCAST.......................................................16 59 9. IP MULTICAST.......................................................16 60 9.1 MCAP message format............................................17 61 9.2 MCAP message domain............................................18 62 9.3 Multicast receive..............................................19 63 9.4 Multicast transmit.............................................19 64 9.5 Advertisement of channel mappings..............................20 65 9.6 Overlapped channel mappings....................................21 66 9.7 Transfer of channel ownership..................................21 67 9.8 Redundant channel mappings.....................................22 68 9.9 Expired channel mappings.......................................22 69 9.10 Bus reset.....................................................23 70 10. IANA CONSIDERATIONS...............................................23 71 11. SECURITY CONSIDERATIONS...........................................24 72 12. ACKNOWLEDGEMENTS..................................................24 73 13. REFERENCES........................................................24 74 14. EDITOR'S ADDRESS..................................................24 75 1. INTRODUCTION 77 This document specifies how to use IEEE Std 1394-1995, Standard for a 78 High Performance Serial Bus (and its supplements), for the transport of 79 Internet Protocol Version 4 (IPv4) datagrams. It defines the necessary 80 methods, data structures and codes for that purpose and additionally 81 defines methods for an address resolution protocol (1394 ARP) and a 82 multicast channel allocation protocol (MCAP)---both of which are 83 specific to Serial Bus. 85 The group of IEEE standards and supplements, draft or approved, related 86 to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as 87 Serial Bus. 89 1394 is an interconnect (bus) that conforms to the CSR architecture, 90 ISO/IEC 13213:1994. Serial Bus permits communications between nodes over 91 shared physical media at speeds that range, at present, from 100 to 92 400 Mbps. Both consumer electronic applications (such as digital VCRs, 93 stereo systems, televisions and camcorders) and traditional desktop 94 computer applications (e.g., mass storage, printers and tapes), have 95 adopted 1394. Serial Bus is unique in its relevance to both consumer 96 electronic and computer domains and is EXPECTED to form the basis of a 97 home or small office network that combines both types of devices. 99 The CSR architecture describes a memory-mapped address space that Serial 100 Bus implements as a 64-bit fixed addressing scheme. Within the address 101 space, ten bits are allocated for bus ID (up to a maximum of 1,023 102 buses), six are allocated for node physical ID (up to 63 per bus) while 103 the remaining 48 bits (offset) describe a per node address space of 256 104 terabytes. The CSR architecture, by convention, splits a node's address 105 space into two regions with different behavioral characteristics. The 106 lower portion, up to but not including 0xFFFF F000 0000, is EXPECTED to 107 behave as memory in response to read and write transactions. The upper 108 portion is more like a traditional IO space: read and write transactions 109 in this area usually have side effects. Control and status registers 110 (CSRs) that have FIFO behavior customarily are implemented in this 111 region. 113 Within the 64-bit address, the 16-bit node ID (bus ID and physical ID) 114 is analogous to a network hardware address---but 1394 node IDs are 115 variable and subject to reassignment each time one or more nodes are 116 added to or removed from the bus. 118 NOTE: Although the 16-bit node ID contains a bus ID, at present there is 119 no standard method to connect separately enumerated Serial Buses. Active 120 development of a standard for Serial Bus to Serial Bus bridges is 121 underway in the IEEE P1394.1 working group. Unless extended by some 122 future standard, the IPv4 over 1394 protocols specified by this document 123 may not operate correctly across bridges. 125 The 1394 link layer provides a packet delivery service with both 126 confirmed (acknowledged) and unconfirmed packets. Two levels of service 127 are available: "asynchronous" packets are sent on a best-effort basis 128 while "isochronous" packets are guaranteed to be delivered with bounded 129 latency. Confirmed packets are always asynchronous but unconfirmed 130 packets may be either asynchronous or isochronous. Data payloads vary 131 with implementations and may range from one octet up to a maximum 132 determined by the transmission speed (at 100 Mbps, named S100, the 133 maximum asynchronous data payload is 512 octets while at S400 it is 2048 134 octets). 136 NOTE: Extensions underway in IEEE P1394b contemplate additional speeds 137 of 800, 1600 and 3200 Mbps. 139 2. DEFINITIONS AND NOTATION 141 2.1 Conformance 143 When used in this document, the keywords "MAY", "OPTIONAL", 144 "RECOMMENDED", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD" and "SHOULD 145 NOT" differentiate levels of requirements and optionality and are to be 146 interpreted as described in RFC 2119. 148 Several additional keywords are employed, as follows: 150 EXPECTED: A keyword used to describe the behavior of the hardware or 151 software in the design models assumed by this standard. Other hardware 152 and software design models may also be implemented. 154 IGNORED: A keyword that describes bits, octets, quadlets or fields whose 155 values are not checked by the recipient. 157 RESERVED: A keyword used to describe either objects---bits, octets, 158 quadlets and fields---or the code values assigned to these objects; the 159 object or the code value is set aside for future standardization. A 160 RESERVED object has no defined meaning and SHALL be zeroed by its 161 originator or, upon development of a future standard, set to a value 162 specified by such a standard. The recipient of a RESERVED object SHALL 163 NOT check its value. The recipient of an object whose code values are 164 defined by this standard SHALL check its value and reject RESERVED code 165 values. 167 2.2 Glossary 169 The following terms are used in this standard: 171 address resolution protocol: A method for a requester to determine the 172 hardware (1394) address of an IP node from the IP address of the node. 174 bus ID: A 10-bit number that uniquely identifies a particular bus within 175 a group of multiple interconnected buses. The bus ID is the most 176 significant portion of a node's 16-bit node ID. The value 0x3FF 177 designates the local bus; a node SHALL respond to requests addressed to 178 its 6-bit physical ID if the bus ID in the request is either 0x3FF or 179 the bus ID explicitly assigned to the node. 181 encapsulation header: A structure that precedes all IP data transmitted 182 over 1394. See also link fragment. 184 IP datagram: An Internet message that conforms to the format specified 185 by RFC 791. 187 link fragment: A portion of an IP datagram transmitted within a single 188 1394 packet. The data payload of the 1394 packet contains both an 189 encapsulation header and its associated link fragment. It is possible to 190 transmit datagrams without link fragmentation. 192 multicast channel allocation protocol: A method for multicast groups to 193 coordinate their use of Serial Bus resources (channels) if multicast 194 datagrams are transmitted on other than the default broadcast channel. 196 multicast channel owner: A multicast source that has allocated a channel 197 for one or more multicast addresses and transmits MCAP advertisements to 198 communicate these channel mapping(s) to other participants in the IP 199 multicast group. When more than one source transmits MCAP advertisements 200 for the same channel number, the source with the largest physical ID is 201 the owner. 203 node ID: A 16-bit number that uniquely identifies a Serial Bus node 204 within a group of multiple interconnected buses. The most significant 205 ten bits are the bus ID and the least significant six bits are the 206 physical ID. 208 node unique ID: A 64-bit number that uniquely identifies a node among 209 all the Serial Bus nodes manufactured worldwide; also known as the 210 EUI-64 (Extended Unique Identifier, 64-bits). 212 octet: Eight bits of data. 214 packet: Any of the 1394 primary packets; these may be read, write or 215 lock requests (and their responses) or stream data. The term "packet" is 216 used consistently to differentiate Serial Bus primary packets from 1394 217 ARP requests/responses, IP datagrams or MCAP 218 advertisements/solicitations. 220 physical ID: On a particular bus, this 6-bit number is dynamically 221 assigned during the self-identification process and uniquely identifies 222 a node on that bus. 224 quadlet: Four octets, or 32 bits, of data. 226 stream packet: A 1394 primary packet with a transaction code of 0x0A 227 that contains a block data payload. Stream packets may be either 228 asynchronous or isochronous according to the type of 1394 arbitration 229 employed. 231 2.3 Abbreviations 233 The following are abbreviations that are used in this standard: 235 1394 ARP Address resolution protocol (specific to 1394) 236 CSR Control and status register 237 CRC Cyclical redundancy checksum 238 EUI-64 Extended Unique Identifier, 64-bits 239 GASP Global asynchronous stream packet 240 IP Internet protocol (within this document, IPv4) 241 MCAP Multicast channel allocation protocol 243 2.4 Numeric values 245 Decimal and hexadecimal numbers are used within this standard. By 246 editorial convention, decimal numbers are most frequently used to 247 represent quantities or counts. Addresses are uniformly represented by 248 hexadecimal numbers, which are also used when the value represented has 249 an underlying structure that is more apparent in a hexadecimal format 250 than in a decimal format. 252 Decimal numbers are represented by Arabic numerals or by their English 253 names. Hexadecimal numbers are prefixed by 0x and represented by digits 254 from the character set 0 - 9 and A - F. For the sake of legibility, 255 hexadecimal numbers are separated into groups of four digits separated 256 by spaces. 258 For example, both 42 and 0x2A represent the same numeric value. 260 3. IP-CAPABLE NODES 262 Not all Serial Bus devices are capable of the reception and transmission 263 of 1394 ARP requests/responses or IP datagrams. An IP-capable node SHALL 264 fulfill the following minimum requirements: 266 - it SHALL implement configuration ROM in the general format 267 specified by ISO/IEC 13213:1994 and SHALL implement the bus 268 information block specified by IEEE P1394a and a unit directory 269 specified by this standard; 271 - the max_rec field in its bus information block SHALL be at least 8; 272 this indicates an ability to accept block write requests and 273 asynchronous stream packets with data payload of 512 octets. The 274 same ability SHALL also apply to read requests; that is, the node 275 SHALL be able to transmit a block response packet with a data 276 payload of 512 octets; 278 - it SHALL be isochronous resource manager capable, as specified by 279 IEEE P1394a; 281 - it SHALL support both reception and transmission of asynchronous 282 streams as specified by IEEE P1394a; and 284 4. LINK ENCAPSULATION AND FRAGMENTATION 286 All IP datagrams (broadcast, unicast or multicast), 1394 ARP 287 requests/responses and MCAP advertisements/solicitations that are 288 transferred via 1394 block write requests or stream packets SHALL be 289 encapsulated within the packet's data payload. The maximum size of data 290 payload, in octets, is constrained by the speed at which the packet is 291 transmitted. 293 Table 1 - Maximum data payloads (octets) 295 Speed Asynchronous Isochronous 296 +------------------------------------+ 297 | S100 | 512 | 1024 | 298 | S200 | 1024 | 2048 | 299 | S400 | 2048 | 4096 | 300 | S800 | 4096 | 8192 | 301 | S1600 | 8192 | 16384 | 302 | S3200 | 16384 | 32768 | 303 +------------------------------------+ 305 NOTE: The maximum data payloads at speeds of S800 and faster may be 306 reduced (but will not be increased) as a result of standardization by 307 IEEE P1394b. 309 The maximum data payload for asynchronous requests and responses may 310 also be restricted by the capabilities of the sending or receiving 311 node(s); this is specified by max_rec in either the bus information 312 block or 1394 ARP response. 314 For either of these reasons, the maximum data payload transmissible 315 between IP-capable nodes may be less than the default 1500 octet maximum 316 transmission unit (MTU) specified by this document. This requires that 317 the encapsulation format also permit 1394 link-level fragmentation and 318 reassembly of IP datagrams. 320 NOTE: IP-capable nodes may operate with an MTU size larger than the 321 default, but the means by which a larger MTU is configured are beyond 322 the scope of this document. 324 4.1 Global asynchronous stream packet (GASP) format 326 Some IP datagrams, as well as 1394 ARP requests and responses, may be 327 transported via asynchronous stream packets. When asynchronous stream 328 packets are used, their format SHALL conform to the global asynchronous 329 stream packet (GASP) format specified by IEEE P1394a. The GASP format 330 illustrated below is INFORMATIVE and reproduced for ease of reference, 331 only. 333 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | data_length |tag| channel | 0x0A | sy | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | header_CRC | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | source_ID | specifier_ID_hi | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 |specifier_ID_lo| version | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 +--- data ---+ 346 | | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | data_CRC | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 Figure 1 - GASP format 353 The source_ID field SHALL specify the node ID of the sending node and 354 SHALL be equal to the most significant 16 bits of the sender's NODE_IDS 355 register. 357 The specifier_ID_hi and specifier_ID_lo fields together SHALL contain 358 the value 0x00 005E, the 24-bit organizationally unique identifier (OUI) 359 assigned by the IEEE Registration Authority (RA) to IANA. 361 The version field SHALL be one. 363 NOTE: Because the GASP format utilizes the first two quadlets of data 364 payload in an asynchronous stream packet format, the maximum payloads 365 cited in Table 1 are effectively reduced by eight octets. In the clauses 366 that follow, references to the first quadlet of data payload mean the 367 first quadlet usable for an IP datagram or 1394 ARP request or response. 368 When the GASP format is used, this is the third quadlet of the data 369 payload for the packet. 371 4.2 Encapsulation header 373 All IP datagrams transported over 1394 are prefixed by an encapsulation 374 header with one of the formats illustrated below. 376 If an entire IP datagram may be transmitted within a single 1394 packet, 377 it is unfragmented and the first quadlet of the data payload SHALL 378 conform to the format illustrated below. 380 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | lf| reserved | ether_type | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 Figure 2 - Unfragmented encapsulation header format 388 The lf field SHALL be zero. 390 The ether_type field SHALL indicate the nature of the datagram that 391 follows, as specified by the following table. 393 ether_type Datagram 394 +-------------------------+ 395 | 0x0800 | IPv4 | 396 | 0x0806 | 1394 ARP | 397 | 0x8861 | MCAP | 398 +-------------------------+ 400 NOTE: Other network protocols, identified by different values of 401 ether_type, may use the encapsulation formats defined herein but such 402 use is outside of the scope of this document. 404 In cases where the length of the datagram exceeds the maximum data 405 payload supported by the sender and all recipients, the datagram SHALL 406 be broken into link fragments; the first two quadlets of the data 407 payload for the first link fragment SHALL conform to the format shown 408 below. 410 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | lf|rsv| buffer_size | ether_type | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | dgl | reserved | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3 - First fragment encapsulation header format 420 The second and subsequent link fragments (up to and including the last) 421 SHALL conform to the format shown below. 423 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | lf|rsv| buffer_size | rsv | fragment_offset | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | dgl | reserved | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 4 - Subsequent fragment(s) encapsulation header format 433 The definition and usage of the fields is as follows: 435 The lf field SHALL specify the relative position of the link fragment 436 within the IP datagram, as encoded by the following table. 438 lf Position 439 +------------------------+ 440 | 0 | Unfragmented | 441 | 1 | First | 442 | 2 | Last | 443 | 3 | Interior | 444 +------------------------+ 446 buffer_size: The size of the buffer, expressed as buffer_size + 1 447 octets, necessary for the recipient to reassemble the entire IP 448 datagram from all of the link fragments. The value of buffer_size 449 SHALL be the same for all link fragments of an IP datagram. 451 ether_type: This field is present only in the first link fragment and 452 SHALL have a value of 0x0800, which indicates an IPv4 datagram. 454 fragment_offset: This field is present only in the second and 455 subsequent link fragments and SHALL specify the offset, in octets, of 456 the fragment from the beginning of the IP datagram. The first octet 457 of the datagram (the start of the IP header) has an offset of zero; 458 the implicit value of fragment_offset in the first link fragment is 459 zero. 461 dgl: The value of dgl (datagram label) SHALL be the same for all link 462 fragments of an IP datagram. The sender SHALL increment dgl for 463 successive, fragmented datagrams; the incremented value of dgl SHALL 464 wrap from 65,535 back to zero. 466 All IP datagrams, regardless of the mode of transmission (block write 467 requests or stream packets) SHALL be preceded by one of the above 468 described encapsulation headers. This permits uniform software treatment 469 of datagrams without regard to the mode of their transmission. 471 4.3 Link fragment reassembly 473 The recipient of an IP datagram transmitted via more than one 1394 474 packet SHALL use both the sender's source_ID (obtained from either the 475 asynchronous packet header or the GASP header) and dgl to identify all 476 the link fragments from a single datagram. 478 Upon receipt of a link fragment, the recipient may place the data 479 payload (absent the encapsulation header) within an IP datagram 480 reassembly buffer at the location specified by fragment_offset. The size 481 of the reassembly buffer may be determined from buffer_size. 483 If a link fragment is received that overlaps another fragment identified 484 by the same source_ID and dgl, the fragment(s) already accumulated in 485 the reassembly buffer SHALL be discarded. A fresh reassembly may be 486 commenced with the most recently received link fragment. Fragment 487 overlap is determined by the combination of fragment_offset from the 488 encapsulation header and data_length from the 1394 packet header. 490 Upon detection of a Serial Bus reset, recipient(s) SHALL discard all 491 link fragments of all partially reassembled IP datagrams and sender(s) 492 SHALL discard all not yet transmitted link fragments of all partially 493 transmitted IP datagrams. 495 5. SERIAL BUS ADDRESS RESOLUTION PROTOCOL (1394 ARP) 497 Methods to determine the hardware address of a device from its 498 corresponding IP address are inextricably tied to the transport medium 499 utilized by the device. In the description below and throughout this 500 document, the acronym 1394 ARP pertains solely to an address resolution 501 protocol whose methods and data structures are specific to 1394. 503 1394 ARP requests SHALL be transmitted by the same means as broadcast IP 504 datagrams; 1394 ARP responses MAY be transmitted in the same way or they 505 MAY be transmitted as block write requests addressed to the 506 sender_unicast_FIFO address identified by the 1394 ARP request. A 1394 507 ARP request/response is 32 octets and SHALL conform to the format 508 illustrated by Figure 5. 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 | hardware_type (0x0018) | protocol_type (0x0800) | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | hw_addr_len | IP_addr_len | opcode | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | | 518 +--- sender_unique_ID ---+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 521 | sender_max_rec| sspd | sender_unicast_FIFO_hi | 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | sender_unicast_FIFO_lo | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | sender_IP_address | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | target_IP_address | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 5 - 1394 ARP request/response format 532 1394 ARP requests and responses transported by asynchronous stream 533 packets SHALL be encapsulated within the GASP format specified by IEEE 534 P1394a (see also 4.1). The recipient of a 1394 ARP request or response 535 SHALL ignore it unless the most significant ten bits of the source_ID 536 field (whether obtained from the GASP header of an asynchronous stream 537 packet or the packet header of a block write request) are equal to 538 either 0x3FF or the most significant ten bits of the recipient's 539 NODE_IDS register. 541 Field usage in a 1394 ARP request/response is as follows: 543 hardware_type: This field indicates 1394 and SHALL have a value of 544 0x0018. 546 protocol_type: This field SHALL have a value of 0x0800; this 547 indicates that the protocol addresses in the 1394 ARP 548 request/response conform to the format for IP addresses. 550 hw_addr_len: This field indicates the size, in octets, of the 551 1394-dependent hardware address associated with an IP address and 552 SHALL have a value of 16. 554 IP_addr_len: This field indicates the size, in octets, of an IP 555 version 4 (IPv4) address and SHALL have a value of 4. 557 opcode: This field SHALL be one to indicate a 1394 ARP request and 558 two to indicate a 1394 ARP response. 560 sender_unique_ID: This field SHALL contain the node unique ID of the 561 sender and SHALL be equal to that specified in the sender's bus 562 information block. 564 sender_max_rec: This field SHALL be equal to the value of max_rec in 565 the sender's configuration ROM bus information block. 567 sspd: This field SHALL be set to the lesser of the sender's link 568 speed and PHY speed. The link speed is the maximum speed at which the 569 link may send or receive packets; the PHY speed is the maximum speed 570 at which the PHY may send, receive or repeat packets. The table below 571 specifies the encoding used for sspd; all values not specified are 572 RESERVED for future standardization. 574 Table 2 - Speed codes 576 Value Speed 577 +---------------+ 578 | 0 | S100 | 579 | 1 | S200 | 580 | 2 | S400 | 581 | 3 | S800 | 582 | 4 | S1600 | 583 | 5 | S3200 | 584 +---------------+ 586 sender_unicast_FIFO_hi and sender_unicast_FIFO_lo: These fields 587 together SHALL specify the 48-bit offset of the sender's FIFO 588 available for the receipt of IP datagrams in the format specified by 589 section 6. The offset of a sender's unicast FIFO SHALL NOT change, 590 except as the result of a power reset. 592 sender_IP_address: This field SHALL specify the IP address of the 593 sender. 595 target_IP_address: In a 1394 ARP request, this field SHALL specify 596 the IP address from which the sender desires a response. In a 1394 597 ARP response, it SHALL be IGNORED. 599 6. CONFIGURATION ROM 601 Configuration ROM for IP-capable nodes SHALL contain a unit directory in 602 the format specified by this standard. The unit directory SHALL contain 603 Unit_Spec_ID and Unit_SW_Version entries, as specified by ISO/IEC 604 13213:1994. 606 The unit directory may also contain other entries permitted by ISO/IEC 607 13213:1994 or IEEE P1212r. 609 6.1 Unit_Spec_ID entry 611 The Unit_Spec_ID entry is an immediate entry in the unit directory that 612 specifies the organization responsible for the architectural definition 613 of the Internet Protocol capabilities of the device. 615 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | 0x12 | unit_spec_ID (0x00 005E) | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Figure 6 - Unit_Spec_ID entry format 623 The value of unit_spec_ID SHALL be 0x00 005E, the registration ID (RID) 624 obtained by IANA from the IEEE RA. The value indicates that the IETF and 625 its technical committees are responsible for the maintenance of this 626 standard. 628 6.2 Unit_SW_Version entry 630 The Unit_SW_Version entry is an immediate entry in the unit directory 631 that, in combination with the unit_spec_ID, specifies the document that 632 defines the software interface of the unit. 634 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | 0x13 | unit_sw_version (0x00 0001) | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Figure 7 - Unit_SW_Version entry format 642 The value of unit_sw_version SHALL be one, which indicates that the 643 device complies with the normative requirements of this standard. 645 6.3 Textual descriptors 647 Textual descriptors within configuration ROM are OPTIONAL; when present 648 they provide additional descriptive information intended to be 649 intelligible to a human user. IP-capable nodes SHOULD associate a 650 textual descriptor with a content of "IANA" with the Unit_Spec_ID entry 651 and a textual descriptor with a content of "IPv4" for the 652 Unit_SW_Version entry. 654 The figure below illustrates a unit directory implemented by an 655 IP-capable node; it includes OPTIONAL textual descriptors. Although the 656 textual descriptor leaves are not part of the unit directory, for the 657 sake of simplicity they are shown immediately following the unit 658 directory. 660 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | directory_length (4) | CRC | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | 0x12 | unit_spec_ID (0x00 005E) | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | 0x81 | textual descriptor offset (3) | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | 0x13 | unit_sw_version | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | 0x81 | textual descriptor offset (5) | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | textual_descriptor_length (3) | CRC | 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | | 676 +--- zeros ---+ 677 | | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | "I" | "A" | "N" | "A" | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | textual_descriptor_length (3) | CRC | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | | 684 +--- zeros ---+ 685 | | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | "I" | "P" | "v" | "4" | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 9 - Sample unit directory and textual descriptors 692 7. IP UNICAST 694 A unicast IP datagram may be transmitted to a recipient within a 1394 695 primary packet that has one of the following transaction codes: 697 tcode Description Arbitration 698 +--------------------------------------+ 699 | 0x01 | Block write | Asynchronous | 700 | 0x0A | Stream packet | Isochronous | 701 | 0x0A | Stream packet | Asynchronous | 702 +--------------------------------------+ 704 Block write requests are suitable when 1394 link-level acknowledgement 705 is desired but there is no need for bounded latency in the delivery of 706 the packet (quality of service). 708 Isochronous stream packets provide quality of service guarantees but no 709 1394 link-level acknowledgement. 711 The last method, asynchronous stream packets, is mentioned only for the 712 sake of completeness. This method SHOULD NOT be used for IP unicast, 713 since it provides for neither 1394 link-level acknowledgment nor quality 714 of service---and consumes a valuable resource, a channel number. 716 Regardless of the IP unicast method employed, asynchronous or 717 isochronous, it is the responsibility of the sender of a unicast IP 718 datagram to determine the maximum data payload that may be used in each 719 packet. The necessary information may be obtained from: 721 - the SPEED_MAP maintained by the 1394 bus manager, which provides 722 the maximum transmission speed between any two nodes on the local 723 Serial Bus. The bus manager analyzes bus topology in order to 724 construct the speed map; the maximum transmission speed between 725 nodes reflects the capabilities of the intervening nodes. The 726 speed in turn implies a maximum data payload (see Table 1); 728 - the sender_max_rec field in a 1394 ARP response; or 730 - other methods beyond the scope of this standard. 732 The maximum data payload SHALL be the minimum of the largest data 733 payload implemented by the sender, the recipient and the PHYs of all 734 intervening nodes (the last is implicit in the SPEED_MAP entry indexed 735 by sender and recipient). 737 NOTE: The SPEED_MAP is derived from the self-ID packets transmitted by 738 all 1394 nodes subsequent to a bus reset. An IP-capable node may observe 739 the self-ID packets directly. 741 Unicast IP datagrams whose quality of service is best-effort SHALL be 742 contained within the data payload of 1394 block write transactions 743 addressed to the source_ID and sender_unicast_FIFO obtained from a 1394 744 ARP response. 746 If no acknowledgement is received in response to a unicast block write 747 request it is uncertain whether or not the data payload was received by 748 the target. 750 NOTE: An acknowledgment may be absent because the target is no longer 751 functional, may not have received the packet because of a header CRC 752 error or may have received the packet successfully but the acknowledge 753 sent in response was corrupted. 755 Unicast IP datagrams that require quality of service other than best- 756 effort are beyond the scope of this standard. 758 8. IP BROADCAST 760 Broadcast IP datagrams are encapsulated according to the specifications 761 of section 4 and are transported by asynchronous stream packets. There 762 is no quality of service provision for IP broadcast over 1394. The 763 channel number used for IP broadcast is specified by the 764 BROADCAST_CHANNEL register. 766 All broadcast IP datagrams SHALL use asynchronous stream packets whose 767 channel number is equal to the channel field from the BROADCAST_CHANNEL 768 register. 770 Although 1394 permits the use of previously allocated channel number(s) 771 for up to one second subsequent to a bus reset, IP-capable nodes SHALL 772 NOT transmit asynchronous stream packets at any time the valid bit in 773 their BROADCAST_CHANNEL register is zero. Since the valid bit is 774 automatically cleared to zero by a bus reset, this prohibits the use of 775 1394 ARP or broadcast IP until the IRM allocates a channel number. 777 9. IP MULTICAST 779 Multicast IP datagrams are encapsulated according to the specifications 780 of section 4 and are transported by stream packets. Asynchronous streams 781 are used for best-effort IP multicast; quality of service other than 782 best-effort is beyond the scope of this standard. 784 By default, all best-effort IP multicast SHALL use asynchronous stream 785 packets whose channel number is equal to the channel field from the 786 BROADCAST_CHANNEL register. In particular, datagrams addressed to 787 224.0.0.1 and 224.0.0.2 SHALL use this channel number. Best-effort IP 788 multicast for other IP multicast group addresses may utilize a different 789 channel number if such a channel number is allocated and advertised 790 prior to use, as described below. 792 IP-capable nodes may transmit best-effort IP multicast only if one of 793 the following two conditions is met: 795 - the channel number in the stream packet is equal to the channel 796 number field in the BROADCAST_CHANNEL register and the valid bit in 797 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 are transported as the data portion of a GASP packet and have the format 818 illustrated below. The first four octets of the message are fixed; the 819 remainder consists of variable-length tuples, each of which encodes 820 information about a particular IP multicast group. Individual MCAP 821 messages SHALL NOT be fragmented and SHALL be encapsulated within a 822 stream packet as ether_type 0x8861. 824 1 2 3 825 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 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | length | reserved | opcode | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | | 830 + message data + 831 | | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 Figure 10 - MCAP message format 836 Field usage in an MCAP message is as follows: 838 length: This field SHALL contain the size, in octets, of the entire 839 MCAP message. 841 opcode: This field SHALL have one of the values specified by the 842 table below. 844 opcode Name Comment 845 +----------------------------------------------------------------+ 846 | 0 | Advertise | Sent by a multicast channel owner to | 847 | | | broadcast the current mapping(s) from one | 848 | | | or more group addresses to their | 849 | | | corresponding channel number(s). | 850 | 1 | Solicit | Sent to request multicast channel owner(s) | 851 | | | to advertise the indicated channel | 852 | | | mapping(s) as soon as possible. | 853 +----------------------------------------------------------------+ 855 message data: The remainder of the MCAP message is variable in length 856 and SHALL consist of zero or more group address descriptors with the 857 format illustrated below. 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 | type | reserved | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | expiration | channel | speed | reserved | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | bandwidth | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | | 869 + group_address + 870 | | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 Figure 11 - MCAP group address descriptor format 875 length: This field SHALL contain the size, in octets, of the MCAP 876 group address descriptor. 878 type: This field SHALL have a value of one, which indicates a group 879 address descriptor. 881 expiration: The usage of this field varies according to opcode. For 882 solicit messages the expiration field SHALL be IGNORED. Otherwise, 883 for advertisements, this field SHALL contain a time-stamp, in 884 seconds, that specifies a future time after which the channel number 885 specified by channel may no longer be used. 887 channel: This field is valid only for advertise messages, in which 888 case it SHALL specify an allocated channel number, in the range zero 889 to 63 inclusive. All other values are RESERVED. 891 speed: This field is valid only for advertise messages, in which case 892 it SHALL specify the speed at which stream packets for the indicated 893 channel are transmitted. Table 2 specifies the encoding used for 894 speed. 896 bandwidth: This field SHALL be zero; it is allocated in the group 897 address descriptor to accommodate future extensions to MCAP that 898 specify quality of service and utilize the isochronous capabilities 899 of Serial Bus. 901 group_address: This variable length field SHALL specify the IP 902 address of a particular IP multicast group. The length of 903 group_address, in octets, is derived from the length of the group 904 address descriptor by subtracting 12 from the length field. 906 9.2 MCAP message domain 908 MCAP messages carry information valid only for the local Serial Bus on 909 which they are transmitted. Recipients of MCAP messages SHALL IGNORE all 910 MCAP messages from other than the local bus, as follows. The source_ID 911 of the sender is contained in the GASP header that precedes the 912 encapsulated MCAP message. A recipient of an MCAP message SHALL examine 913 the most significant ten bits of source_ID from the GASP header; if they 914 are not equal to either 0x3FF or the most significant ten bits of the 915 recipient's NODE_IDS register, the recipient SHALL IGNORE the message. 917 Within an MCAP message domain, the owner of a channel mapping is 918 identified by the source_ID field in the GASP header of an MCAP 919 advertisement. The owner is the node with the largest physical ID, the 920 least significant six bits of source_ID. 922 9.3 Multicast receive 924 An IP-capable device that wishes to receive multicast data SHALL first 925 ascertain the channel mapping (if any) that exists between a group 926 address and a channel number other than the default channel specified by 927 the BROADCAST_CHANNEL register. Such a device may observe the MCAP 928 advertisements on the broadcast channel for the desired channel 929 mapping(s). 931 An intended multicast recipient may transmit MCAP solicitation requests 932 in order to request multicast channel owner(s) to broadcast 933 advertisements sooner than the next ten second interval. Originators of 934 MCAP solicitation requests SHALL limit the rate at which they are 935 transmitted. Subsequent to sending a solicitation request, the 936 originator SHALL NOT send another MCAP solicitation request until ten 937 seconds have elapsed. 939 In either case, if a mapping exists for the group address for other than 940 the default channel, an MCAP advertise message is EXPECTED within ten 941 seconds. Upon receipt of an MCAP advertise message that describes one or 942 more channel mappings, the intended multicast recipient may receive IP 943 datagrams on the indicated channel number(s) until the expiration time. 945 If multiple MCAP advertise messages are observed that specify the same 946 group address, the channel number SHALL be obtained from the 947 advertisement message with the largest physical ID, which SHALL be 948 obtained from the least significant six bits of source_ID from the GASP 949 header. 951 If no MCAP advertise message is received for a particular group address 952 within ten seconds, no multicast source(s) are active for channel(s) 953 other than the default. Either there is there is no multicast data or it 954 is being transmitted on the default channel. 956 Once a multicast recipient has observed an advertisement for the desired 957 group address, it MAY receive multicast data on either the default 958 broadcast channel or the channel number(s) indicated but it SHALL 959 continue to monitor the default broadcast channel for MCAP 960 advertisements for the same group address in order to refresh the 961 expiration time of channel number(s) in use. 963 9.4 Multicast transmit 965 An IP-capable device that wishes to transmit multicast data on other 966 than the default channel SHALL first ascertain whether or not another 967 multicast source has already allocated a channel number for the group 968 address. The intended multicast source may transmit an MCAP solicitation 969 request with one or more group address descriptors. 971 Whether or not a solicitation request has been transmitted, the intended 972 multicast source SHALL monitor the broadcast channel for MCAP 973 advertisements. If a channel mapping already exists for the group 974 address, an MCAP advertisement SHOULD be received within ten seconds. In 975 this case the intended multicast source may commence transmission of IP 976 datagrams on the indicated channel number(s) and may continue to do so 977 until their expiration time. The multicast source SHALL monitor MCAP 978 advertisements in order to refresh the expiration time of channel 979 number(s) in use. 981 When no other multicast source has established a channel mapping for the 982 group address, the intended multicast source may attempt to allocate a 983 channel number from the isochronous resource manager's 984 CHANNELS_AVAILABLE register according to the procedures described in 985 IEEE P1394a. If the channel number allocation is successful, the 986 multicast source SHALL advertise the new channel mapping(s) as soon as 987 possible. Once 100 ms elapses subsequent to the initial advertisement of 988 a newly allocated channel number , the multicast source may transmit IP 989 datagrams using the channel number advertised. 991 Multicast IP datagrams may be transmitted on the default channel until 992 the sender observes (or transmits) an advertisement that specifies non- 993 default channel mapping(s) for the multicast addresses. This permits the 994 smooth transition of multicast from the default channel to an explicitly 995 allocated channel. 997 Once a multicast source has advertised a channel mapping, it SHALL 998 continue to transmit MCAP advertisements for the channel mapping unless 999 it either a) transfers ownership to another multicast source, b) permits 1000 the channel mapping to expire without transfer or c) in the case of 1001 overlapped channel mappings, relinquishes control of the channel mapping 1002 to another multicast source. 1004 9.5 Advertisement of channel mappings 1006 Each multicast source SHALL periodically broadcast an advertisement of 1007 all IP multicast group addresses for which it has allocated a channel 1008 number different from the default multicast channel number. An 1009 advertisement SHALL consist of a single MCAP message with an opcode of 1010 zero that contains one or more group address descriptors (one for each 1011 group address assigned a channel number other than that specified by the 1012 BROADCAST_CHANNEL register). 1014 Within each group address descriptor, the group_address and channel 1015 fields associate an IP multicast group address with a Serial Bus channel 1016 number. The speed field specifies the maximum 1394 speed at which any of 1017 the senders within the IP multicast group is permitted to transmit data. 1018 The expiration field specifies the current time or a future time after 1019 which the channel mapping(s) are no longer valid. Except when a channel 1020 owner intends to relinquish ownership (as described in 9.7 below), the 1021 expiration time SHALL be at least 60 seconds in the future measured from 1022 the time the advertisement is transmitted. 1024 No more than ten seconds SHALL elapse from the transmission of its most 1025 recent advertisement before the owner of a channel mapping initiates 1026 transmission of the subsequent advertisement. The owner of a channel 1027 mapping SHOULD transmit an MCAP advertisement in response to a 1028 solicitation as soon as possible after the receipt of the request. 1030 9.6 Overlapped channel mappings 1032 When two intended multicast sources wish to transmit to the same IP 1033 multicast group and no channel mapping exists for the group address, 1034 there is a chance that both will allocate channel numbers and both will 1035 advertise the channel mappings. These channel mappings overlap, i.e., 1036 the same group address is mapped to more than one channel number in MCAP 1037 advertisements with nonzero expiration times. 1039 Multicast channel owners SHALL monitor MCAP advertisements in order to 1040 detect overlapped channel mappings. MCAP advertisements whose expiration 1041 field has a value less than 60 SHALL be ignored for the purpose of 1042 overlapped channel detection. When an overlapped channel mapping is 1043 detected, the owner with the largest physical ID (as determined by the 1044 least significant six bits of source_ID from the GASP header) is NOT 1045 REQUIRED to take any action. The channel numbers advertised by owners 1046 with smaller physical IDs are invalid; their owners SHALL cease 1047 transmission of both IP datagrams and MCAP advertisements that use the 1048 invalid channel numbers. As soon as these channel mappings expire , 1049 their owners SHALL deallocate any unused channel numbers as described in 1050 9.8 below. 1052 Recipients of MCAP advertisements that detect overlapped channel 1053 mappings SHALL ignore the advertisements from multicast channel owner(s) 1054 with the smaller physical IDs and SHALL NOT transmit IP datagrams that 1055 use the invalid channel number. It is possible for some channel mappings 1056 in a single MCAP advertisement to be valid even if others SHALL be 1057 IGNORED as a result of overlap. 1059 9.7 Transfer of channel ownership 1061 The owner of a channel mapping may cease multicast transmission on a 1062 particular channel, in which case it SHOULD invalidate the channel 1063 mapping and in some cases deallocate the channel number. Because other 1064 multicast sources may be using the same channel mapping, an orderly 1065 process is defined to transfer channel ownership. 1067 The owner of an existing channel mapping that wishes to release the 1068 mapping SHALL commence a timer to measure the time remaining before the 1069 anticipated release of the mapping and its associated channel. Until the 1070 timer counts down to zero, the owner SHOULD continue to transmit MCAP 1071 advertisements for the affected channel but SHALL adjust expiration in 1072 each advertisement to reflect the time remaining until the channel is to 1073 be deallocated. If the owner is unable to transmit MCAP advertisements 1074 until the timer reaches zero, it SHALL initiate a bus reset. Otherwise, 1075 the sequence of expiration times transmitted by the owner intending to 1076 release the mapping SHALL decrease with each succeeding advertisement. 1077 If other multicast source(s) are using the same channel mapping and 1078 observe an expiration time less than or equal to 60 seconds, they SHALL 1079 commence transmitting MCAP advertisements for the channel mapping with 1080 refreshed expiration times greater than or equal to 60 seconds that 1081 maintain the channel mapping. Any contention that occurs between 1082 multiple sources that attempt to claim ownership of the channel mapping 1083 SHALL be resolved as described in 9.8. If the original owner observes an 1084 MCAP advertisement for the channel to be relinquished before its own 1085 timer has expired, it SHALL NOT deallocate the channel number. 1087 Otherwise, if the owner's timer expires without the observation of a 1088 MCAP advertisement by another node, the owner of the channel number 1089 SHALL subsequently deallocate the channel as described in 9.8. If the 1090 intended owner of the channel mapping observes an MCAP advertisement 1091 whose expiration field is zero, orderly transfer of the channel(s) from 1092 the former owner has failed. The intended owner SHALL either stop 1093 reception and transmission on the expired channel number(s) or allocate 1094 different channel number(s) as specified by 9.4. 1096 9.8 Redundant channel mappings 1098 When ownership of a channel mapping is transferred from one multicast 1099 source to another, it is possible for more than one device to claim 1100 ownership. This results in redundant MCAP advertisements, transmitted by 1101 different sources, each of which specifies the same multicast group 1102 address and channel. A procedure similar to that of 9.6 SHALL resolve 1103 the contention for channel ownership. 1105 Multicast channel owners SHALL monitor MCAP advertisements in order to 1106 detect redundant channel mappings. MCAP advertisements whose expiration 1107 field has a value less than 60 SHALL be ignored for the purpose of 1108 redundant channel detection. When a redundant channel mapping is 1109 detected, the owner with the largest physical ID (as determined by the 1110 least significant six bits of source_ID from the GASP header) is NOT 1111 REQUIRED to take any action. The owner(s) with smaller physical IDs 1112 SHALL cease transmission of MCAP advertisements for the redundant 1113 channel number but SHALL NOT deallocate the channel number. 1115 9.9 Expired channel mappings 1117 A channel mapping expires when expiration seconds have elapsed since the 1118 most recent MCAP advertisement. At this time, multicast recipients SHALL 1119 stop reception on the expired channel number(s). Also at this time, the 1120 owner of the channel mapping(s) SHALL transmit an MCAP advertisement 1121 with expiration cleared to zero and SHALL continue to transmit such 1122 advertisements until 30 seconds have elapsed since the expiration of the 1123 channel mapping. Once this additional 30-second period has elapsed, the 1124 owner of the channel mapping(s) SHALL deallocate the channel number(s) 1125 and indicate their availability in the isochronous resource manager's 1126 CHANNELS_AVAILABLE register. 1128 If an IP-capable device observes an MCAP advertisement whose expiration 1129 field is zero, it SHALL NOT attempt to allocate any of the channel 1130 number(s) specified until 30 seconds have elapsed since the most recent 1131 such advertisement. 1133 9.10 Bus reset 1135 A bus reset SHALL invalidate all multicast channel mappings and SHALL 1136 cause all multicast recipients and senders to zero all MCAP 1137 advertisement interval timers. 1139 Prior owners of multicast channel mappings may reallocate a channel 1140 number from the isochronous resource manager's CHANNELS_AVAILABLE 1141 register and resume broadcast of MCAP advertisements as soon as a 1142 channel is allocated. If channel reallocation is attempted, the prior 1143 owner SHOULD use the same channel number allocated prior to the bus 1144 reset and may commence reallocation immediately upon completion of the 1145 bus reset so long as the same channel number is reused. If the prior 1146 owner elects to allocate a different channel number, it SHALL wait until 1147 at least one second has elapsed since the completion of the bus reset 1148 before attempting to allocate a new channel number. 1150 Intended or prior recipients or transmitters of multicast on other than 1151 the default channel SHALL NOT transmit MCAP solicitation requests until 1152 at least ten seconds have elapsed since the completion of the bus reset. 1153 Multicast data on other than the default channel SHALL NOT be received 1154 or transmitted until an MCAP advertisement is observed or transmitted 1155 for the IP multicast group address. 1157 Intended or prior transmitters of multicast on other than the default 1158 channel that did not own a channel mapping for the IP multicast group 1159 address prior to the bus reset SHALL NOT attempt to allocate a channel 1160 number from the isochronous resource manager's CHANNELS_AVAILABLE 1161 register until at least ten seconds have elapsed since the completion of 1162 the bus reset. Subsequent to this ten second delay, intended or prior 1163 transmitters of multicast may follow the procedures specified by 9.4 to 1164 allocate a channel number and advertise the channel mapping. 1166 10. IANA CONSIDERATIONS 1168 This document necessitates the creation and management of a new name 1169 space (registry) by IANA. The need for such a registry arises out of the 1170 method by which protocol interfaces are uniquely identified by bus 1171 standards compliant with ISO/IEC 13213:1994, CSR Architecture. This is 1172 explained in more detail in section 6; the essence is that a globally 1173 unique 48-bit number SHALL identify the document that specifies the 1174 protocol interface. The 48-bit number is the concatenation of 0x00 005E 1175 (a registration ID, or RID, granted to IANA by the IEEE Registration 1176 Authority) and a second 24-bit number administered by IANA. 1178 The IEEE RA RECOMMENDS that the policy for management of the second 1179 24-bit number be chosen to maximize the quantity of usable numbers with 1180 the range of possible values. In particular, the IEEE RA RECOMMENDS that 1181 the assignment scheme not apply a structure to the number (e.g., the 1182 allocation of a version field within the number) since this would tend 1183 to waste large portions of the range. 1185 The new name space is "CSR Protocol Identifiers". The values zero and 1186 0xFF FFFF are reserved and SHALL NOT be allocated by IANA. The value one 1187 is allocated to this document. The remaining numbers SHALL be managed by 1188 IANA and allocated as necessary to identify Internet-Drafts that become 1189 IESG standards track documents. 1191 Regardless of the assignment method elected by IANA, a registry of all 1192 assigned version numbers SHOULD be maintained at one or more Internet 1193 sites and should clearly identify the relevant standard identified by 1194 the combination of the RID and version number. 1196 11. SECURITY CONSIDERATIONS 1198 This document specifies the use of an unsecured link layer, Serial Bus, 1199 for the transport of IPv4 datagrams. Serial Bus is vulnerable to denial 1200 of service attacks; it is also possible for devices to eavesdrop on data 1201 or present forged identities. Implementers who utilize Serial Bus for 1202 IPv4 SHOULD consider appropriate counter-measures within application or 1203 other layers. 1205 12. ACKNOWLEDGEMENTS 1207 This document represents work in progress by the IP/1394 Working Group. 1208 The editor wishes to acknowledge the contributions made by all the 1209 active participants, either on the reflector or at face-to-face 1210 meetings, which have advanced the technical content. 1212 13. REFERENCES 1214 Normative reference to standards under development at the time of this 1215 document's publication shall utilize the most current draft until such 1216 time as it is replaced by an approved standard. 1218 [1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus 1220 [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture 1221 for Microcomputer Buses 1223 [3] IEEE Project P1394a, Draft Standard for a High Performance Serial 1224 Bus (Supplement) 1226 [4] IEEE Project P1394b, Draft Standard for a High Performance Serial 1227 Bus (Supplement) 1229 14. EDITOR'S ADDRESS 1231 Peter Johansson 1232 Congruent Software, Inc. 1233 98 Colorado Avenue 1234 Berkeley, CA 94602 1235 (510) 527-3926 1236 (510) 527-3856 FAX 1237 pjohansson@aol.com