When banging out the details for 3GPP and DVB use of FLUTE we took a closer look at channelisation for the LCT, ALC, FLUTE family. When we started describing the session (see draft-mehta-rmt-flute-sdp-03.txt) it became clear that there are 3 cases for distinguishing channels.
Channels are defined by 4 parameters:
(IP_source_address, TSI, IP_destination/group_address_destination_port_number).
Thus channels can be differentiated based on each of these cases:
1. Differing destination IP addresses (ports may also change)
2. Differing port numbers using the same IP destination address for all
3. Both differing and mixed, where several channels use the same IP destination address different ports and several IP destination addresses are used.
Generally (1) should be used (for enabling CC (congestion control) use of channels). However, there are potential use cases for (2) since application layer CC is feasible. No one has so far come up with a compelling use case for (3) and this could be horribly complex.
The flute-sdp I-D does not have a way of describing case (3) in any case.
However, now I am proposing to EXPLICITLY ELIMINATE THE UNNECESSARY MULTI-ADDRESS + MULTI-PORT CHANNEL DIFFERENTIATION case (3) by stating this in LCT:
The identification of channels of a session SHOULD be differentiated primarily based on their IP destination/group address, such that no more than one channel should use a single IP destination/group address. However, more than one channel is delivered using a single IP destination/group address, meaning that the destination port number is also primarily used to identify channels, the destination port number MUST differentiate the channels alone, such that the same IP destination/group address MUST be used for all the channels of a session. This disallows the unnecessary and complex case of multiple channels across multiple ports unevenly distributed over multiple addresses in any situation.
Sound good?
Cheers, Rod.
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.