Subject: [vnfpool] pool manager for state sync?

From: Zongning <[email-masked]>
Date: Thu, 26 Sep 2013 07:09:20 +0000

Hi, all,

In current RSerPool mechanism, the service states (for stateful service like FW) are synchronized between active and backup servers via the relay of pool user. This approach works fine assuming that pool user is stable. Consider the VNF pools model where a pool user (i.e. user of downstream pool according to service chain) is normally a VNF instance in its own pool, and pool user and even its backup instances are likely less stable. As such, storing critical service states information in VNF instances would be a problem. I'd think a feasible approach would be to use pool manager for service states synchronization, e.g. retrieving, storing, distributing service states amongst VNF instances?
Comments are highly appreciated!

-Ning

---

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 30 Sep 2013 10:00:54 +0200

Hi,

Torsdag 26. september 2013 07.09.20 skrev Zongning:
> Hi, all,
> 
> In current RSerPool mechanism, the service states (for stateful service like
> FW) are synchronized between active and backup servers via the relay of
> pool user. This approach works fine assuming that pool user is stable.
> Consider the VNF pools model where a pool user (i.e. user of downstream
> pool according to service chain) is normally a VNF instance in its own
> pool, and pool user and even its backup instances are likely less stable.
> As such, storing critical service states information in VNF instances would
> be a problem. I'd think a feasible approach would be to use pool manager
> for service states synchronization, e.g. retrieving, storing, distributing
> service states amongst VNF instances? Comments are highly appreciated!

This sounds useful.

Originally, RSerPool did not intend to define any state synchronisation. But 
ASAP has the ASAP Cookie/ASAP Cookie Echo mechanism built in, because it is 
very simple and therefore easy to implement and may be useful for a number of 
applications. It is, however, somewhat limited: the cookie size is < 64 KiB, 
the state should not change too often to avoid network overhead, and security 
has to be ensured so that a malicious PU does not use the same cookie for 
resumption on multiple PEs.

Since VNF is a specific application, it makes sense to define a specific state 
synchronisation approach. May be, "state synchronisation for VNF" could be 
another service on top of RSerPool? That is, RSerPool would not be modified to 
add state synchronisation but a service that realises it could be realised 
based on RSerPool? This would separate the application-specific task from the 
pool management task. Of course, pool management (i.e. the PR) and state 
synchronisation management could be deployed on the same machines.

-- 
Best regards / Mit freundlichen Grüßen / Med vennlig hilsen

=======================================================================
 Thomas Dreibholz

 Simula Research Laboratory
 Simula Innovation AS, Network Systems Group
 Visiting address: Martin Linges vei 17, 1364 Fornebu, Norway
 Mailing address:  P.O.Box 134, 1325 Lysaker, Norway
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://simula.no/people/dreibh
=======================================================================