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

Re: MAC/NPA question



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


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


-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------