other multicast sources may be using the same channel mapping, an
orderly process is defined to transfer channel ownership.
The owner of an existing channel mapping that wishes to release the
mapping SHALL commence a timer to measure the time remaining before
the anticipated release of the mapping and its associated channel.
Until the timer counts down to zero, the owner SHOULD continue to
transmit MCAP advertisements for the affected channel but SHALL
adjust expiration in each advertisement to reflect the time remaining
until the channel is to be deallocated. If the owner is unable to
transmit MCAP advertisements until the timer reaches zero, it SHALL
initiate a bus reset. Otherwise, the sequence of expiration times
transmitted by the owner intending to release the mapping SHALL
decrease with each succeeding advertisement. If other multicast
source(s) are using the same channel mapping and observe an
expiration time less than or equal to 60 seconds, they SHALL commence
transmitting MCAP advertisements for the channel mapping with
refreshed expiration times greater than or equal to 60 seconds that
maintain the channel mapping. Any contention that occurs between
multiple sources that attempt to claim ownership of the channel
mapping SHALL be resolved as described in 9.8. If the original owner
observes an MCAP advertisement for the channel to be relinquished
before its own timer has expired, it SHALL NOT deallocate the channel
number.
Otherwise, if the owner's timer expires without the observation of a
MCAP advertisement by another node, the owner of the channel number
SHALL subsequently deallocate the channel as described in 9.8. If the
intended owner of the channel mapping observes an MCAP advertisement
whose expiration field is zero, orderly transfer of the channel(s)
from the former owner has failed. The intended owner SHALL either
stop reception and transmission on the expired channel number(s) or
allocate different channel number(s) as specified by 9.4.
9.8 Redundant channel mappings
When ownership of a channel mapping is transferred from one multicast
source to another, it is possible for more than one device to claim
ownership. This results in redundant MCAP advertisements, transmitted
by different sources, each of which specifies the same multicast
group address and channel. A procedure similar to that of 9.6 SHALL
resolve the contention for channel ownership.
Multicast channel owners SHALL monitor MCAP advertisements in order
to detect redundant channel mappings. MCAP advertisements whose
expiration field has a value less than 60 SHALL be ignored for the
purpose of redundant channel detection. When a redundant channel
mapping is detected, the owner with the largest physical ID (as
determined by the least significant six bits of source_ID from the
GASP header) is NOT REQUIRED to take any action. The owner(s) with
smaller physical IDs SHALL cease transmission of MCAP advertisements
for the redundant channel number but SHALL NOT deallocate the channel
number.
9.9 Expired channel mappings
A channel mapping expires when expiration seconds have elapsed since
the most recent MCAP advertisement. At this time, multicast
recipients SHALL stop reception on the expired channel number(s).
Also at this time, the owner of the channel mapping(s) SHALL transmit
an MCAP advertisement with expiration cleared to zero and SHALL
continue to transmit such advertisements until 30 seconds have
elapsed since the expiration of the channel mapping. Once this
additional 30-second period has elapsed, the owner of the channel
mapping(s) SHALL deallocate the channel number(s) and indicate their
availability in the isochronous resource manager's CHANNELS_AVAILABLE
register.
If an IP-capable device observes an MCAP advertisement whose
expiration field is zero, it SHALL NOT attempt to allocate any of the
channel number(s) specified until 30 seconds have elapsed since the
most recent such advertisement.
9.10 Bus reset
A bus reset SHALL invalidate all multicast channel mappings and SHALL
cause all multicast recipients and senders to zero all MCAP
advertisement interval timers.
Prior owners of multicast channel mappings may reallocate a channel
number from the isochronous resource manager's CHANNELS_AVAILABLE
register and resume broadcast of MCAP advertisements as soon as a
channel is allocated. If channel reallocation is attempted, the prior
owner SHOULD use the same channel number allocated prior to the bus
reset and may commence reallocation immediately upon completion of
the bus reset so long as the same channel number is reused. If the
prior owner elects to allocate a different channel number, it SHALL
wait until at least one second has elapsed since the completion of
the bus reset before attempting to allocate a new channel number.
Intended or prior recipients or transmitters of multicast on other
than the default channel SHALL NOT transmit MCAP solicitation
requests until at least ten seconds have elapsed since the completion
of the bus reset. Multicast data on other than the default channel
SHALL NOT be received or transmitted until an MCAP advertisement is
observed or transmitted for the IP multicast group address.
Intended or prior transmitters of multicast on other than the default
channel that did not own a channel mapping for the IP multicast group
address prior to the bus reset SHALL NOT attempt to allocate a
channel number from the isochronous resource manager's
CHANNELS_AVAILABLE register until at least ten seconds have elapsed
since the completion of the bus reset. Subsequent to this ten second
delay, intended or prior transmitters of multicast may follow the
procedures specified by 9.4 to allocate a channel number and
advertise the channel mapping.
10. IANA CONSIDERATIONS
This document necessitates the creation and management of a new name
space (registry) by IANA. The need for such a registry arises out of
the method by which protocol interfaces are uniquely identified by
bus standards compliant with ISO/IEC 13213:1994, CSR Architecture.
This is explained in more detail in section 6; the essence is that a
globally unique 48-bit number SHALL identify the document that
specifies the protocol interface. The 48-bit number is the
concatenation of 0x00 005E (a registration ID, or RID, granted to
IANA by the IEEE Registration Authority) and a second 24-bit number
administered by IANA.
The IEEE RA RECOMMENDS that the policy for management of the second
24-bit number be chosen to maximize the quantity of usable numbers
with the range of possible values. In particular, the IEEE RA
RECOMMENDS that the assignment scheme not apply a structure to the
number (e.g., the allocation of a version field within the number)
since this would tend to waste large portions of the range.
The new name space is "CSR Protocol Identifiers". The values zero and
0xFF FFFF are reserved and SHALL NOT be allocated by IANA. The value
one is allocated to this document. The remaining numbers SHALL be
managed by IANA and allocated as necessary to identify Internet-
Drafts that become IESG standards track documents.
Regardless of the assignment method elected by IANA, a registry of
all assigned version numbers SHOULD be maintained at one or more
Internet sites and should clearly identify the relevant standard
identified by the combination of the RID and version number.
11. SECURITY CONSIDERATIONS
This document specifies the use of an unsecured link layer, Serial
Bus, for the transport of IPv4 datagrams. Serial Bus is vulnerable to
denial of service attacks; it is also possible for devices to
eavesdrop on data or present forged identities. Implementers who
utilize Serial Bus for IPv4 SHOULD consider appropriate counter-
measures within application or other layers.
12. ACKNOWLEDGEMENTS
This document represents the efforts of the IP/1394 Working Group.
The editor wishes to acknowledge the contributions made by all the
active participants, either on the reflector or at face-to-face
meetings, which have advanced the technical content.
13. REFERENCES
Normative reference to standards under development at the time of
this document's publication shall utilize the most current draft
until such time as it is replaced by an approved standard.
[1] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
[2] ISO/IEC 13213:1994, Control and Status Register (CSR)
Architecture for Microcomputer Buses
[3] IEEE Project P1394a, Draft Standard for a High Performance Serial
Bus (Supplement)
[4] IEEE Project P1394b, Draft Standard for a High Performance Serial
Bus (Supplement)
[5] Postel, J., "Internet Protocol Darpa Internet Program Protocol
Specification", RFC791, September 1981.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC2119, March 1997.
14. EDITOR'S ADDRESS
Peter Johansson
Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA 94602
Phone: (510) 527-3926
Fax: (510) 527-3856
EMail: pjohansson@aol.com
15. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.