[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MAC/NPA question

See comments in-line.

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
receivers)can be directly routed from the satellite itself, instead of first
sending it to the ground hub and then to the other receiver?

Regards
Prashant
Traditional MPEG delivery networks (cabled, wireless, whatever) will most usually use a MAC/NPA address to filter the packets that they wish to receive - discriminatling those destined to other receivers that will be filtered in hardware/software/firmware below the IP-level.
The mode D=0, in which the address is present is specified as the default. RFC4326 states: 

   An End Indicator (4.3) MUST be sent with a D-bit value of 1.  Other
   SNDUs MAY be sent with a D-bit value of 0 or 1.  The default method
   SHOULD use a D-bit value of 0 (see section 4.5).
However, when the network segment connected to a Receiver is not connected to other networks - i.e. it is a stub network (common in many current scenarios), the D=1 option may be safely used. For multicast, D=1 is always "safe". Choice then becomes one of optimisation of resources.
So far, I haven't seen a detailed examination of the options for the satellite OBP case. 

Gorry



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.