Network Working Group P. Johansson Internet-Draft Congruent Software, Inc. Expires: October, 1998 Multicast Channel Allocation Protocol (MCAP) for IEEE 1394 STATUS OF THIS DOCUMENT This docuent is an Internet-Draft. Internet-Drafts are working docuents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups ay also distribute working docuents as Internet-Drafts. Internet-Drafts are draft docuents valid for a maximum of six months and ay be updated, replaced, or obsoleted by other documents at any tie. It is inappropriate to use Internet-Drafts as reference material or to cite the other than as "work in progress." To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), unnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). ABSTRACT This docuent specifies how IP-capable Serial Bus devices may allocate IEEE 1394 channel nuber(s) for use in the multicast transmission of IP datagras. It defines the necessary methods, data structures and codes for that purpose. See also the ost recent revision of draft-ietf-ip1394-ipv4 for a specification of the transport of IPv4 datagras over IEEE 1394. CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe parts reflect rough consensus achieved at the 41st IETF eeting in Los Angeles, other parts reflect the editor's distillation of coments on the reflector since then and still other parts are new contributions to the evolution of MCAP. Until subsequent revisions of this docuent are posted that ore clearly identify agreed areas, the reader should consider this a work in progress very uch subject to revision. This docuent is not yet adopted by the IP/1394 working group. Expire: October, 1998 [Page 1] Internet-Draft 00 1394 MCAP April 1998 TABLE OF CONTENTS 1. INTRODUCTION.......................................................3 2. DEFINITIONS AND NOTATION...........................................3 2.1 Conforance....................................................3 2.2 Glossary.......................................................4 2.3 Abbreviations..................................................4 3. CHANNEL ALLOCATION MANAGER.........................................5 4. MCAP MESSAGE FORMAT................................................5 5. MCAP OPERATIONS....................................................7 5.1 Advertiseent of channel mappings..............................8 5.2 Request for channel allocation.................................8 5.3 Error response to channel allocation...........................9 5.4 Release of unneeded channel(s).................................9 5.5 Solicitation of the channel ap...............................10 5.6 Periodic refresh of channel allocation(s).....................10 6. SECURITY CONSIDERATIONS...........................................11 7. ACKNOWLEDGEMENTS..................................................11 8. REFERENCES........................................................11 9. EDITOR’S ADDRESS..................................................12 Expires: October, 1998 [Page 2] Internet-Draft 00 1394 MCAP April 1998 1. INTRODUCTION This docuent specifies how IP-capable Serial Bus devices may allocate IEEE 1394 channel nuber(s) for use in the multicast transmission of IP datagras. It defines the necessary methods, data structures and codes for that purpose. The group of IEEE standards and suppleents, draft or approved, related to IEEE Std 1394-1995 is hereafter referred to either as 1394 or as Serial Bus. The draft specification for the transport of IPv4 datagras over 1394, draft-ietf-ip1394-ipv4, requires broadcast and multicast IP datagrams to be transported within 1394 asynchronous streas. Before an asynchronous strea may be used it is necessary to allocate a 1394 resource, a channel nuber. The IPv4 draft specification describes how a channel nuber is allocated for all broadcast IP datagrams; this same channel nuber is also used, by default, for multicast traffic. In cases where it is desirable to use a different channel nuber for particular multicast groups, methods are needed to allocate a channel nuber, advertise its existence and ultimately deallocate the channel nuber when it is no longer needed. This document describes such methods and naes them "multicast channel allocation protocol" (MCAP). Although the definition of MCAP is otivated by the particular requireents of 1394, the methods are extensible to other link media. CAUTION: This is a WORKING DOCUMENT of the IETF IP/1394 group; soe parts reflect rough consensus achieved at the 41st IETF eeting in Los Angeles, other parts reflect the editor's distillation of coments on the reflector since then and still other parts are new contributions to the evolution of MCAP. Until subsequent revisions of this docuent are posted that ore clearly identify agreed areas, the reader should consider this a work in progress very uch subject to revision. This docuent is not yet adopted by the IP/1394 working group. 2. DEFINITIONS AND NOTATION 2.1 Conforance When used in this docuent, the keywords "may", "optional", "recomended", "required", "shall" and "should" differentiate levels of requireents and optionality and are to be interpreted as described in RFC 2119. Several additional keywords are eployed, as follows: expected: A keyword used to describe the behavior of the hardware or software in the design odels assumed by this standard. Other hardware and software design odels may also be implemented. ignored: A keyword that describes bits, octets, quadlets or fields whose values are not checked by the recipient. Expires: October, 1998 [Page 3] Internet-Draft 00 1394 MCAP April 1998 reserved: A keyword used to describe objects---bits, octets, quadlets and fields---or the code values assigned to these objects in cases where either the object or the code value is set aside for future standardization. Usage and interpretation ay be specified by future extensions to this or other standards. A reserved object shall be zeroed or, upon developent of a future standard, set to a value specified by such a standard. The recipient of a reserved object shall not check its value. The recipient of an object defined by this standard as other than reserved shall check its value and reject reserved code values. 2.2 Glossary The following ters are used in this standard: bus ID: A 10-bit nuber that uniquely identifies a particular bus within a group of ultiple interconnected buses. The bus ID is the most significant portion of a node's 16-bit node ID. The value 0x3FF designates the local bus; a node shall respond to requests addressed to its 6-bit physical ID if the bus ID in the request is either 0x3FF or the bus ID explicitly assigned to the node. IP datagra: An Internet message that conforms to the format specified by RFC 791. node ID: A 16-bit nuber that uniquely identifies a Serial Bus node within a group of ultiple interconnected buses. The most significant 10 bits are the bus ID and the least significant 6 bits are the physical ID. octet: Eight bits of data. packet: Any of the 1394 priary packets; these may be read, write or lock requests (and their responses) or strea data. The term "packet" is used consistently to differentiate 1394 packets fro ARP requests/responses or IP datagras. physical ID: On a particular bus, this 6-bit nuber is dynamically assigned during the self-identification process and uniquely identifies a node on that bus. quadlet: Four octets, or 32 bits, of data. strea packet: A 1394 primary packet with a transaction code of 0x0A that contains a block data payload. Strea packets may be either asynchronous or isochronous according to the type of 1394 arbitration eployed. 2.3 Abbreviations The following are abbreviations that are used in this standard: CAM Channel allocation anager MCAP Multicast channel allocation protocol Expires: October, 1998 [Page 4] Internet-Draft 00 1394 MCAP April 1998 IP Internet protocol (within the context of this docuent, IPv4) 3. CHANNEL ALLOCATION MANAGER MCAP requires the presence of a channel allocation anager (CAM) to process requests, allocate or deallocate Serial Bus channel nubers and advertise the apping from group addresses to their corresponding channels. The identity of the CAM and the ethod of its selection have not yet been discussed by the working group. Consensus has been reached that the CAM listens for essages (whose forat is described below) on the default multicast channel specified by the NETWORK_CHANNELS register and transits advertisements and other responses on the sae channel. The details of CAM operations are described in section 5. 4. MCAP MESSAGE FORMAT MCAP essages, whether sent by a multicast source or recipient or the CAM, share a comon format illustrated below. The first eight octets of the essage are fixed; the remainder consists of variable-length tuples, each of which encodes inforation about a particular multicast group. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | checksu | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bus_ID | reserved | opcode | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + essage data + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - MCAP essage format Field usage in an MCAP essage is as follows: length: This field shall contain the size, in octets, of the entire MCAP essage. checksu: This field shall contain a checksum calculated on the entire MCAP essage. The checksum shall be one's complement of the su of all the 16-bit words in the message; arithmetic overflow is discarded. For the purpose of calculating the checksu, the checksum field is treated as if zero. bus_ID: This field shall specify the 10-bit bus ID for which inforation in the MCAP message is valid. The value of bus_ID shall be equal to the ost significant 10 bits of the sender's NODE_IDS register. Expires: October, 1998 [Page 5] Internet-Draft 00 1394 MCAP April 1998 opcode: This field shall have one of the values specified by table 1 below. Table 1 - MCAP opcode values opcode Nae Comment +----------------------------------------------------------------+ | 0 | Advertise | Sent by the CAM to broadcast the current | | | | apping from each group address to its | | | | corresponding channel nuber. | | 1 | Request | Sent by a multicast source to request the | | | | allocation of a channel nuber or to | | | | refresh the reaining lifetime of a | | | | channel nuber allocation. | | 2 | Release | Optionally sent by a multicast source to | | | | release a channel nuber at a future time. | | 3 | Error | Sent by the CAM when it is unable to | | | | satisfy a channel nuber allocation | | | | request. | | 4 | Solicit | Sent to request the CAM advertise the | | | | current channel apping(s) as soon as | | | | possible. | +----------------------------------------------------------------+ essage data: The remainder of the MCAP message is variable in length and shall consist of zero or ore group address descriptors with the forat illustrated below. 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length | type | reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | expiration | channel | speed | status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + group_address + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - MCAP group address descriptor forat length: This field shall contain the size, in octets, of the MCAP group address descriptor. type: This field shall have a value of one, which indicates a group address descriptor. expiration: The usage of this field varies according to opcode. For solicit and error essages the expiration field shall be ignored. Otherwise this field shall contain a tie-stamp, in seconds, that Expires: October, 1998 [Page 6] Internet-Draft 00 1394 MCAP April 1998 specifies a future tie for the release of the channel number specified by channel. Tie is expressed in terms of the CYCLE_TIME.seconds and a atch occurs when expiration equals the most significant seven bits of the CYCLE_TIME register. channel: This field shall specify either a valid channel nuber, in the range zero to 63 inclusive, or else indicate an invalid channel nuber with a value of 0xFF. All other values are reserved. The usage of this field varies according to opcode, as shown in the table below. Operation Usage of channel +----------------------------------------------+ | Advertise | Channel nuber allocated for the | | | multicast group_address | | Request | Suggested channel nuber (hint) | | Release | Ignored | | Error | Ignored | | Solicit | Ignored | +----------------------------------------------+ speed: This field shall be ignored except for advertise and request essages, in which case it shall specify the speed at which stream packets for the indicated channel are transitted. The encoding used for speed is specified by the table below; all values not specified are reserved. Value Speed +---------------+ | 0 | S100 | | 1 | S200 | | 2 | S400 | | 3 | S800 | | 4 | S1600 | | 5 | S3200 | +---------------+ status: This field shall be ignored except for error essages, in which case it shall characterize the reason(s) the CAM did not allocate a requested channel nuber. The encoding for this field is yet to be deterined. bandwidth: This field shall be ignored; it is allocated in the group address descriptor to accomodate future extensions to MCAP that specify quality of service and utilize the isochronous capabilities of Serial Bus. group_address: This variable length field shall specify the IP address of a particular multicast group. The length of group_address, in octets, is derived fro the length of the group address descriptor by subtracting 12 fro the length field. 5. MCAP OPERATIONS Expires: October, 1998 [Page 7] Internet-Draft 00 1394 MCAP April 1998 MCAP is a cooperative protocol iplemented by multicast senders and recipients and the CAM. The participants exchange essages over the default multicast channel used by all IP-capable nodes on a particular Serial Bus. The bus_ID field in all MCAP essages shall be equal to the most significant 10 bits of the sender's NODE_IDS register. 5.1 Advertiseent of channel mappings The CAM shall periodically broadcast an advertiseent of all multicast group addresses allocated a channel nuber that differs from the default multicast channel number. An advertisement shall consist of a single MCAP essage with an opcode of zero which contains zero or more group address descriptors (one for each group address assigned a channel nuber other than that specified by the NETWORK_CHANNELS register). Within each group address descriptor, the group_address and channel fields associate a multicast group address with a Serial Bus channel nuber. More than one multicast group address may be mapped to a single Serial Bus channel nuber by means of separate group address descriptors. The speed field specifies the aximum 1394 speed at which any of the senders within the multicast group transmits data. The expiration field specifies a future tie when the CAM will deallocate the channel nuber. No ore than ten seconds shall elapse from the transmission of the most recent advertiseent before the CAM initiates transmission of the subsequent advertiseent. 5.2 Request for channel allocation Before any multicast transmission on other than the default channel nuber specified by the NETWORK_CHANNELS register, a sender within a multicast group shall insure that the CAM has allocated a channel nuber. A multicast sender should first listen for an MCAP advertisement. If the multicast group address is already mapped to a channel number, the sender need not ake a channel allocation request and may use the advertised channel nuber for multicast transmission. Otherwise the intended multicast sender shall transmit an MCAP message with an opcode of one which contains one or ore group address descriptors. Within each group address descriptor the group_address field shall specify the multicast group address for which a channel nuber is requested. If the requester has reasons to prefer a particular channel nuber, this may be specified as a hint in the channel field but the CAM is not obligated to allocate that channel. The intended multicast sender shall also specify, for each multicast group address, the aximum speed at which it intends to transmit data and the expiration tie for the channel allocation. Expires: October, 1998 [Page 8] Internet-Draft 00 1394 MCAP April 1998 When the CAM receives an MCAP request for channel allocation(s), it shall attept to allocate a channel number in accordance with its own policies and the availability of Serial Bus channel nuber(s). If a channel is already allocated for the specified group_address, the CAM shall take no additional action other than to confir the channel nuber mapping in the next MCAP advertisement. If the channel number hint in the allocation request differs fro the channel number actually allocated, the CAM should transit an advertisement as soon as possible. Otherwise the advertiseent should be transmitted at the next scheduled tie. If no channel is allocated for the specified group_address, the CAM shall select a channel nuber and attempt to allocate it from the isochronous resource anager's CHANNELS_AVAILABLE register. The selection criteria shall be based upon the channel hint supplied in the request and the CAM's own policies; a value of 0xFF for channel indicates that the requester has provided no hint. If the chosen channel nuber is unavailable, the CAM may attempt to allocate a different channel nuber from CHANNELS_AVAILABLE. The retry algorithms are subject to policies iplemented by the CAM (e.g., some implementations might not allocate the last available channel but elect to aggregate multicast group addresses to already allocated channel(s)). When the CAM successfully allocates a channel nuber or assigns the multicast group address to an already allocated channel number, the new apping from multicast group address to channel number shall be advertised as soon as possible. The MCAP advertiseent constitutes a response to the channel allocation request and perits the multicast sender to comence transmissions. Otherwise, the CAM shall transit an error response as described below. 5.3 Error response to channel allocation The CAM shall transit an MCAP error response message whenever one or ore multicast group addresses specified in an MCAP channel allocation request essage have not been mapped to other than the default multicast channel nuber. Multicast channel allocation ay fail because no channel numbers are available or because CAM policy prevents the allocation. For whatever reason, the MCAP error response essage shall contain a group address descriptor for each failure. The group_address field shall identify the multicast group and the status field shall contain a code that indicates the nature of the error. All other fields within the group address descriptor shall be ignored. 5.4 Release of unneeded channel(s) When a multicast sender intends to cease transmissions for a multicast group that is not apped to the default multicast channel, it may notify the CAM by eans of an MCAP release message. The usage of the release Expires: October, 1998 [Page 9] Internet-Draft 00 1394 MCAP April 1998 essage is optional, since the CAM will automatically deallocate the channel nuber when its expiration time is reached. An MCAP release essage has an opcode value of three and contains one or ore group address descriptors. Each descriptor identifies the group_address whose channel nuber is to be released. The expiration field shall specify a tie at least 30 seconds in the future for the release of the channel nuber. All other fields within the group address descriptor shall be ignored. In response to an MCAP release essage that identifies a group_address in the current channel ap, the CAM shall update the expiration time for the channel with the value of expiration and shall transit an MCAP advertiseent message as soon as possible. The advertisement that reflects the updated expiration tie is the response expected by the sender of the MCAP release essage. Whether multicast senders utilize the optional MCAP release message or not, channel allocations eventually expire for unused channel nubers. When the expiration tie associated with a particular multicast group and associated channel is reached (as easured by the CAM's CYCLE_TIME register), the CAM shall reove the multicast group and channel number fro the current channel map. Once the CAM has transmitted an MCAP advertiseent message in which no group descriptors reference a previously allocated channel nuber, the CAM shall deallocate the channel nuber in the isochronous resource manager's CHANNELS_AVAILABLE register. 5.5 Solicitation of the channel ap Multicast recipients or senders ay request the CAM to advertise the channel ap by transmitting an MCAP solicitation request. No group address descriptors are included with this essage; the opcode value of five requests the CAM identified by bus_ID to advertise the channel ap. Originators of MCAP solicitation requests shall liit the rate at which they are transitted. Subsequent to sending a solicitation request, neither the originator nor any other node that observes the request shall send another MCAP solicitation request until either a) 10 seconds have expired or b) an MCAP advertiseent has been observed. The CAM should transit an MCAP advertisement message as soon as possible in response to the solicitation request. 5.6 Periodic refresh of channel allocation(s) As described in 5.4 above, the CAM shall reove expired multicast group address and channel nuber pairs from the current channel map and ultiately return channel number(s) to the CHANNELS_AVAILABLE pool when no longer used by any multicast group. In order to prevent this occurrence for active multicast groups, at least one sender within a multicast group shall periodically extend the expiration tie for the channel map by means of an MCAP channel Expires: October, 1998 [Page 10] Internet-Draft 00 1394 MCAP April 1998 allocation request essage (see 5.1). Although the CAM does not allocate a new channel, the request causes the expiration tie to be updated to a new future value. The frequency of MCAP channel allocation request essages and the expiration time specified in each should be coordinated such that at least three request essages are transmitted before the expiration tie specified by the earliest of the three is reached. In multicast groups where there is more than one sender it is desirable to liit the number of MCAP channel allocation request messages. The ideal situation is for one sender to generate the requests. If this sender intends to leave the multicast group, one of two events occur: either the sender transits the optional MCAP release message or it ceases transission of allocation request messages. In the first case, one of the other senders within the multicast group is expected to observe the release essage and initiate its own transmission of MCAP channel allocation request essages. Otherwise, if the time remaining before channel expiration falls below two seconds, that sender should initiate its own transission of MCAP channel allocation request essages. In the latter case, the allocation request shall be transitted at least one second before the expiration time. 6. SECURITY CONSIDERATIONS This docuent specifies the use of an unsecured link layer, Serial Bus, for the transport of IPv4 datagras. Serial Bus is vulnerable to denial of service attacks; it is also possible for devices to eavesdrop on data or present forged identities. Iplementers who utilize Serial Bus for IPv4 should consider appropriate counter-easures within application or other layers. 7. ACKNOWLEDGEMENTS This docuent represents work in progress by the IP/1394 Working Group. The editor wishes to acknowledge the contributions ade by all the active participants, either on the reflector or at face-to-face eetings, which have advanced the technical content. 8. REFERENCES [1] IEEE Std 1394-1995, Standard for a High Perforance Serial Bus [2] ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcoputer Buses [3] IEEE Project P1394a, Draft Standard for a High Perforance Serial Bus (Suppleent) [4] IEEE Project P1394b, Draft Standard for a High Perforance Serial Bus (Suppleent) Expires: October, 1998 [Page 11] Internet-Draft 00 1394 MCAP April 1998 9. EDITOR’S ADDRESS Peter Johansson Congruent Software, Inc. 3998 Whittle Avenue Oakland, CA 94602 (510) 531-5472 (510) 531-2942 FAX pjohansson@aol.co Expires: October, 1998 [Page 12]