Subject: MAC/NPA question

From: [email-masked]
Date: Tue, 03 Jan 2006 12:48:14 +0000

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?

• 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)?

• 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?

• Does the above case refer to two IP routers connected to a same DVB receiver?
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.

• 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?

Regards
Prashant

P.S. HAPPY NEW YEAR to all.

-- 
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: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Wed, 04 Jan 2006 08:01:45 +0100

Hello Prashant,

let me try to answer yuor questions.

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

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

> (i.e. where the same link connects multiple receivers)”. Which link is being

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.

> maintained in the DVB receiver which can used to get the destination MAC

As explained above the issue is neither ARP nor source address filtering.

> of the cases (so maybe default case) but would be present for some exceptional

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.

> Prashant

Regards,
Bernhard

> P.S. HAPPY NEW YEAR to all.

PS: HNY as well.

---

From: [email-masked]
Date: Wed, 04 Jan 2006 14:54:10 +0000

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

---

From: Bernhard Collini-Nocker <[email-masked]>
Date: Thu, 05 Jan 2006 07:54:09 +0100

Hello Prashant,

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

> 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,
Bernhard

>>>I would be grateful if you could help me with the following doubts related
>>
>>to
>>
>>>the MAC/NPA address:
>>>
>>>optional. What is the main reason that drives it? Is it only because there
>>
>>is a
>>
>>>• Is this destination address the MAC address (i.e. the actual physical
>>
>>hardware
>>
>>>• The section also states that “the destination address would be present
>>
>>for
>>
>>>(i.e. where the same link connects multiple receivers)”. Which link is
>>
>>being
>>
>>>referred to here?
>>
>>
>>>• Does the above case refer to two IP routers connected to a same DVB
>>
>>receiver?
>>
>>>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
>>
>>>• 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?
>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 05 Jan 2006 10:30:32 +0000

See comments in-line.

> sending it to the ground hub and then to the other receiver?
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

---

From: [email-masked]
Date: Tue, 10 Jan 2006 10:39:28 +0000

Hi Gorry,

As mentioned in some of the emails before, I think we should look into the
network access control methods for the IP services over DVB systems. Though
RCST authentication and key exchange mechanisms have been defined by DVB, but
authentication of the users behind the RCST may also be important. This may be
especially required by the service provider depending on their business models.
Do you think it is worthwhile to look into this issue?

RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be used
for authentication of user terminals. The RCST would have to be a RADIUS Client
forwarding the authentication requests to the DVB gateways in the NCC. The DVB
gateways act as RADIIUS proxies which further forward the requests to an AAA
server. The AAA server would have user profiles. DIAMETER (over
TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex
protocol with larger overheads as compared to RADIUS, one of its main advantage
is its support for mobility.

Interaction of these with the RCS security could be an issue say when different
users connected to the same RCST (maybe in a cyber cafe) join different
multicast groups at different times and the new keys have to be sent to the
RCST.

The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point for
the security services to be provided. But this draft seems to be very specific
for securing the ULE packets. Maybe a new ID could address the network access
control issue, what do you think?

Regards
Prashant

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 16 Jan 2006 11:50:19 +0000

It is good to hear from you.

The security requirements document would certainly benefit from 
additional contributions. I'll cc this to the authors, and hope they can 
add their own respones to mine.

I'd encourage you to send any contributions you can to the security 
requirements I-D (to this list), that would be good to start security 
work.  I note that you mention DVB-RCS, examples using a specific 
technology are always welceome, but please do bear in mind that the 
document would need to be applicable to a range of MPEG-2 based 
transmission systems.

If you have other thoughts that could be captured on specific topics, it 
would be worth trying to first set those out in an email, and if you can 
find others from the group to work on this, a new I-D would be the 
easiest way to bring the topic to the attention of others.

Best wishes,

Gorry

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 18 Jan 2006 19:47:27 -0500

> control issue, what do you think?
Took me a while to respond to this. We have been looking at 
configuration for a while using SIP based mechanisms like other groups 
have done. I would link NAC to this. What do you think?

/mjm

---

From: [email-masked]
Date: Thu, 19 Jan 2006 08:51:33 +0000

Hi Marie-Jose

I have worked with SIP before, and it can provide some very interesting features
that may be used here. I am not sure of your approach here though...are you
looking into using SIP from user terminal to DVB gateway/Hub (acting as a SIP
server or maybe a SIP proxy) for setting up MPEG2 sessions? In this case SIP 200
OK message after authorisation should initiate the rekeying mechanisms. What
about setting up multicast sessions - IGMP with SIP?

Access control could be used along with this when SIP Invites are sent. We would
still need a backend DIAMETER server and interaction between the SIP and
DIAMETER servers. There is I-D for diameter application for SIP
(draft-ietf-aaa-diameter-sip-app-10) that may be useful.

Are you working on an ID for this SIP approach? I would like to contribute
something on the access control issues.

Regards
Prashant