New upstream version 1.2.3
[quagga-debian.git] / bgpd / IMPLEMENTATION.txt
diff --git a/bgpd/IMPLEMENTATION.txt b/bgpd/IMPLEMENTATION.txt
deleted file mode 100644 (file)
index fff360a..0000000
+++ /dev/null
@@ -1,169 +0,0 @@
-$Id: IMPLEMENTATION.txt,v 1.2 2005/02/15 17:10:03 gdt Exp $
-
-This file contains notes about the internals of the BGP
-implementation.  The initial impetus is understanding the memory usage
-of Quagga'a BGP implementation.  There may be some inaccuracies; it is
-in the repository in the hopes that it will be significantly more
-helpful than not.
-
-* FILES
-
-bgp_advertise.[hc]:
-  data structures: advertised prefixes, attributes
-
-bgp_aspath.[hc]:
-  struct aspath:
-    These are stored in a hash, apparently in wire format.
-bgp_attr.[hc]:
-  struct attr: contains all attributes
-    size(ILP32) 26 words/104 bytes (poor packing, v6/multicast is 10)
-
-  bgp_attr_parse: origin, aspath, next hop probably most of interest
-  bgp_attr_origin: set flag bit
-  bgp_attr_aspath: put in refcounted hash table, so share pointer
-  bgp_attr_nexthop: store in attribute structure
-
-bgp_btoa.c: ? test program
-
-bgp_clist.[hc]:
-  data structures: community lists (including permit/deny state)
-
-bgp_community.[hc]:
-  data structures: community atttributes (multiple communities per struct)
-
-bgp_damp.[hc]:
-  per-route damping data, and damping control information
-
-bgp_debug.[hc]:
-  debugging support (vty config, dump of packets)
-
-bgp_dump.[hc]:
-  MRT-compatible dump format routines
-
-bgp_ecommunity.[hc]:
-  Extended communities attributes (multiple ecommmunities per struct)
-
-bgp_filter.[hc]:
-  AS path access list filtering
-
-bgp_fsm.[hc]:
-  Per-peer state machine for TCP connection, hold time, etc.
-
-bgp_main.c:
-  Daemon startup.
-
-bgp_mplsvpn.[hc]:
-  parsing of attribute structures for MPLS VPNs [need better description]
-
-bgp_network.[hc]:
-  Opening and binding of sockets, finding addresses for interfaces
-
-bgp_nexthop.[hc]:
-  data structures: Nexthop cache [not clear how used, if truly cache
-  in sense of memoization, or something else]
-
-  importing EGP routes into IGP (thread created)
-  "scanning" (thread created)
-  bgp_scan: has useful clues to data structure complexity.  Scanning
-  process iterates over database of received advertisements, and
-  builds 'cache' structure.
-bgp_open.[ch]:
-  Open messages, and capability negotiation
-
-bgp_packet.[hc]
-  sending and receiving of UPDATE/WITHDRAW
-  collision resolution for simultanteous opens
-  bgp_read: top-level read routine: reads whole packet (nonblocking)
-    and dispatches to per-message-type receive
-
-  bgp_update_receive:
-    calls bgp_attr_parse
-    reads nrli into struct bgp_nrli update
-
-    uninterning of aspath, community, ecommmunity, cluster,
-    transit which were interned in bgp_attr_parse
-
-bgp_regex.[ch]:
-  Glue to convert BGP regexps to standard (_ means many things).
-
-bgp_route.[hc]:
-  data structures: routes as received, static routes
-  Application of filters.  Lots of route processing.
-  bgp_nlri_parse:
-    sanity checks, then calls bgp_update with peer, prefix, attributes pointer
-
-  bgp_update: bgp_update_main, then RS processing
-
-  bgp_update_main:
-    find 'struct bgp_node *' for this afi/safi
-    look for route in table, then 'intern' attributes
-    ** interning is process of
-      looking for data in hash table, and putting there if missing, refcnt
-      using pointer to existing data
-    many validity checks
-    get new struct bgp_info (10 words/40 bytes)
-    call bgp_info_add with rn and bgp_info
-    call bgp_process
-
-bgp_routemap.c
-  implementation of route maps (match and set)
-
-bgp_snmp.c
-  SNMP glue.  Not particularly interesting except to add variables or
-  debug SNMP.
-
-bgp_table.[hc]
-  data structures: struct bgp_table, struct bgp_node
-  allocation/lookup/utility operations - not a lot of protocol processin
-
-bgp_vty.[hc]
-  protocol-wide vty hooks
-
-bgp_zebra.[hc]
-  Processing interface events from zebra, redistribution of routes.
-
-bgpd.h
-  struct bgp_master: daemon main data structure 
-  struct bgp: per-instance structure
-  struct peer_group
-  struct bgp_notify: (in-core representation of wire format?)
-  struct bgp_nexthop: (v4 and v6 addresses, *ifp)
-  struct bgp_rd: router distinguisher: 8 octects
-  struct bgp_filter: distribute, prefix, aslist, route_maps
-  struct peer: neighbor structure (very rich/complex)
-  struct bgp_nlri: reference to wire format
-  #define of protocol constants
-    attribute type codes
-  fsm states/events
-  timer values
-
-bgpd.c
-  instance/peer allocation
-  configuration
-  initialization/termination
-
-* DATA STRUCTURE SIZES
-
-Question: How much memory does quagga's bgpd use as a function of
-state received from peers?
-
-It seems that a struct bgp_info is kept for each prefix.  The "struct
-attr *" is interned, and variables within that are interned.  So, 40
-bytes are kept per received prefix, plus interned shared values.  This
-could be 36 if 'int suppress' where changed to a u_char and moved to
-be with the other u_chars.  Without MPLS, this could be 32 bytes.
-Note that 8 bytes of this is linked list overhead, meaning that 24
-bytes are the raw per-prefix storage requirements.
-
-Also, a struct bgp_damp_info is apparently maintained per route; this
-is fairly large (about 44 bytes).
-
-[TODO: the role of struct bgp_node.]
-
-* TIME COMPLEXITY
-
-It appears that received prefixes from each peer are stored in a
-linked list.