Re: MAC/NPA question

[Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>]

Hello Prashant,

P.Pillai@Bradford.ac.uk wrote:
> Hi Bernhard
> 
> Thank you very much for your prompt reply.
> 
> So Am I correct in saying that the destination MAC/NPA address in mainly
> required for on-board processing systems so that the data (between 2

certainly NO. "Taste" cannot easily and objectively be described as good
or bad. There are other good reasons to have/use a Destination Address,
such as filtering. But, there is no such "mainly required for".

What one can say is that the Destination Address can be used for
addressing and filtering purposes and there are special cases where it
use is mandatory.

> receivers)can be directly routed from the satellite itself, instead of first
> sending it to the ground hub and then to the other receiver?

The issue here is less whether the routing is on-board or not but the
multiplexing of TS streams and layer 2 destination addressing.

> Regards
> Prashant

Regards,
Bernhard

> 
> Quoting Bernhard Collini-Nocker <bnocker@cosy.sbg.ac.at>:
> 
> 
>>Hello Prashant,
>>
>>let me try to answer yuor questions.
>>
>>P.Pillai@Bradford.ac.uk wrote:
>>
>>>Hi Gorry,
>>>
>>>I would be grateful if you could help me with the following doubts related
>>
>>to
>>
>>>the MAC/NPA address:
>>>
>>>• Section 4.5 in the ULE RFC states that the destination address field is
>>>optional. What is the main reason that drives it? Is it only because there
>>
>>is a
>>
>>>higher layer address (e.g. IP address) that can be used for filtering?
>>
>>Yes, especially for IP-multicast packets this avoids redundant
>>information in the ULE SNDU. In all other cases routers will filter on
>>IP addresses rather anyhow.
>>
>>
>>>• Is this destination address the MAC address (i.e. the actual physical
>>
>>hardware
>>
>>>address) of the DVB receiver or is any address that is used at layer 2 for
>>>identification (i.e. this address can be generated dynamically)?
>>
>>This likely depends on implementation. In many/most cases the "actual
>>physical hardware" address will be an IEEE 802 MAC address (even
>>registered) but it may well be another "actual phsyical hardware
>>address" or a software configurable one.
>>
>>
>>>• The section also states that “the destination address would be present
>>
>>for
>>
>>>Unicast IP packets destined to routers that are sent using the shared link
>>>(i.e. where the same link connects multiple receivers)”. Which link is
>>
>>being
>>
>>>referred to here?
>>
>>
>>The RFC actually says that "the SNDU destination Adress Field MUST be
>>carried for IP unicast destined to routers that are sent using shared
>>links...".
>>Take as an example a SkyPlex system, where all contributing DVB (SCPC or
>>TDMA) uplinks are multiplexed on-board of the satellite into one single
>>downstream and, hence, each router (both DVB-TX and DVB-RX) "sees" each
>>other. In that case a receiving router cannot decide upon the IP address
>>to whom the packet is being routed, so the presence of a destination
>>address field refers to the right router. Rather than filtering (for in
>>end-hosts) this is actually an addressing issue here.
>>
>>
>>>• Does the above case refer to two IP routers connected to a same DVB
>>
>>receiver?
>>
>>Clearly no. See above example.
>>
>>
>>>Even in this case the DVB receiver would de-capsulated the IP datagram from
>>
>>the
>>
>>>ULE packet and could then encapsulate it into an Ethernet frame with the
>>
>>source
>>
>>>Ethernet address being that of the DVB receiver. And an ARP cache can be
>>>maintained in the DVB receiver which can used to get the destination MAC
>>>address of the router.
>>
>>As explained above the issue is neither ARP nor source address filtering.
>>
>>
>>>• Am I right in saying that the destination address would not be present in
>>
>>most
>>
>>>of the cases (so maybe default case) but would be present for some
>>
>>exceptional
>>
>>>cases?
>>
>>This is more a question of taste, network topology, transmitter and
>>receiver capabilities, and concrete operational issues/constraints. I
>>personally would agree, also because PID filtering can be used to
>>"segment" DVB links and perform hardware filtering.
>>
>>
>>>Regards
>>>Prashant
>>
>>Regards,
>>Bernhard
>>
>>
>>>P.S. HAPPY NEW YEAR to all.
>>
>>PS: HNY as well.
>>
>>
> 
> 
>