Subject: Comments on ULE extension header....

From: "[email-masked]" <[email-masked]>
Date: Mon, 7 Jun 2004 14:30:11 -0400

Thanks to Gorry for publishing the draft :)

Few Comments
Editorial :
---------
In Section 2, Figure 1,2 and 3 D_bit is maked as ZERO. It should be ONE
Figure 3, T2 and H2 are interchanged.

Concept:
---------
When we are talking about backward compatibility, it is better to have
version number in the ULE, so across the version it is identified uniquely.

In Optional headers, Wish to add Source mac address... In case of
UDLR(RFC3077), during DTCP announcement, ULE can take the source mac i.e.
FUMAC makes simple in address resolution. -UDLR is jst an example.
otherthings are security filters can be implemented based on source MAC.

-William

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Jun 2004 10:50:26 +0100

> Thanks to Gorry for publishing the draft :)

This was a work of many discussions among many people...

> version number in the ULE, so across the version it is identified uniquely.

Yes - and this *could* have been in the ULE base header, but there are
significant disadvantages too - additional capacity would consumed.

My suggestion is to use one encapsulation method per PID (MPEG-2 TS logical
channel) - if we do this other signaling protocols can associate a
particular PID with a particular encapsulation method.  The descriptors
passed by the signaling protocol could also differentiate MPE from ULE.
If we need a new format for ULE sometime in the future, we could use this
method to identify this.

Are you suggestion a new OPTIONAL extension to give the version of the ULE
protocol? - How do you see the additional benefits of this?

> otherthings are security filters can be implemented based on source MAC.

Yes - this is true.

We had a discussion on this topic at the Vienna BoF, and at that time I
don't recall a need for a MAC source without a MAC destination address. If
that is still the case, then maybe the bridging format extension would
satisfy this requirement?

Thoughts?

> -William

Gorry Fairhurst

---

From: "William StanisLaus" <[email-masked]>
Date: Tue, 8 Jun 2004 17:29:20 +0530

Please see the comments inlined...

-William.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Tuesday, June 08, 2004 3:20 PM
> To: [email-masked]
> Cc: Bernhard Collini-Nocker
> Subject: Re: Comments on ULE extension header....
> 
> 

William> I suggest to have it as a Mandatory header, Since different
version of implementation of ULE can be differenciated with a version
number. 
Say for example, in ULE version 1 I have 4 Mandatory headers. And we
decide to add 2 more Mandatory headers and come up with a new version of
ULE. In that case, since we have added new mandatory header the older
implementation will jst drop the packet/SNDU. BUT if you have an version
number, we can make it backward compatibily based on version number and
still process the packet/SNDU by avoiding those header processing and
dropping the packets.

> satisfy this requirement?

William> In case of UDLR, it is not a packet forwarding, the orginator
of the packet is the FEED itself i.e. satellite terminal. My understand
with bridged format packets is sending the ethernet packets along with
L2 information in satellite network, i.e. L2 tunneling. In that you
still have outer ULE and MPEG headers.
Please correct if I'm wrong.

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Jun 2004 15:41:31 +0100

On Ethernet bridging...

>> <[email-masked]> wrote:

<snip>

> Please correct if I'm wrong.

So I'd guess if you wanted a source MAC address, an example is:

<base ULE header, (D=1)> <Bridging header><payload><crc-32>

I.e.:

<Len,Type=bridging, (D=1)> <MAC-dst;MAC-src;Ether-Type><payload><crc-32>

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 08 Jun 2004 15:35:59 +0100

More on version identification...

 <snip>

This is the first time we've discussed the published XULE draft, but if I
understand correctly, the MANDATORY EXTENSION is one that MUST be processed
before a PDU is forwarded. It does NOT imply it MUST be implemented.

In the future, more MANDATORY EXTENSION headers could be added - if there
was a case for this - by simply allocating entries in the IANA registry
after publishing an RFC that defines the new extension header syntax.  Older
systems simply can not process these headers and discard the PDU when they
find an unrecognised MANDATORY type (and ignore any following parts of this
SNDU).

In contrast, unrecognised OPTIONAL extensions can be ignored, and don't
require the encapsulated PDU to be discarded.

Given these features, it seems that new extensions could be introduced if
new optimisations/requirements emerge.

Gorry Fairhurst

---

From: "William StanisLaus" <[email-masked]>
Date: Wed, 9 Jun 2004 09:43:53 +0530

Let me make it clear,

CASE 1:
-------
Satellite terminal has two interface Ethernet and DVB. The packet
received from Ethernet has to be forwarded in DVB interface, in that
case we choose to do in bridged format.. So just take the L2 information
from Ethernet packet and encapsulate with ULE and MPEG2-TS, without
modifying anything and forward the packet in satellite network. i.e. L2
Tunneling

NOTE: In this, L2 is IEEE 802.3 Encapsulation, might contain LLC and
SNAP as well.

CASE 2a:
-------
Satellite terminal has two interface Ethernet and DVB. The packet
received from Ethernet has to be forwarded in DVB interface, but bridged
format in ULE, the terminal strips out L2 information from Ethernet and
adds new L2 information i.e. SOURCE MAC as terminal which forwards the
packet, DEST MAC as the terminal to which the packet has to be forward (
immediate next hop ) and protocol type 

CASE 2b:
-------
Satellite terminal orginating a packet i.e. in this case it is not a
forwarder but a host. Example UDLR, DTCP announcement (HELLO packet).
If we wish to bridge the packet, exactly like CASE 2a we have to bridge
the packet.

Question:
--------
In both CASE 2a and 2b, we have protocol type, in Bridged information
and ULE Protocol Type, so something can be saved and some processing
overhead can be improved if we have a plain SOURCE MAC in direct ULE
optional header.

Thoughts??

-William.

> Sent: Tuesday, June 08, 2004 8:12 PM
> To: [email-masked]
> Cc: 'Bernhard Collini-Nocker'
> <Len,Type=bridging, (D=1)> 
> <MAC-dst;MAC-src;Ether-Type><payload><crc-32>
> 
> >> 
> >>> -William
> >>> 
> >>> 
> >>>

---

From: "William StanisLaus" <[email-masked]>
Date: Wed, 9 Jun 2004 09:55:52 +0530

Well, I agree for Mandatory headers, it MUST not be implemented across
the version. But Version number tracks the supported Mandatory headers
for that release/version. Hence we can always quote the implementation
with the version number.
For any commercial Marketing, Feature sheet says about the MPE, and jst
version number will imply any supported Mandatory header. Otherwise it
should list all the Mandatory headers in the Feature Sheet.

-William.

> Sent: Tuesday, June 08, 2004 8:06 PM
> To: [email-masked]