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

Vedran Miletić rivanvx at gmail.com
Mon Mar 12 10:25:44 PDT 2012


Hi Tom and Tommaso,

thanks for your responses.

11. ožujka 2012. 13:06 korisnik Tommaso Pecorella <tpecorella at mac.com>
napisao je:
> 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

Optical switch probably, but optical cross connect is a bit more
exotic. Using GMPLS it works roughly like this: edge router receives
packets to be sent through optical network, and buffers them. Upon the
receipt of the first packet to a new destination it sends a request to
set up a path (Path),  which is processed by control planes of all
OXCs in optical network. A reply comes from other end edge router
(through the same control planes) in form of resources reserved
message (Resv). I belive this is RSVP-TE, but I haven't looked into it
that deeply yet.

> what's the MAC address (single, multiple?) of he devices and

I believe that control plane which has multiple (point-to-point)
connections has a single MAC address. I can't claim that for sure,
since I haven't ever used such a device in real world.

> 2) how to simulate the device-delays.

That seems quite easy compared to architectural stuff. I will either
put them into Send() method or use any nicer way suggested. But that's
not the priority yet.

> 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.

OXCs don't read data, they just let it pass from source to destination
port in accordance to switch tables.

> 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 ?

It doesn't, as data isn't read at all.

> 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.

That's probably it. It can't be, but it's control layer can.

> 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 ?

It does. But there is still this problem:
1) if Oxc is a NetDevice, I should be able to put L3 above it; in that
case we have a problem of having a device that is attached to many
channels and just forwards packets (with the exception of control
ones); that is going to confuse L3, right? It expects to have an
address range in each NetDevice -- Channel -- NetDevice, and this
approach doesn't allow that.
2) If Oxc is not a NetDevice, how can I attach it to a Channel and do
ScheduleWithContext stuff on packets?

Please state if I wasn't clear on any part; I really need to solve
these design issues before proceeding.



12. ožujka 2012. 05:33 korisnik Tom Henderson <tomh at tomh.org> napisao je:
> Can you comment more on the IP routing and addressing model that you have in
> mind?  Is this GMPLS-based (RFC 3945)?  Is it the case that these switches
> will make (dynamically) available, to IP-enabled nodes, some label-switched
> path (LSP) between the nodes?

Yes, that's the idea, that or OpenFlow control plane.

> Assuming that is the case, then my first impression is that you will want
> some kind of new NetDevice at the IP link endpoints, and you probably can
> model the switch and optical network itself however is most natural for you,
> because Ipv4GlobalRouting is not going to work over this kind of a dynamic
> optical switched network without modifications (and it is debatable whether
> it is within scope for global routing, which is intended for static
> topologies).  We may also want to consider MPLS support and its ns-3 design
> while we are defining this.

We have been looking into Andrey Churin's code at ns-3-shop, we don't
understand quite a bit of it, but it can probably be used with some
modifications.

Vedran

> - Tom




More information about the Ns-developers mailing list