[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

Concerning that "type" field over MPE (in LLC/SNAP) and ULE:
-Many papers and studies point out the increased flexibility of ULE over MPE for specifying the protocol carried (in terms of e.g. overhead and complexity), especially when it is not IP, since LLC/SNAP should be used as Laurence pointed out.
 
Regarding this issue, my question concerns only satellite links:
- Is *actually* MPE used for carrying oher protocols than IP? If yes, what proportion of this traffic is non-IP traffic? What about ULE ?
 
That leads me to another question, that is closely related to what is beeing discussed here:
- At a previous discussion concerning the support for non-IP traffic (IPDVB archive for 0508: non-IP Protocol Support), it was said that a an "IP tunnel" approach could not always work, and the classical example of ARP was given. However, and if we think of satellite-networks again, do we really have ARP requests over satellite links? (If yes, can't we cope with this problem using IP-based solutions such as a distributed or centralized Addres Resolution Server?). Besides ARP, what else could make a foo-over IP solution not to work over satellite links? 
 
Where is the glitch? If this solution worked, there would be no problems regarding type fields or version tests, and solve many many more issues, as e.g. L2-L3 address parsing.
 
Many thanks for throwing some light on this issues!
 
Juan
 
Juan
 
 
 
 
2005/11/22, Marie-Jose Montpetit <marie@mjmontpetit.com>:
Just one short comment:

actually when we did a study of ULE vs. MPE with ns (the code BTW has
been used by many people) and queueing the results were not as clean
cut as "short" vs. "long" packets.

Sure because we could pack a number of short packets in a single payload
there was an obvious gain but only if no other cost was taken into
account (for example can you wait for all those packets to arrive
without killing your end to end delay and jitter statistics). MPE also
can do the packing BTW as was reported on this list.

And sure again for really long packets the MPE overhead becomes less an
issue. But overall it was more complex than that.

There are a number of packets in the middle between "short" and "long"
and there are many options that can be turned on and off to improve one
cost element over another. And one thing we did find is that ULE was
offering more flexibility in packing options who for us usually looking
above IP was an advantage. And this was not also taking into account any
header compression scheme.

This said I do agree that there are commercial elements we did not take
into account either...

/mjm

> -------- Original Message --------
> Subject: Re: Fwd to ipdvb:  [Réf. : The real benefits of ULE compared
> to MPE] From Laurence Duquerroy
> From: Lloyd Wood < l.wood@eim.surrey.ac.uk>
> Date: Tue, November 22, 2005 6:28 am
> To: ipdvb@erg.abdn.ac.uk
>
> 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 MailScanner has detected a possible fraud attempt from "3.2.1.1" claiming to be MailScanner warning: numerical links are often malicious: 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>