Subject: Proposed text for Draft-IETF-IP1394-IPv4-15

From: Peter Johansson <[email-masked]>
Date: Sun, 9 May 1999 18:14:37 EDT

In a message dated 99-04-22 12:11:01 EDT, [email-masked] writes:

<<4) A solution is needed for the error in MCAP where a 1394 channel is
deallocated yet the channel continues to be used for IP mcast.  The solution
is to send expire time of 0 for 30 seconds. Dealloc channel after 30 seconds.
Owner-want-to-be must allocate new channel once expire time reaches 0.
Proposed text is not done.>>

This change is effected by new text in two locations. The first is added as
the last paragraph of 10.7:

"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 10.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 10.4."

The second modifies the first paragraph of 10.8 to read as follows:

"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."

<<5) Add text that states that once a node starts attempting to become an
owner it must complete all steps until it either becomes the owner or
determines that another node became the owner.  Proposed text is not done.>>

I've always thought this was sufficiently clear in the draft: there are rules
for contention, expiration and transfer of channel ownership that apply.

Never the less, I've add the following as the last paragraph of 10.5:

"Once a multicast source has advertised a channel mapping, it SHALL continue
to transmit MCAP advertisements for the channel mapping unless it either a)
transfers ownership to another multicast source, b) permits the channel
mapping to expire without transfer or c) in the case of overlapped channel
mappings, relinquishes control of the channel mapping to another multicast
source."

<<6) Text explaining buffer size may need improvement. The salient points in
the text should be: buffer size is equal in all link fragments and buffer
size is equals the size of IP packet (including the header). Textual
modifications to this point are left to the editor's discretion.>>

Definition of buffer_size revised to read as follows: "The size of the
buffer, expressed as buffer_size + 1 octets, necessary for the recipient to
reassemble the entire IP datagram from all of the link fragments. The value
of buffer_size SHALL be the same for all link fragments of an IP datagram."

<<7) Remove the reference to sharing multiple IP mcast addrs with a single
1394 channel.>>

Offending sentence in 10.5 deleted; cautionary note in the introductory
material to section 10 retained.

A NEW ISSUE AROSE AS A CONSEQUENCE OF THESE CHANGES

The definition of "overlapped channels" became invalid as a result of the new
transfer procedures. The first paragraph of 10.6 is revised as follows:

"When two intended multicast sources wish to transmit to the same multicast
group and no channel mapping exists for the group address, there is a chance
that both will allocate channel numbers and both will advertise the channel
mappings. These channel mappings overlap, i.e., the same group address is
mapped to more than one channel number in MCAP advertisements with nonzero
expiration times."

PLEASE COMMENT; IF THERE APPEARS TO BE CONSENSUS, I WILL POST
Draft-IETF-IP1394-IPv4-15 AT THE END OF THE WEEK. Myron and Tony may then use
it as the basis for a working group "last call."

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Sun, 9 May 1999 21:17:35 -0700

Thanks Peter. This looks fine to me. -myron

> -----Original Message-----
> From: Peter Johansson [mailto:[email-masked]]
> Sent: Sunday, May 09, 1999 3:15 PM
> To: [email-masked]
> Subject: Proposed text for Draft-IETF-IP1394-IPv4-15
>
>