Subject: Re: LFB topology reconfguration

From: "Putzolu, David" <[email-masked]>
Date: Fri, 7 Nov 2003 15:58:59 -0800

[chair hat off]

> From: Forwarding and Control Element Separation 
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Thursday, November 06, 2003 7:33 AM
> To: [email-masked]
> Subject: Re: [FORCES] LFB topology reconfguration
> 
>   For me, the boundary between internal changes to an LFB's
> configuration, and changes to inter-LFB connections is most often a
> protocol boundary.  Provisioning new connections/services within a
> protocol requires updating entries in the LFB's which implement that
> protocol.  Provisioning a new protocol requires re-arranging LFB's, or
> creating new LFB's.

Hi Alan.

Can you (or others) clarify a bit further on this?

In particular, I am trying to understand if there is a requirement
to add support for entirely new protocols (or other such actions 
requiring LFB rearranging) at run time, and if so, what is the 
concrete example that requires a LFB-rearranging mechanism?

My impression is that the state of the art engineering approach
is to bring down blades one at a time to upgrade their 
firmware/software/hardware functions, using active/passive or
other HA mechanisms to retain non-stop forwarding in the face of
upgrades.  In this sort of approach there is indeed FE LFB 
topology change,  but that change occurs while an FE is offline
(and thus not during the post-association phase).

I am aware of active networking approaches that allow a more 
dynamic, runtime-based reconfiguration of FE functionality.  
Are these what people have in mind, and if so,  are they 
engineering practice (shipping product) or still research?

Thanks,
David

---

From: Jamal Hadi Salim <[email-masked]>
Date: Fri, 7 Nov 2003 17:43:34 -0800

Packet massaging starts at the classifier; this is followed by
one or more LFB instances that do something to the packet.
You could define the massaging of the packet as a service.
A simple rearrangement of such as a service could be to temporarily
add a mirroring LFB instance for debug or other reasons and then
removing it later. This does not require bringing down anything.
There are more interesting things, but this is within the charter.
Whether the mirroring LFB shows up at ASIC design time or
10 years later as downloaded firmware to an FPGA or a software
kernel module is beyond the scope of Forces.
IMO it does not in any way affect how a ForCES protocol should look like.
Infact theres no point in even discussing the issue of how it got there.
Forces role is to configure from the CE what it knows the FE can do.

I think theres a mental block which results from a COPS mindset
that is affecting how people are thinking about this.
For simplicty sake assume that the LFBs already exist ...

cheers,
jamal

---

From: Robert Haas <[email-masked]>
Date: Sun, 9 Nov 2003 22:27:26 +0100

On the active networking (AN) question raised by David:

There are roughly two approaches in AN, one is the really active 
approach (each packet specifies the code that it must be processed with 
in its journey through the network). The other is the programmable 
approach, in which code/plug-ins/service-modules are dynamically added 
into network nodes by some signaling mechanism. An example of each: 
                            
1) An active packet may specify which LFBs it want to be processed with. 
New specific LFBs may have to be "installed". The "path" across LFBs is 
decided by the packet itself. One LFB may even be a virtual execution 
environment.

2) A new service may be deployed in a network by specifying how LFBs 
should be configured, possibly requesting new LFBs to be "installed" 
wherever possible/necessary.

2) is receiving much attention in the (european) AN community nowadays. 
It addresses the problem of dynamic service provisioning, which is 
believed to be crucial for ISPs to switftly provide competitive 
services. The relevance of ForCES is therefore high, as interoperable 
products depend on it.

For those interested in further reading, there are various papers 
describing implementations of AN in network processors, one I 
co-authored in the August 2003 issue of IEEE Network. More by Roman 
Pletka et al in the upcoming IWAN 2003 conference.

Regards,
-Robert

-- 
Robert Haas
IBM Zurich Research Laboratory
Säumerstrasse 4
CH-8803 Rüschlikon/Switzerland
phone +41-1-724-8698  fax +41-1-724-8578  http://www.zurich.ibm.com/~rha

---

From: Alan DeKok <[email-masked]>
Date: Sun, 9 Nov 2003 13:46:02 -0500

> concrete example that requires a LFB-rearranging mechanism?

 My examples about LFB re-configuring & topology change were meant to
demonstrate what behaviours could cause LFB topology to change.  I
wasn't trying to say that we should require that behaviour in ForCES.

> (and thus not during the post-association phase).

  I agree.

> engineering practice (shipping product) or still research?

  So far as I know, they're still research.

  Alan DeKok.