idnits 2.17.1 draft-ietf-ip1394-mcap-00.txt: -(65): 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-04-26) 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. ** 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 2 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 12 longer pages, the longest (page 2) 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 247 instances of too long lines in the document, the longest one being 6 characters in excess of 72. 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 534, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 536, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 539, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 542, 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: 10 errors (**), 0 flaws (~~), 7 warnings (==), 6 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: October, 1998 7 Multicast Channel Allocation Protocol (MCAP) for IEEE 1394 9 STATUS OF THIS DOCUMENT 11 This docuent is an Internet-Draft. Internet-Drafts are working 12 docuents of the Internet Engineering Task Force (IETF), its areas, and 13 its working groups. Note that other groups ay also distribute working 14 docuents as Internet-Drafts. 16 Internet-Drafts are draft docuents valid for a maximum of six months 17 and ay be updated, replaced, or obsoleted by other documents at any 18 tie. It is inappropriate to use Internet-Drafts as reference material 19 or to cite the 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 unnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 ABSTRACT 29 This docuent specifies how IP-capable Serial Bus devices may allocate 30 IEEE 1394 channel nuber(s) for use in the multicast transmission of IP 31 datagras. It defines the necessary methods, data structures and codes 32 for that purpose. 34 See also the ost recent revision of draft-ietf-ip1394-ipv4 for a 35 specification of the transport of IPv4 datagras over IEEE 1394. 37 CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe 38 parts reflect rough consensus achieved at the 41st IETF eeting in Los 39 Angeles, other parts reflect the editor's distillation of coments on 40 the reflector since then and still other parts are new contributions to 41 the evolution of MCAP. Until subsequent revisions of this docuent are 42 posted that ore clearly identify agreed areas, the reader should 43 consider this a work in progress very uch subject to revision. This 44 docuent is not yet adopted by the IP/1394 working group. 46 TABLE OF CONTENTS 48 1. INTRODUCTION.......................................................3 49 2. DEFINITIONS AND NOTATION...........................................3 50 2.1 Conforance....................................................3 51 2.2 Glossary.......................................................4 52 2.3 Abbreviations..................................................4 53 3. CHANNEL ALLOCATION MANAGER.........................................5 54 4. MCAP MESSAGE FORMAT................................................5 55 5. MCAP OPERATIONS....................................................7 56 5.1 Advertiseent of channel mappings..............................8 57 5.2 Request for channel allocation.................................8 58 5.3 Error response to channel allocation...........................9 59 5.4 Release of unneeded channel(s).................................9 60 5.5 Solicitation of the channel ap...............................10 61 5.6 Periodic refresh of channel allocation(s).....................10 62 6. SECURITY CONSIDERATIONS...........................................11 63 7. ACKNOWLEDGEMENTS..................................................11 64 8. REFERENCES........................................................11 65 9. EDITOR�S ADDRESS..................................................12 66 1. INTRODUCTION 68 This docuent specifies how IP-capable Serial Bus devices may allocate 69 IEEE 1394 channel nuber(s) for use in the multicast transmission of IP 70 datagras. It defines the necessary methods, data structures and codes 71 for that purpose. 73 The group of IEEE standards and suppleents, draft or approved, related 74 to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as 75 Serial Bus. 77 The draft specification for the transport of IPv4 datagras over 1394, 78 draft-ietf-ip1394-ipv4, requires broadcast and multicast IP datagrams to 79 be transported within 1394 asynchronous streas. Before an asynchronous 80 strea may be used it is necessary to allocate a 1394 resource, a 81 channel nuber. The IPv4 draft specification describes how a channel 82 nuber is allocated for all broadcast IP datagrams; this same channel 83 nuber is also used, by default, for multicast traffic. 85 In cases where it is desirable to use a different channel nuber for 86 particular multicast groups, methods are needed to allocate a channel 87 nuber, advertise its existence and ultimately deallocate the channel 88 nuber when it is no longer needed. This document describes such methods 89 and naes them "multicast channel allocation protocol" (MCAP). 91 Although the definition of MCAP is otivated by the particular 92 requireents of 1394, the methods are extensible to other link media. 94 CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe 95 parts reflect rough consensus achieved at the 41st IETF eeting in Los 96 Angeles, other parts reflect the editor's distillation of coments on 97 the reflector since then and still other parts are new contributions to 98 the evolution of MCAP. Until subsequent revisions of this docuent are 99 posted that ore clearly identify agreed areas, the reader should 100 consider this a work in progress very uch subject to revision. This 101 docuent is not yet adopted by the IP/1394 working group. 103 2. DEFINITIONS AND NOTATION 105 2.1 Conforance 107 When used in this docuent, the keywords "may", "optional", 108 "recomended", "required", "shall" and "should" differentiate levels of 109 requireents and optionality and are to be interpreted as described in 110 RFC 2119. 112 Several additional keywords are eployed, as follows: 114 expected: A keyword used to describe the behavior of the hardware or 115 software in the design odels assumed by this standard. Other hardware 116 and software design odels may also be implemented. 118 ignored: A keyword that describes bits, octets, quadlets or fields whose 119 values are not checked by the recipient. 121 reserved: A keyword used to describe objects---bits, octets, quadlets 122 and fields---or the code values assigned to these objects in cases where 123 either the object or the code value is set aside for future 124 standardization. Usage and interpretation ay be specified by future 125 extensions to this or other standards. A reserved object shall be zeroed 126 or, upon developent of a future standard, set to a value specified by 127 such a standard. The recipient of a reserved object shall not check its 128 value. The recipient of an object defined by this standard as other than 129 reserved shall check its value and reject reserved code values. 131 2.2 Glossary 133 The following ters are used in this standard: 135 bus ID: A 10-bit nuber that uniquely identifies a particular bus within 136 a group of ultiple interconnected buses. The bus ID is the most 137 significant portion of a node's 16-bit node ID. The value 0x3FF 138 designates the local bus; a node shall respond to requests addressed to 139 its 6-bit physical ID if the bus ID in the request is either 0x3FF or 140 the bus ID explicitly assigned to the node. 142 IP datagra: An Internet message that conforms to the format specified 143 by RFC 791. 145 node ID: A 16-bit nuber that uniquely identifies a Serial Bus node 146 within a group of ultiple interconnected buses. The most significant 10 147 bits are the bus ID and the least significant 6 bits are the physical 148 ID. 150 octet: Eight bits of data. 152 packet: Any of the 1394 priary packets; these may be read, write or 153 lock requests (and their responses) or strea data. The term "packet" is 154 used consistently to differentiate 1394 packets fro ARP 155 requests/responses or IP datagras. 157 physical ID: On a particular bus, this 6-bit nuber is dynamically 158 assigned during the self-identification process and uniquely identifies 159 a node on that bus. 161 quadlet: Four octets, or 32 bits, of data. 163 strea packet: A 1394 primary packet with a transaction code of 0x0A 164 that contains a block data payload. Strea packets may be either 165 asynchronous or isochronous according to the type of 1394 arbitration 166 eployed. 168 2.3 Abbreviations 170 The following are abbreviations that are used in this standard: 172 CAM Channel allocation anager 173 MCAP Multicast channel allocation protocol 174 IP Internet protocol (within the context of this docuent, IPv4) 176 3. CHANNEL ALLOCATION MANAGER 178 MCAP requires the presence of a channel allocation anager (CAM) to 179 process requests, allocate or deallocate Serial Bus channel nubers and 180 advertise the apping from group addresses to their corresponding 181 channels. 183 The identity of the CAM and the ethod of its selection have not yet 184 been discussed by the working group. 186 Consensus has been reached that the CAM listens for essages (whose 187 forat is described below) on the default multicast channel specified by 188 the NETWORK_CHANNELS register and transits advertisements and other 189 responses on the sae channel. The details of CAM operations are 190 described in section 5. 192 4. MCAP MESSAGE FORMAT 194 MCAP essages, whether sent by a multicast source or recipient or the 195 CAM, share a comon format illustrated below. The first eight octets of 196 the essage are fixed; the remainder consists of variable-length tuples, 197 each of which encodes inforation about a particular multicast group. 199 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | length | checksu | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | bus_ID | reserved | opcode | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 + essage data + 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 5 - MCAP essage format 213 Field usage in an MCAP essage is as follows: 215 length: This field shall contain the size, in octets, of the entire 216 MCAP essage. 218 checksu: This field shall contain a checksum calculated on the 219 entire MCAP essage. The checksum shall be one's complement of the 220 su of all the 16-bit words in the message; arithmetic overflow is 221 discarded. For the purpose of calculating the checksu, the checksum 222 field is treated as if zero. 224 bus_ID: This field shall specify the 10-bit bus ID for which 225 inforation in the MCAP message is valid. The value of bus_ID shall 226 be equal to the ost significant 10 bits of the sender's NODE_IDS 227 register. 229 opcode: This field shall have one of the values specified by table 1 230 below. 232 Table 1 - MCAP opcode values 234 opcode Nae Comment 235 +----------------------------------------------------------------+ 236 | 0 | Advertise | Sent by the CAM to broadcast the current | 237 | | | apping from each group address to its | 238 | | | corresponding channel nuber. | 239 | 1 | Request | Sent by a multicast source to request the | 240 | | | allocation of a channel nuber or to | 241 | | | refresh the reaining lifetime of a | 242 | | | channel nuber allocation. | 243 | 2 | Release | Optionally sent by a multicast source to | 244 | | | release a channel nuber at a future time. | 245 | 3 | Error | Sent by the CAM when it is unable to | 246 | | | satisfy a channel nuber allocation | 247 | | | request. | 248 | 4 | Solicit | Sent to request the CAM advertise the | 249 | | | current channel apping(s) as soon as | 250 | | | possible. | 251 +----------------------------------------------------------------+ 253 essage data: The remainder of the MCAP message is variable in length 254 and shall consist of zero or ore group address descriptors with the 255 forat illustrated below. 257 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | length | type | reserved | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | expiration | channel | speed | status | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | bandwidth | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | | 267 + group_address + 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 5 - MCAP group address descriptor forat 273 length: This field shall contain the size, in octets, of the MCAP 274 group address descriptor. 276 type: This field shall have a value of one, which indicates a group 277 address descriptor. 279 expiration: The usage of this field varies according to opcode. For 280 solicit and error essages the expiration field shall be ignored. 281 Otherwise this field shall contain a tie-stamp, in seconds, that 282 specifies a future tie for the release of the channel number 283 specified by channel. Tie is expressed in terms of the 284 CYCLE_TIME.seconds and a atch occurs when expiration equals the most 285 significant seven bits of the CYCLE_TIME register. 287 channel: This field shall specify either a valid channel nuber, in 288 the range zero to 63 inclusive, or else indicate an invalid channel 289 nuber with a value of 0xFF. All other values are reserved. The usage 290 of this field varies according to opcode, as shown in the table 291 below. 293 Operation Usage of channel 294 +----------------------------------------------+ 295 | Advertise | Channel nuber allocated for the | 296 | | multicast group_address | 297 | Request | Suggested channel nuber (hint) | 298 | Release | Ignored | 299 | Error | Ignored | 300 | Solicit | Ignored | 301 +----------------------------------------------+ 303 speed: This field shall be ignored except for advertise and request 304 essages, in which case it shall specify the speed at which stream 305 packets for the indicated channel are transitted. The encoding used 306 for speed is specified by the table below; all values not specified 307 are reserved. 309 Value Speed 310 +---------------+ 311 | 0 | S100 | 312 | 1 | S200 | 313 | 2 | S400 | 314 | 3 | S800 | 315 | 4 | S1600 | 316 | 5 | S3200 | 317 +---------------+ 319 status: This field shall be ignored except for error essages, in 320 which case it shall characterize the reason(s) the CAM did not 321 allocate a requested channel nuber. The encoding for this field is 322 yet to be deterined. 324 bandwidth: This field shall be ignored; it is allocated in the group 325 address descriptor to accomodate future extensions to MCAP that 326 specify quality of service and utilize the isochronous capabilities 327 of Serial Bus. 329 group_address: This variable length field shall specify the IP 330 address of a particular multicast group. The length of group_address, 331 in octets, is derived fro the length of the group address descriptor 332 by subtracting 12 fro the length field. 334 5. MCAP OPERATIONS 335 MCAP is a cooperative protocol iplemented by multicast senders and 336 recipients and the CAM. The participants exchange essages over the 337 default multicast channel used by all IP-capable nodes on a particular 338 Serial Bus. 340 The bus_ID field in all MCAP essages shall be equal to the most 341 significant 10 bits of the sender's NODE_IDS register. 343 5.1 Advertiseent of channel mappings 345 The CAM shall periodically broadcast an advertiseent of all multicast 346 group addresses allocated a channel nuber that differs from the default 347 multicast channel number. An advertisement shall consist of a single 348 MCAP essage with an opcode of zero which contains zero or more group 349 address descriptors (one for each group address assigned a channel 350 nuber other than that specified by the NETWORK_CHANNELS register). 352 Within each group address descriptor, the group_address and channel 353 fields associate a multicast group address with a Serial Bus channel 354 nuber. More than one multicast group address may be mapped to a single 355 Serial Bus channel nuber by means of separate group address 356 descriptors. The speed field specifies the aximum 1394 speed at which 357 any of the senders within the multicast group transmits data. The 358 expiration field specifies a future tie when the CAM will deallocate 359 the channel nuber. 361 No ore than ten seconds shall elapse from the transmission of the most 362 recent advertiseent before the CAM initiates transmission of the 363 subsequent advertiseent. 365 5.2 Request for channel allocation 367 Before any multicast transmission on other than the default channel 368 nuber specified by the NETWORK_CHANNELS register, a sender within a 369 multicast group shall insure that the CAM has allocated a channel 370 nuber. 372 A multicast sender should first listen for an MCAP advertisement. If the 373 multicast group address is already mapped to a channel number, the 374 sender need not ake a channel allocation request and may use the 375 advertised channel nuber for multicast transmission. 377 Otherwise the intended multicast sender shall transmit an MCAP message 378 with an opcode of one which contains one or ore group address 379 descriptors. Within each group address descriptor the group_address 380 field shall specify the multicast group address for which a channel 381 nuber is requested. If the requester has reasons to prefer a particular 382 channel nuber, this may be specified as a hint in the channel field but 383 the CAM is not obligated to allocate that channel. The intended 384 multicast sender shall also specify, for each multicast group address, 385 the aximum speed at which it intends to transmit data and the 386 expiration tie for the channel allocation. 388 When the CAM receives an MCAP request for channel allocation(s), it 389 shall attept to allocate a channel number in accordance with its own 390 policies and the availability of Serial Bus channel nuber(s). 392 If a channel is already allocated for the specified group_address, the 393 CAM shall take no additional action other than to confir the channel 394 nuber mapping in the next MCAP advertisement. If the channel number 395 hint in the allocation request differs fro the channel number actually 396 allocated, the CAM should transit an advertisement as soon as possible. 397 Otherwise the advertiseent should be transmitted at the next scheduled 398 tie. 400 If no channel is allocated for the specified group_address, the CAM 401 shall select a channel nuber and attempt to allocate it from the 402 isochronous resource anager's CHANNELS_AVAILABLE register. The 403 selection criteria shall be based upon the channel hint supplied in the 404 request and the CAM's own policies; a value of 0xFF for channel 405 indicates that the requester has provided no hint. If the chosen channel 406 nuber is unavailable, the CAM may attempt to allocate a different 407 channel nuber from CHANNELS_AVAILABLE. The retry algorithms are subject 408 to policies iplemented by the CAM (e.g., some implementations might not 409 allocate the last available channel but elect to aggregate multicast 410 group addresses to already allocated channel(s)). 412 When the CAM successfully allocates a channel nuber or assigns the 413 multicast group address to an already allocated channel number, the new 414 apping from multicast group address to channel number shall be 415 advertised as soon as possible. The MCAP advertiseent constitutes a 416 response to the channel allocation request and perits the multicast 417 sender to comence transmissions. 419 Otherwise, the CAM shall transit an error response as described below. 421 5.3 Error response to channel allocation 423 The CAM shall transit an MCAP error response message whenever one or 424 ore multicast group addresses specified in an MCAP channel allocation 425 request essage have not been mapped to other than the default multicast 426 channel nuber. 428 Multicast channel allocation ay fail because no channel numbers are 429 available or because CAM policy prevents the allocation. For whatever 430 reason, the MCAP error response essage shall contain a group address 431 descriptor for each failure. The group_address field shall identify the 432 multicast group and the status field shall contain a code that indicates 433 the nature of the error. All other fields within the group address 434 descriptor shall be ignored. 436 5.4 Release of unneeded channel(s) 438 When a multicast sender intends to cease transmissions for a multicast 439 group that is not apped to the default multicast channel, it may notify 440 the CAM by eans of an MCAP release message. The usage of the release 441 essage is optional, since the CAM will automatically deallocate the 442 channel nuber when its expiration time is reached. 444 An MCAP release essage has an opcode value of three and contains one or 445 ore group address descriptors. Each descriptor identifies the 446 group_address whose channel nuber is to be released. The expiration 447 field shall specify a tie at least 30 seconds in the future for the 448 release of the channel nuber. All other fields within the group address 449 descriptor shall be ignored. 451 In response to an MCAP release essage that identifies a group_address 452 in the current channel ap, the CAM shall update the expiration time for 453 the channel with the value of expiration and shall transit an MCAP 454 advertiseent message as soon as possible. The advertisement that 455 reflects the updated expiration tie is the response expected by the 456 sender of the MCAP release essage. 458 Whether multicast senders utilize the optional MCAP release message or 459 not, channel allocations eventually expire for unused channel nubers. 460 When the expiration tie associated with a particular multicast group 461 and associated channel is reached (as easured by the CAM's CYCLE_TIME 462 register), the CAM shall reove the multicast group and channel number 463 fro the current channel map. Once the CAM has transmitted an MCAP 464 advertiseent message in which no group descriptors reference a 465 previously allocated channel nuber, the CAM shall deallocate the 466 channel nuber in the isochronous resource manager's CHANNELS_AVAILABLE 467 register. 469 5.5 Solicitation of the channel ap 471 Multicast recipients or senders ay request the CAM to advertise the 472 channel ap by transmitting an MCAP solicitation request. No group 473 address descriptors are included with this essage; the opcode value of 474 five requests the CAM identified by bus_ID to advertise the channel ap. 476 Originators of MCAP solicitation requests shall liit the rate at which 477 they are transitted. Subsequent to sending a solicitation request, 478 neither the originator nor any other node that observes the request 479 shall send another MCAP solicitation request until either a) 10 seconds 480 have expired or b) an MCAP advertiseent has been observed. 482 The CAM should transit an MCAP advertisement message as soon as 483 possible in response to the solicitation request. 485 5.6 Periodic refresh of channel allocation(s) 487 As described in 5.4 above, the CAM shall reove expired multicast group 488 address and channel nuber pairs from the current channel map and 489 ultiately return channel number(s) to the CHANNELS_AVAILABLE pool when 490 no longer used by any multicast group. 492 In order to prevent this occurrence for active multicast groups, at 493 least one sender within a multicast group shall periodically extend the 494 expiration tie for the channel map by means of an MCAP channel 495 allocation request essage (see 5.1). Although the CAM does not allocate 496 a new channel, the request causes the expiration tie to be updated to a 497 new future value. The frequency of MCAP channel allocation request 498 essages and the expiration time specified in each should be coordinated 499 such that at least three request essages are transmitted before the 500 expiration tie specified by the earliest of the three is reached. 502 In multicast groups where there is more than one sender it is desirable 503 to liit the number of MCAP channel allocation request messages. The 504 ideal situation is for one sender to generate the requests. If this 505 sender intends to leave the multicast group, one of two events occur: 506 either the sender transits the optional MCAP release message or it 507 ceases transission of allocation request messages. In the first case, 508 one of the other senders within the multicast group is expected to 509 observe the release essage and initiate its own transmission of MCAP 510 channel allocation request essages. Otherwise, if the time remaining 511 before channel expiration falls below two seconds, that sender should 512 initiate its own transission of MCAP channel allocation request 513 essages. In the latter case, the allocation request shall be 514 transitted at least one second before the expiration time. 516 6. SECURITY CONSIDERATIONS 518 This docuent specifies the use of an unsecured link layer, Serial Bus, 519 for the transport of IPv4 datagras. Serial Bus is vulnerable to denial 520 of service attacks; it is also possible for devices to eavesdrop on data 521 or present forged identities. Iplementers who utilize Serial Bus for 522 IPv4 should consider appropriate counter-easures within application or 523 other layers. 525 7. ACKNOWLEDGEMENTS 527 This docuent represents work in progress by the IP/1394 Working Group. 528 The editor wishes to acknowledge the contributions ade by all the 529 active participants, either on the reflector or at face-to-face 530 eetings, which have advanced the technical content. 532 8. REFERENCES 534 [1] IEEE Std 1394-1995, Standard for a High Perforance Serial Bus 536 [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture 537 for Microcoputer Buses 539 [3] IEEE Project P1394a, Draft Standard for a High Perforance Serial 540 Bus (Suppleent) 542 [4] IEEE Project P1394b, Draft Standard for a High Perforance Serial 543 Bus (Suppleent) 544 9. EDITOR�S ADDRESS 546 Peter Johansson 547 Congruent Software, Inc. 548 3998 Whittle Avenue 549 Oakland, CA 94602 551 (510) 531-5472 552 (510) 531-2942 FAX 553 pjohansson@aol.co