Re: Non-IP Protocol Support

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

Do you mean something like this, at the Receiver?

         decapsulation of L2 over IP
      /- ****** --\
      |           |
    +-|---------+ |
    | |         | |
    | |         | | IP Module
    | ^         | v
    | |         | |
    +-|---------+ | (IP Interface)
    | |         | |
    | |  ^      | |  Link
    | |  |      | |
    | |  O------|-O
    +-|---------+  (ULE Interface)
    | |         |
    | |         |   MPEG-2 TS
    | |         |
    | |         |
    --|----------
      |

This architecture is more painful than something like PWE3, where the
interface on which the tunnelled L2 frames are presented is usually
different to that on which they are received. In this case, you would tunnel
over IP to decapsulate, and then post the frame back into the same Link
layer below the same IP module interface.

There is (of course) overhead here added to L2 amd there are a few details
that would need to be worked out: the issue of discovery of the
(link-local?) multicast address, etc.

Gorry

On 4/8/05 3:23 pm, "West, Mark" <mark.a.west@roke.co.uk> wrote:
> 
> Indeed, RFC 3251 may be worth considering :-)
Hmmmm, not so useful ;-).

> But seriously...
> 
> ... could I not encapsulate ARP, in that case, over multicast IP?
> 
> It may be that this conversation is a little premature, in that there are
> other questions about security that aren't directly related to this.  But
> if you can't tunnel stuff over IP to bootstrap, for example, then I'm
> suspicious of using an IP-based architecture to set-up a non-IP-based
> security system.  (If that makes any sense?!)
> 
> Cheers,
> 
> Mark.
> 
> 
>> 
>> The IETF have defined several foo-over-IP methods which could be used,
>> and
>> these should work with ULE (bidirectional IP connectivity may be
>> required).
>> PWE3 is by no means the only option.
>> 
>> However, there are situations were this tunnel over IP approach really
>> does
>> not do what may be wanted. ARP for IPv4 is a classic example. If you
>> wanted
>> to use arp to resolve an IP to MAC address, then clearly you can't
>> encapsulate this over IP to send it.
>> 
>> Gorry
>> 
>> On 4/8/05 12:40 pm, "West, Mark" <mark.a.west@roke.co.uk> wrote:
>> 
>>> 
>>> A further comment on Juan's point (and something that came up in
>>> discussion after the ipdvb session, yesterday)...
>>> 
>>> If there is a security mechanism for IP (e.g. IPsec) and you want to
>> apply
>>> that to non-IP flows (e.g. a stream of SNDUs, Ethernet frames, ...)
>> then
>>> why not run the non-IP over an emulated pseudo-wire within the IPsec
>>> tunnel?  Then you only need an IP-based security solution.
>>> 
>>> I honestly don't know whether this is appropriate, but it seemed like
>> an
>>> interesting idea at the time!
>>> 
>>> 
>> (http://www.ietf.org/internet-drafts/draft-ietf-pwe3-iana-allocation-11.
>> txt
>>> already has codepoints for Ethernet, etc., but not anything specific
>> to
>>> the ipdvb case.)
>>> 
>>> Cheers,
>>> 
>>> Mark.
>>> 
>>> --
>>> Mark A. West, Senior Consultant Engineer
>>> Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
>>> Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433
>>> 
>> 
>> 
>>