Network Working Group P. Johansson
Internet-Draft Congruent Software, Inc.
<draft-ietf-ip1394-mcap-00.txt>
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. EDITORS 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. EDITORS 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]
