[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd to ipdvb: [Réf. : The real benefits of ULE compared to MPE] From Laurence Duquerroy
On Tue, 22 Nov 2005, Gorry Fairhurst wrote:
> 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,
Essential, actually. This is essential practice when writing code on
multiprotocol routers to prevent misinterpreting other frames and
generating forwarded junk. For those who only believe RFCs, original
behaviour is described in RFC1122 section 3.2.1.1. This was updated by
RFC2460, which added IPv6 to the standards.
('driver' is such an endhost term.)
L.
> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>
<http://www.ee.surrey.ac.uk/Personal/L.Wood/><L.Wood@eim.surrey.ac.uk>