[Ns-developers] Possible approaches to modelling optical pass through devices

Tommaso Pecorella tpecorella at mac.com
Sun Mar 11 05:06:38 PDT 2012


Hi Vedran,

I'd go for sure toward the 3rd approach. The optical switch is a kind-of bridge, just with some intelligence in it.

The main problems I see are:
1) how to integrate the optical signaling protocol (GMPLS?) in those, as is what's the MAC address (single, multiple?) of he devices and
2) how to simulate the device-delays.

The problems, mind, are close related.

Optical switches (I'm digging old memory, might be outdated) are passthrough-with-data-spilling, so there might be a delay added by each of them. Since we're talking with lightspeed data, even a 1 bit delay is significant. We shall model it by adding some delay in the forwarding. Same goes for packet recv, it happens when the packet is fully decoded, so add a delay equal to the lighspeed + packet length and so on.
This basically affects how a switch can find out if a packet is it's own or not (thus to be forwarded or not).

Mind, again, that my old memory comes from when I was working with DQDB, many years ago.

So, going to a different but related topic: how does an optical switch find out that a packet is a signaling packet directed to it ?

In DQDB the interfaces had a true MAC address (even if it was ultra-short), but I don't know what's the standard nowadays. If you can find out this point, then you'll have your "MAC address". It might be as well a particular optical wavelength, but it's still an "address", so you can use it to identify your NetDevice and half of your issues will be fixed.

If, on the other hand, the Optical Switch can NOT be reached by the optical network and, for example, you need a completely separate network for the signaling, then your problem is solved: your NetDevice is not a NetDevice as it can NOT have any L3 layer above it.

Don't go mad now, the point you might have missed is simple. In ns-3 all the devices are modeled with a NetDevice, as is you can put L3 above anything. A bridge is not a router *just* because we don't stack IP above it. However we don't have any different implementation for a pure hub and a PC with a bridged interface.

On the other hand there's nothing against the approach to make them different. Let me make a picture...

  ..............
  | Signaling  |..........
  :.............         |Signaling
  |  IP        |         |Interface
  ;''''''''''''',--------+-------.
  | NetDevice  || Optical Switch |
  '`''''''''''' '`'''''''''''''''' 

The "Optical Switch" device is not a NetDevice and is doing the real switching. The NetDevice is the one where the signaling is actually caught and might be a promiscuous interface over the very same channel used by the other interface or a completely different one, or something grabbing the data through filtering from the actual OpticalSwitch. It depends on the actual "MAC" question above.

The "true" NetDevices will be similar but not identical, as a terminating device does not need to do any switching at all. So basically you'll have two very different device, one being a NetDevice (source and end), one being the signaling interfaces for the switches and one being the actual switch device.


Does this makes any sense ?

Cheers,

T.





On 11 Mar 2012, at 12:00, Vedran Miletić wrote:

> Hi,
> 
> I'm hoping to post somekind of repository with somekind of working
> optics, but I have to decide on this before proceeding.
> 
> In optics there is a lot switch or hub-like devices with some kind of
> "pass through" property, i.e. device just forwards packets (better say
> signals but let's ignore this for now) in various ways. Some of them
> also have a control plane that understands IP routing and changes
> their state in accordance to messages exchanged with peers over IP. I
> see a couple of different approaches to modelling this. Let's see an
> example with modelling optical cross connect (OXC), which is some kind
> of a switch.
> 
> First off, modelling switching tables is not a problem, a properly
> used std::map<> work just fine here. However, ns-3 architecture (or
> optics) does seem tricky. There are three approaches that I see:
> 
> 3) Make WdmOxcDevice : public Object and add WdmOxcControlNetDevice
> that would have PtP connection to peer devices at other Nodes and work
> with Ipv4GlobalRouting to handle changing switch forwarding tables.
> Would a BridgeNetDevice work for this instead?
> 
> And the main question is: if I missed it completely, what is the
> general approach to modelling pass through devices in ns-3 and in
> which cases and how should one "aggregate" channels, as it was done in
> BridgeChannel?
> 
> Thanks in advance.
> 
> Vedran

--------------------------------------------------------------

$25: for you a pizza and some beers with friends, for someone 
     might change their lives. Think about it.

Kiva.org - Loans That Change Lives

--------------------------------------------------------------

Tommaso Pecorella - Ph.D.

Assistant professor
Dpt. Elettronica e Telecomunicazioni
Università di Firenze

CNIT - Università di Firenze Unit

via di S. Marta 3
50139, Firenze
ITALY

email: tommaso.pecorella at unifi.it
       tommaso.pecorella at cnit.it

phone : +39-055-4796412
mobile: +39-320-4379803
fax   : +39-055-494569









More information about the Ns-developers mailing list