Merge pull request #3367 from karamalla0406/frr3333

[mirror_frr.git] / bgpd / IMPLEMENTATION.txt

$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_path_info
    call bgp_path_info_add with rn and bgp_path_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_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_path_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.