No subject
Fri Dec 10 14:40:18 2004
Return-Path: xorp-cvs-admin@icir.org
Delivery-Date: Fri, 10 Dec 2004 06:41:01 -0800
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by tigger.icir.org (8.12.11/8.12.8) with ESMTP id iBAEf17h004840
for <atanu@tigger.icir.org>; Fri, 10 Dec 2004 06:41:01 -0800 (PST)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iBAEf1Fw008303
for <atanu@icir.org>; Fri, 10 Dec 2004 06:41:01 -0800 (PST)
(envelope-from xorp-cvs-admin@icir.org)
Received: from fruitcake.ICSI.Berkeley.EDU (localhost [127.0.0.1])
by fruitcake.ICSI.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id iBAEf1UF006463;
Fri, 10 Dec 2004 06:41:01 -0800 (PST)
Received: from wyvern.icir.org (wyvern.icir.org [192.150.187.14])
by fruitcake.ICSI.Berkeley.EDU (8.12.10/8.12.9) with ESMTP id iBAEeIUF006437
for <xorp-cvs@icsi.berkeley.edu>; Fri, 10 Dec 2004 06:40:19 -0800 (PST)
Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68])
by wyvern.icir.org (8.12.9p1/8.12.8) with ESMTP id iBAEeIFw008299
for <xorp-cvs@icir.org>; Fri, 10 Dec 2004 06:40:18 -0800 (PST)
(envelope-from bms@icir.org)
Received: from xorpc.icir.org (localhost [127.0.0.1])
by xorpc.icir.org (8.12.11/8.12.8) with ESMTP id iBAEeIBU015235
for <xorp-cvs@icir.org>; Fri, 10 Dec 2004 06:40:18 -0800 (PST)
(envelope-from bms@xorpc.icir.org)
Received: (from bms@localhost)
by xorpc.icir.org (8.12.11/8.12.3/Submit) id iBAEeIkG015234
for xorp-cvs@icir.org; Fri, 10 Dec 2004 14:40:18 GMT
(envelope-from bms)
Date: Fri, 10 Dec 2004 14:40:18 GMT
From: Bruce Simpson <bms@icir.org>
Message-Id: <200412101440.iBAEeIkG015234@xorpc.icir.org>
To: xorp-cvs@icir.org
X-XORP-CVS-Branch: HEAD
Subject: [Xorp-cvs] XORP cvs commit: xorp/fea xorp/xrl/interfaces xorp/xrl/targets
Sender: xorp-cvs-admin@icir.org
Errors-To: xorp-cvs-admin@icir.org
X-BeenThere: xorp-cvs@icir.org
X-Mailman-Version: 2.0
Precedence: bulk
List-Help: <mailto:xorp-cvs-request@icir.org?subject=help>
List-Post: <mailto:xorp-cvs@icir.org>
List-Subscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=subscribe>
List-Id: Mailing list for XORP CVS commit messages <xorp-cvs.icir.org>
List-Unsubscribe: <http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs>,
<mailto:xorp-cvs-request@icir.org?subject=unsubscribe>
CVSROOT: /usr/local/www/data/cvs
Module name: xorp
Changes by: bms@xorpc.icir.org 2004-12-10 14:40:18 UTC
XORP CVS repository
Added files:
fea pa_backend.hh pa_backend_dummy.cc
pa_backend_dummy.hh pa_entry.cc pa_entry.hh
pa_table.cc pa_table.hh pa_transaction.cc
pa_transaction.hh xrl_packet_acl.cc
xrl_packet_acl.hh
xrl/interfaces packet_acl.xif packet_acl_xif.cc packet_acl_xif.hh
xrl/targets packet_acl.tgt packet_acl.xrls packet_acl_base.cc
packet_acl_base.hh
Log message:
Introduce the packet ACL code as a replacement for the old,
snafu'd firewall design. This considerably simplifies
the back-end design and introduces a transaction-driven
interface.
Stylistic changes:
Change prefix Fw -> Pa so as to avoid any confusion between
IPF, PF, IPFW, and what XORP's code is. It is probably
slightly easier to pronounce, but not much.
Design assumptions:
1. The FEA is assumed to be the sole entity managing the
back-end ACLs.
2. All communication with the kernel is one-way; the FEA
pushes ACLs to the kernel. Notification from the kernel,
at the top level, is assumed to only be of the kind 'this
operation succeeded or failed'. This may be expanded in
future if the first assumption changes.
3. All access to the FEA's ACLs is via a transaction-driven
interface to ensure atomicity of updates.
4. Snapshots of the FEA's ACLs are taken just before
transactions are committed to ensure consistency.
Transactions which fail are rolled back to the previous
snapshot by reloading the FEA's snapshot, and pushing it
back down to the kernel. This update is atomic; see
point 5 next.
5. The push to the underlying ACL back-end inside the kernel
is atomic on a per-transaction basis, *if* and *only if*
the back-end supports this. For back-ends which do not
support the notion of transaction atomicity, the FEA
will attempt to emulate such atomicity, in some cases,
by taking snapshots of the kernel's ACL state also.
This is also done when rolling back (as in point 4).
Revision Changes Path
1.1 +106 -0 xorp/fea/pa_backend.hh (new)
1.1 +110 -0 xorp/fea/pa_backend_dummy.cc (new)
1.1 +92 -0 xorp/fea/pa_backend_dummy.hh (new)
1.1 +48 -0 xorp/fea/pa_entry.cc (new)
1.1 +182 -0 xorp/fea/pa_entry.hh (new)
1.1 +203 -0 xorp/fea/pa_table.cc (new)
1.1 +185 -0 xorp/fea/pa_table.hh (new)
1.1 +201 -0 xorp/fea/pa_transaction.cc (new)
1.1 +296 -0 xorp/fea/pa_transaction.hh (new)
1.1 +640 -0 xorp/fea/xrl_packet_acl.cc (new)
1.1 +375 -0 xorp/fea/xrl_packet_acl.hh (new)
1.1 +200 -0 xorp/xrl/interfaces/packet_acl.xif (new)
1.1 +570 -0 xorp/xrl/interfaces/packet_acl_xif.cc (new)
1.1 +409 -0 xorp/xrl/interfaces/packet_acl_xif.hh (new)
1.1 +7 -0 xorp/xrl/targets/packet_acl.tgt (new)
1.1 +175 -0 xorp/xrl/targets/packet_acl.xrls (new)
1.1 +758 -0 xorp/xrl/targets/packet_acl_base.cc (new)
1.1 +380 -0 xorp/xrl/targets/packet_acl_base.hh (new)
_______________________________________________
Xorp-cvs mailing list
Xorp-cvs@icir.org
http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-cvs