Re: Fwd to ipdvb: [Réf. : The real benefits of ULE compared to MPE] From Laurence Duquerroy

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Rod.Walsh@nokia.com wrote:
> IP version appears in the IP header (sorry for stating the obvious :)
Yes - and although that is good to verify this in the inet driver, there were 
reasons why this is not a general recommended method for IPv6 over foo. Most 
L2 networks actually do this using a 16?8 bit field at L2: Ethernet [RFC2464], 
for PPP [RFC1662], FR [RFC2590], etc.

> For interest value: For Multicast the MAC is calculated according to 
> IP address in a way you can discriminate v4 from v6.
>
True.

> For unicast the MAC is whatever (generally the MAC address of the terminal, 
> but it could be other things too).
> However, it's a design assumption in using MPE for DVB-H that signalling
> the IP version below IP packet is unnecessary.
>
> This was based on various real world implementations (which are now in 
> commercial devices) proving that v4-v6 filtering is only needed at IP layer
> and where HW acceleration
> is needed it is sufficient to go several bytes in to analyse the IP header.
>
Do you know which other IP "subnetwork types" are supported by current drivers 
(802.1pQ, arp, header compression, 802 bridging-mode)?

> Although I'm not sure why ULE would need to signal IP version, 
> any explanation would be helpful.
>
Some info is in section 4 (Encapsulation Protocol Requirements) of:
http://www.ietf.org/internet-drafts/draft-ietf-ipdvb-arch-04.txt


> Cheers, Rod.
>
>
>
>
> > -----Original Message-----
> > From: owner-ipdvb@erg.abdn.ac.uk 
> > [mailto:owner-ipdvb@erg.abdn.ac.uk] On Behalf Of ext Gorry Fairhurst
> > Sent: 21 November, 2005 15:54
> > To: ipdvb@erg.abdn.ac.uk
> > Subject: Fwd to ipdvb: [Réf. : The real benefits of ULE 
> > compared to MPE] From Laurence Duquerroy
> >
> >
> > I forward the attached message, which appears to have been 
> > missed by the mailing list. Follow-up welcome.
> >
> > Best wishes,
> >
> > G Fairhurst.
> >
> > -------- Original Message --------
> > Subject: Fw:  Réf. : The real benefits of ULE compared to MPE
> > Date: Fri, 18 Nov 2005 10:15:43 +0100
> > From: Laurence.Duquerroy@alcatelaleniaspace.com
> >
> > <snip>
> >
> > -----
> >
> >
> >                      Laurence 
> >
> >                      Duquerroy                Pour :   
> > ipdvb@erg.abdn.ac.uk 
> >
> >                                               cc : 
> >
> >                      15/11/2005 10:10
> > Objet :  Réf. : The real benefits of ULE compared to MPE 
> >
> >
> > Hi All,
> >
> > For IPv6:
> > MPE can be used to transport IPv4 or  IPv6 packets, however 
> > the standard does not specify clearly how to signal the IP 
> > version . There is no type field in the MPE header.
> > One solution could be using the LLC/SNAP header (which has a 
> > Protocol Identifier field) , but according to the MPE 
> > specification, when carrying IP packets, the LLC/SNAP header 
> > must not be used.
> >
> > The ULE specification defines a Type field in the ULE  header, 
> > which allows to signal the type of PDU included in the SNDU, 
> > and for IP packets:  the IP version.
> >
> > Laurence Duquerroy
> >
> >
> >
> >                      "H.Cruickshank" 
> >
> >                      <H.Cruickshank@su         Pour :   ipdvb 
> > <ipdvb@erg.abdn.ac.uk>
> >                      rrey.ac.uk>               cc : 
> >
> >                      Envoyé par :              Objet :  The 
> > real benefits of 
> > ULE compared to MPE
> >                      owner-ipdvb@erg.abdn.ac.uk 
> >
> >
> >
> >
> >
> >                      14/11/2005 17:27 
> >
> >                      Veuillez répondre 
> >
> >                      à ipdvb 
> >
> >
> >
> > HI All,
> >
> > Reading through some recent email exchanges has triggered in 
> > my mind the following very basic question:
> >
> > What are the real benefits of ULE compared to MPE ?
> >
> > Can someone or some people answer this basic question, in terms of:
> >
> > * Bytes overhead saving
> > * IPv6
> > * IP multicast
> > * Any operational consideration
> > * Coding efficiency
> > * Future uses
> > * Any other savings
> >
> > Many thanks
> > Haitham
> >
> >
> > --
> >
> >
> > Dr. Haitham S. Cruickshank
> > Lecturer
> > Communications Centre for Communication Systems Research 
> > (CCSR) School of Electronics, Computing and Mathematics 
> > University of Surrey, Guildford, Surrey GU2 7XH, UK
> > Tel: +44 1483 686007 (indirect 689844)
> > Fax: +44 1483 686011
> > e-mail: H.Cruickshank@surrey.ac.uk
> > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
> >
> > RT/ST
> > Research Department / Advanced Telecom Satellite Systems Tel : 
> > 33 (0)5-34-35-63-06  /  Fax : 33 (0)5-34-35-55-60 E-Mail : 
> > laurence.duquerroy@alcatelaleniaspace.fr
> >
> > This message and any attachments (the "message") is intended 
> > solely for the addressees and is confidential. If you receive 
> > this message in error, please delete it and immediately notify 
> > the sender. Any use not in accord with its purpose, any 
> > dissemination or disclosure, either whole or partial, is 
> > prohibited except formal approval. The internet can not 
> > guarantee the integrity of this message. ALCATEL ALENIA SPACE 
> > (and its subsidiaries) shall (will) not therefore be liable 
> > for the message if modified.
> >
> > Ce message et toutes les pieces jointes (ci-apres le 
> > "message") sont etablis a l'intention exclusive de ses 
> > destinataires et sont confidentiels.
> > Si vous recevez ce message par erreur, merci de le detruire et 
> > d'en avertir immediatement l'expediteur. Toute utilisation de 
> > ce message non conforme a sa destination, toute diffusion ou 
> > toute publication, totale ou partielle, est interdite, sauf 
> > autorisation expresse. L'internet ne permettant pas d'assurer 
> > l'integrite de ce message, ALCATEL ALENIA SPACE (et ses filiales)
> > decline(nt) toute responsabilite au titre de ce message, dans 
> > l'hypothese ou il aurait ete modifie.