MODIFICATION HISTORY: -------------------- -------- version 1.5.0 ----------------------------------------------- ** 2003.02.07: Added Route Flap Damping Merged in code from Z. Morley Mao to support route flap damping. See these options: route_flap_damping, punishLess, and newRFD. ** 2003.01.31: Bolstered autoexit Option This option is now more careful about exiting a simulation early. It is an experimental option not intended for general use. ** 2003.01.19: Fixed Outdated Advertisement Bug Certain sequences of events could lead to incorrect advertisements being sent. Now, before a waiting update or withdrawal is sent, we check the appropriate Adj-RIB-Out to make sure that we're sending the same thing which appears there. ** 2002.12.18: Added always_run_dp Option This option allows sets whether to always run the Decision Process when a new route is inserted into an Adj-RIB-In. The original RFC (1771) had complicated rules for determining wether or not the Decision Process should be run. Newer drafts of the next version of the BGP specification (as of 2002-11-04) state that the Decision Process should always be run when a new route is inserted into an Adj-RIB-In. ** 2002.12.18: Fixed Decision Process Multiple Prefix Bug Fixed a bug in which multiple prefixes in the same update message would be handled improperly. This will not affect most simulations since there is almost always only one prefix per AS. ** 2002.12.17: Added synchronized_mrai_timers Option An option to keep MRAI timers synchronized for a particular type of experiment. Not intended for general use. ** 2002.12.17: Fixed continuous_mrai_timers Bug When both NO_PROC_DELAY and continuous_mrai_timers were in use, messages would get put in outbuf, which should not used with NO_PROC_DELAY. ** 2002.12.16: Fixed Bug Regarding Simultaneous Updates Added BGPSession.burst_id and PeerEntry.latest_sent_burst_id to avoid possible incorrect behavior when two updates for the same destination arrive simultaneously and are processed at the same simulation time (ie, no processing delay is being used). This is a very rare case and very few pre-existing models are likely to have been affected by it. ** 2002.12.09: Fixed Table Dump Bug After a reboot and connection reestablishment, only one update would be sent to the rebooted BGP speaker from each of its peers. All other updates were then being forced to wait for one MRAI before being sent. ** 2002.10.28: Added simple_policy Option to Reduce Memory Usage An optimization in which the filtering policy always permits all routes, and assigns degrees of preference which prefer shorter AS paths. If this option is used, no filtering policies can be configured in DML--they will automatically be enforced as described. ** 2002.10.26: More Small Memory Usage Improvements In PeerEntry, added 'flags' field and removed the binary fields 'type', 'subtype', 'connected', and 'firstconnect'. Removed HashMaps for socket information when Global.simple_restarts is true and used bit flags instead. ** 2002.10.24: 'Community' Corrected to 'Communities' Changed all instances of 'Community' to 'Communities' to reflect the correct name of the path attribute. ** 2002.10.23: Added Additional Small Memory Usage Improvements Path attributes no longer have three booleans for permissibility, feasibility, and inlocrib--just one flags byte. Also, attributes no longer have three booleans for optional, transitive, and partial--they just have hard-coded methods which return the value. ** 2002.10.23: Added basic_attribs Option to Reduce Memory Usage This memory optimization allows only the use of the three most basic path attributes: AS path, LocalPref, and NextHop. ** 2002.10.23: Added linked_aspaths Option to Reduce Memory Usage This memory optimization is an improvement over flat_aspaths. An AS path must still be flat, as in flat_aspaths, and aggregation and AS path modification (other than standard AS prepending when advertising to an eBGP peer) are prohibited. AS paths are distributed via linked lists between Route objects, rather than each Route having its own separate copy of the AS path, since AS paths are highly overlapping. It will not work properly if running SSFNet distributedly. ** 2002.10.22: Added flat_aspaths Option to Reduce Memory Usage In this memory optimization, AS paths may only contain a single sequence of AS numbers. This option prevents aggregation. ** 2002.10.22: Added radix_trees Option to Reduce Memory Usage Allows use of radix trees in the RIB to be turned off, saving memory. Only hash tables are used. This means that aggregation can't be used, though aggregation is currently not fully (or properly) implemented anyway. ** 2002.10.21: Added simple_restarts Option Allows BGP to die and restart but always use the same sockets. This avoids some complexities of freeing sockets, and is only a temporary workaround. TCP connections are never broken either. ** ---------- Additional Minor Changes -- 2003.03.04: removed redundant setting of KeepAlive timer & MRAI timer -- 2003.03.04: reduced likelihood of stack overflow by pruning NoticeUpdates -- 2003.03.03: fixes to serialization code for distributed support -- 2003.02.10: corrected problem with autoexit timer -------- version 1.4.15 ---------------------------------------------- ** 2002.08.22: Repeated Withdrawals Bug Fix It was possible, under certain circumstances, for two consecutive withdrawals for the same NLRI to be sent from a BGP speaker to the same peer. The note_last_sent option, as introduced in version 1.4.14, now prevents such consecutive withdrawals (in addition to its original purpose of preventing identical consecutive advertisements). ** 2002.08.12: Added low_mrai_exp_priority Option A global option indicating whether or not MRAI expiration events should have lower priority than RecvUpdate events. MRAI expiration events normally have higher priority than incoming update messages; that is, when an MRAI timer expires, that event is handled before any incoming update messages that may already be waiting to be processed. With low MRAI expiration priority, the two types of events have equal priority. The default value is false. ** 2002.08.11: Added ignore_repeat_ads option A global option indicating whether or not BGP should ignore an advertisement which is identical to the previous advertisement received for the same destination from the same peer (and having no withdrawal or session reset in between the two). Ignoring such repeat advertisements is required by RFC 1771, and thus the default is true. ** 2002.08.05: Added First-Come First-Choice Tie-Breaking A global option indicating whether or not the tie-breaking mechanism for route preference, which normally reverts to BGP ID as a last resort, will instead choose the least recently learned (or first learned) route. It is also known as the first-come, first-chosen method of last-resort tie-breaking. The default value is false. -------- version 1.4.14 ---------------------------------------------- ** 2002.07.28: Keeping Track of Most Recently Sent Update New functionality has been added to keep track of the most recently sent advertisements, which prevents identical consecutive advertisements that can occur in certain circumstances. Such cases are rare, and the overhead needed to prevent them is fairly large, so the default is not to prevent them. To enable this functionality, the note_last_sent option must be set to true in bgpoptions. ** 2002.07.07: Dumping Updates and Routing Tables in Zebra-MRT Format New functionality has been added to allow updates and routing tables to be dumped to files in Zebra-MRT format. Zebra-MRT format is the format used by Zebra (www.zebra.org), which is very similar, though not exactly the same, as the MRT format (www.mrtd.net). Zebra-MRT format is binary, and can be converted to text using the MRT tool called route_btoa. The two options are dump_zmrt_updates and dump_zmrt_table, and can only be used in the BGP ProtocolSession.monitor attribute (not globally in bgpoptions). ** 2002.05.09: Options for Continuous and Randomized MRAI Timers Previously undocumented features related to the MRAI timer have been cleaned up for this release. The continuous_mrai_timers option forces MRAI timers to restart immediately each time they expire. The randomized_mrai_timers option randomizes the value of the MRAI timer the first time it is set (it can only be used when continuous_mrai_timers are being used). ** 2002.04.28: Split Horizon Option for Loop Detection Split horizon is a simple form of loop detection which prevents BGP from advertising messages directly back to the peer that sent them. This implementation of BGP has always used split horizon, but now it is a configurable option, called split_horizon. It's default value is true. -------- version 1.4.13 ---------------------------------------------- ** 2002.04.24: VerbosePlayer Thread-Safe Previously, VerbosePlayer used several global variables which could lead to garbled output when running in parallel. ** 2002.04.24: Distributed Execution Bug Fix Some support for serialization had been omitted from ASpath.java and KeepAlive.java. ** 2002.04.03: BGP Neighbor Misconfiguration Check Added a check to make sure that a BGP can't accidentally configure itself as a neighbor (otherwise it leads to an uninformative SSFNet error message). ** 2002.04.01: BGP/Sockets Bug Fixes Fixed potential infinite loop problem in connection establishment, as well as a bug where, in certain cases, listen() was not called again after a socket was established. -------- version 1.4.12 ---------------------------------------------- ** 2002.03.17: Change in DataPlayer for Older JDK Compatibility The StringBuffer.indexOf() method was being invoked in the DataPlayer class. This method is only available as of JDK 1.4. To be compatible with earlier versions, a minor adjustment was made to the code. -------- version 1.4.11 ---------------------------------------------- ** 2002.02.25: Modifications to Support Distributed Execution BGP no longer relies on references to objects which could be in different timelines, which would be problematic in a distributed simulation. [Note that as of 2002.02.25, no distributed SSFNet is available, though eventually perhaps it will be.] ** 2002.02.25: Cleaned Up Processing Delay Model Processing delay is experimental, and by default is turned off. See Java code comments in Global.java if interested. Modifications related to this were also made to the incoming buffer (see WeightedInBuffer.java), which now contains more levels of event priority. The MRAITimerExp event was added. These changes do not affect simulation functionality in which processing delay is turned off, which is the default behavior. ** 2002.02.21: Added New Events to Aid Connection Establishment New BGP events were added for dealing with socket connection re-establishment after simulated router crashes. The new events are ReadTransConnOpen, WriteTransConnOpen, and WriteTransConnOpenFail. Their use does not affect simulation functionality in which no BGP routers crash. (The router crashing is experimental. See BGPSession.die() and BGPSession.restart() methods if interested.) ** 2002.02.05: Added Manual AS Number Configuration Option AS numbers can now be configured manually using the AS_num configuration option in Net. ** 2002.02.04: Increased Socket Connection Limit -------- version 1.4.10 ---------------------------------------------- ** 2002.01.31: More goodgadget Bulletproofing Due to slight variations in the 'sort' program on different platforms, the goodgadget validation test would not always pass, even when its results were correct. Some additional measures have been taken to ensure that sort variation will not make a difference. -------- version 1.4.9 ----------------------------------------------- ** 2002.01.30: Updated goodgadget Validation Test Removed ordering dependencies in routing table printouts in this validation test by sorting the output. ** 2002.01.30: Removed Extraneous Static Route Code BGP was originally handling static routes in the Loc-RIB. This functionality was not being used, and was not a very sound way to go about it. They are now handled by the forwarding table only. -------- version 1.4.8 ----------------------------------------------- ** 2002.01.29: Fixed Socket Blocking Call Bug There was the possibility that close() could be called on a socket while it was currently blocking on a read() call. The code for reading and writing to sockets in general was cleaned up as well. ** 2002.01.29: Cleaned Up StartupTimer The callback for the StartupTimer (an inner class of BGPSession) now simply issues a RUN event rather than doing various startup tasks. The push() method, which handles all events, performs all of the startup tasks instead. ** 2002.01.24: Readvertise After Restart BGP was not re-advertising it's AS prefix after restarting. -------- version 1.4.7 ----------------------------------------------- ** 2002.01.23: Adjustments to Route Adding and Deleting Specified source of route adds/deletes as IBGP or EBGP instead of just plain BGP. ** 2002.01.21: Stopped Injecting Routes to Neighboring Routers Previously, BGP was adding static routes to the FIB for any interface at the end of a peer-to-peer link from the local router. This was redundant. -------- version 1.4.6 ----------------------------------------------- ** 2002.01.20: Updated Routing Protocol Information Exchange A routing protocol may need to know when the local forwarding table (FIB) is modified by another source. For example, if BGP routes are being exported to OSPF, then OSPF needs to know whenever BGP makes a change to the FIB. By implementing the FIBChangeListener interface for BGPSession, BGP can now listen for such changes, if necessary. It also no longer submits changes directly to OSPF, as it did previously by an OSPF method call. OSPF must now be a FIB listener itself if it wishes to know about changes that BGP makes to the FIB. -------- version 1.4.5 ----------------------------------------------- ** 2002.01.18: Hold Timer during Connection Establishment Fixed The Hold Timer was not being set properly when a transport connection open event occurred during either the Connect or Active state. The effects of this bug would only have been noticed if the transport connection failed before a BGP connection was established. ** 2002.01.18: Closing of Listening Sockets Implemented Now that the Sockets code for closing a listening socket has been completed, BGP can close such a socket if necessary. Currently, it only closes that socket when the die() method, which is experimental, is called. -------- version 1.4.4 ----------------------------------------------- ** 2002.01.09: Cleaner Integer-to-Byte Conversions in Monitoring There were some inefficiencies as well as a couple of subtle (though unlikely) bugs with the encoding of integers as bytes in the monitoring system. Those have been cleaned up, and the data players have been updated so that they now have access to the size of the byte-encoding used for integers. ** 2002.01.08: More Documentation for Policy Configuration Detailed policy configuration notes, particularly for the atomic predicate, have been added. -------- version 1.4.3 ----------------------------------------------- ** 2002.01.07: Bug Fix in Update Handling When a withdrawal is received, BGP checks to see if there was an advertisement waiting to be sent with the same NLRI as in the new withdrawal. If so, it then checks to see if the advertisement and withdrawal were both received from the same peer. If this is also true, the advertisement is then removed from the waiting list, having been "cancelled" by the withdrawal. There was a bug which incorrectly did the comparison to see if both advertisement and withdrawal had been received from the same peer. -------- version 1.4.2 ----------------------------------------------- ** 2002.01.02: Bug Fix in Advertiser Advertiser, which is an example widget, was skipping a token while reading from the workload file. -------- version 1.4.1 ----------------------------------------------- ** 2002.01.02: Bug Fix in DataPlayer DataPlayer, which is an example stream player, should have been ignoring messages before the UP phase began, but was not. -------- version 1.4.0 ----------------------------------------------- ** 2001.12.07: Added Die and Restart Support Implemented methods to kill and restart the BGP process, particularly for simulation router crashes. This functionality is not fully developed or tested and should be used with caution. ** 2001.11.19: Desensitized goodgadget by Removing Table Version Numbers The goodgadget validation test was still very sensitive to tiny changes in simulator behavior, including some behaviors which, although different, were still valid. The routing table version numbers are one such value which may be different given separate, but equally valid, simulation behaviors. Thus, the table version numbers were removed from the validation test output. Several other factors are still present for validation using this test. ** 2001.11.08: Fixed Concurrent Socket Access Problems There was a possible race condition where the same socket could be accessed concurrently for different actions (such is writes and closes), causing an error. This has been corrected. ** 2001.11.08: Added Auto-Reconnect Global Option The auto-reconnect option determines whether or not a BGP speaker should automatically attempt to reconnect when a peering session is lost. If true, as soon as a peering session is broken, BGP will re-enter the Connect state and begin an attempt to establish a new transport session. Refer to 'auto_reconnect'. ** 2001.10.29: Failure Mode Behavior Implemented Until now, failure modes had not been specifically tested for with SSFNet BGP. Specifically, peering sessions almost never went down. Now when a peering session goes down (for whatever reason), BGP will react properly, finding new best paths and sending withdrawals or updates to other peers, where appropriate. ** 2001.10.29: Timer Jitter Is Now Turned On by Default Previously, jittering of timers was not used unless specifically configured by the modeler, despite the fact that it is required by RFC 1771. ** 2001.10.02: Added Support for Continuous (Randomized) MRAI Timers Continuous randomized timers is an option which, if used, means that for each BGP speaker, the first time that an attempt is made to send a BGP update to a particular peer, that speaker will behave as if the MRAI timer for that peer was currently ticking so as to prevent updates (and possibly withdrawals, if withdrawal rate-limiting is in use) from being sent immediately. The actual MRAI timer for that peer will be set for a random time between 0 and the MRAI timer value. From that point on, every time the timer expires it will be immediately reset for the full MRAI value. This option is meaningful only when the MRAI timer is applied on a per-peer only basis. ** 2001.09.28: Added Randomized Last-Resort Tie-Breaking Option The final tie-breaker used when comparing two routes to determine preference, according to RFC 1771, is the lowest BGP ID of the advertising BGP routers. Now an option has been added to use random tie-breaking instead of using lowest BGP ID. The name of the option is 'random_tiebreaking'. ** 2001.09.27: Added Jitter to Manually Configured MRAI Timers Due to a programming bug, jitter was not being added to MRAI timers which were manually configured (ones which did not simply take the default value). This has been corrected. ** 2001.09.27: Renamed 'assert' Method in Class Debug to 'affirm' As of Java 1.4.0, 'assert' is a keyword. The Debug.assert and Debug.gassert methods have been renamed to 'affirm' and 'gaffirm' in response to the change. ** 2001.09.27: Added Per-Peer Only Rate Limiting Option Per-peer only rate limiting was not previously available, only per-peer, per-destination. These two options refer to the granularity at which update rate limiting is performed. RFC 1771 (and later drafts) indicate that no two advertisements which are for the same destination prefix, and which are also due to be sent to the same peer, may be sent within MRAI seconds of each other. (MRAI is the Minimum Route Advertisement Interval, which has a default value of 30 seconds.) Any implementation which guarantees that this will be true is consistent with the RFC. A per-peer, per-destination scheme would (most likely) mean having a timer for every different peer/destination combination, which is a potentially huge number of timers. A per-peer only scheme means keeping just one timer per peer, and never sending advertisements more frequently than MRAI seconds apart, with one exception: several advertisements may be sent at the same (approximate) time, namely when the MRAI timer expires, but they all must have different destinations. Per-peer only is what is typically implemented in commercial routers in order to conserve resources. Rate limiting by peer only is the new default. To use per-peer, per-destination rate-limiting, use the 'rate_limit_by_dest' option. ** 2001.09.23: Fixed Incorrect Case Number in External Update Debug Message Minor correction to correct an incorrectly printed case number in a rarely used debug option. -------- version 1.3.0 ----------------------------------------------- ** 2001.06.05: Organized Streaming and Printing Output Options When simulation options are enabled which generate output, that output maybe be directed to a record stream file and/or to standard output. The boolean options 'streaming' and 'printing' allow the modeler to determine where output is deposited. These attributes must be placed inside the 'bgpoptions' attribute. ** 2001.06.04: Fixed Socket Writing The Sockets package was updated, and this exposed a problem in BGP. Some socket writes were attempted concurrently on the same socket, which is not allowed. Per-peer queues for socket writing were added to fix the problem. ** 2001.05.25: Desensitized goodgadget The goodgadget validation test was extremely sensitive to tiny changes in simulator behavior, including some behaviors which, although different, were still valid. Certain criteria for the validation test were removed in order to make sure it would not crash for valid results. The sensitive version will continue to be used for development testing. ** 2001.05.11: AS Path Prepending Added During policy filtering, attribute manipulation may be applied to routes. A feature to allow additional AS numbers (or NHI addresses) to be prepended to the AS path of a route during attribute manipulation has been added. ** 2001.05.09: "Notice Update Arrival" Option Added It is possible for an update message to spend a long time waiting to be processed after arriving at a router. If the wait is long enough, it can cause a peering connection to time out, since update messages serve as KeepAlives. A new option to "notice" the arrival of update events has been added. This basically splits an update into an update and a KeepAlive when it arrives, and gives the KeepAlive high priority, thus reducing the chances of a session timeout. ** 2001.05.08: Low Update Priority Option Added An option to treat incoming BGP update messages with lower priority than all other BGP events and messages was added. This is so that other events, such as KeepAlive Timer expirations, can be processed with minimal delay when a router is receiving large numbers of update messages. ** 2001.03.23: Synchronized Objects Replaced All occurrences of the Java Utility library classes Vector and Hashtable, which are synchronized, were replaced with ArrayList and HashMap classes, respectively. ArrayList and HashMap behave almost identically to the other two, except that they are unsynchronized and thus are more time-efficient during program execution. A single BGP does not require synchronization for most of its data. ** 2001.03.09: CPU Delay Concurrency Problem Fixed CPU processing delay (introduced in version 1.2.8) was originally implemented in two separate phases--an 'incoming' phase when messages arrived, and an 'outgoing' phase when messages were processed and (possibly) generated new messages to be sent. There was one timer associated with each phase, and the sum of the two timer values for a particular BGP message being processed was to be the total CPU processing delay imposed for that message. However, the timers were allowed to count down simultaneously, so the total simulation time which passed was less than it should have been. This problem has been fixed by introducing a single timer which serves the purpose of the two original ones. ** 2001.02.27: Streams Fully Integrated for Monitoring A new class called Monitor now exists to perform a function similar to the old Options class. The Global class is now in charge only of globally applicable parameters, and does not handle event recording. Events of interest are handled by the debugmsg() method in Monitor, which encodes them and passed them on to a ProbeSession recorder to be recorded (in a file). A new class called VerbosePlayer can be used after a simulation is complete to decode the records in the file and print out the output of the simulation in verbose, human-readable format. ** 2001.02.12: MRAI Used for Naming 'MRAI' is now used to refer to the Minimum Route Advertisement Interval (and sometimes to the timer associated with it), rather than referring to it as 'MinAdver'. All occurrences have been replaced. Most notably, Timing/MinAdverTimer.java was replaced by Timing/MRAITimer.java. Global options were renamed as well. ** 2001.02.12: Global.java Replaces Options.java A name change to more accurately reflect the contents of the class, which contains several globally applicable parameters, not just model options. -------- version 1.2.8 ----------------------------------------------- ** 2001.01.09: Option for Sender-Side Loop Detection Sender-side loop detection is a process in which a BGP speaker, before sending an advertisement, checks the AS path to see if the AS of the neighbor to whom the advertisement is destined for appears in it. If so, the advertisement is suppressed, saving some work. An option to use sender-side loop detection (globally) is now available. ** 2001.01.06: Option for Applying Rate-Limiting to Withdrawals According to the RFC 1771, rate-limiting (using the MRAI timer) should not be applied to explicit withdrawals (see section 9.2.3.1). (It should be noted, however, that most commercial implementation DO apparently apply rate-limiting to withdrawals.) An option was added so that the rate-limiting could be applied to withdrawals if desired, but by default (as previously) it is not. ** 2001.01.05: Global eBGP and iBGP MRAI Value Option Options added so that global default values for the Minimum Route Advertisement Interval value can be specified by the modeler, and so that different default values can be used for external and internal peering sessions. For full details, see the Java documentation and the schema documentation (BGP4/doc/bgp-schema.dml). ** 2000.12.15: Delay Imposed for Message Processing Optional delays can now be imposed in order to model the amount of CPU time required to process certain BGP messages. This is experimental, and the use of this option is not recommended due to certain subtleties involved. -------- version 1.2.7 ----------------------------------------------- ** 2000.11.14: Validation Test Updated The goodgadget validation test, which is extremely sensitive to the slightest variations in the simulation kernel behavior, was showing slightly different (though all correct) output on different platforms. A small amount of jitter has been added to avoid simultaneous events which appear to be a possible source of the variation. -------- version 1.2.6 ----------------------------------------------- ** 2000.11.13: Validation Update for New Simulation Kernel Some changes in simultaneous event ordering broke the goodgadget test (though its behavior was still correct). The test has been slightly modified to reflect the new event ordering. ** 2000.11.09: Route Selection Tie-Breaking Fixed Tie-breaking for routes with the same degree of preference was not be done correctly. Previously, whichever route was learned first took preference. Now preference is decided according to the algorithm in RFC 1771, section 9.1.2.1. -------- version 1.2.5 ----------------------------------------------- ** 2000.11.03: Non-Simultaneous Peering Connection Tested Previously, most peering sessions were established simultaneously-- that is, each peer actively tried to connect to the other at the same time. (Often called a "collision".) This behavior established a peering session as expected. However, non-simultaneous connections were not common and not well-tested. Now they have been tested more rigorously, and some bugs have been worked out. ** 2000.11.03: Startup Memory Usage Reduced Instead of using a process to implement the startup wait times for each BGP instance, timers are now used. This greatly reduces the amount of memory required by each BGP session instance. ** 2000.10.24: Remove Withdrawn Routes from Waiting List When a withdrawal is received, the list of routes waiting to be advertised should be checked to make sure that the route which was just withdrawn is not waiting to be advertised. If so, it should be removed from the waiting list. This was not previously being done. ** 2000.10.24: Identical Advertised Routes Ignored If a route is learned from an advertisement and it is identical to an already known route, it should be ignored. This was not being done, and was causing some trouble in certain cases by replacing the previous identical copy of itself. ** 2000.10.20: Correct Octet (Byte) Value Used with Sockets The correct sizes of BGP messages, in octets (bytes), are now being used both for writing to and reading from Sockets. Previously, the correct values were being written but not read. -------- version 1.2.4 ----------------------------------------------- ** 2000.11.03: Documentation Update File BGP4/package.html was added so that javadoc-generated documentation will contain a description of the package. -------- version 1.2.3 ----------------------------------------------- ** 2000.10.10: Debugging Output Removed Some debugging statements which were accidentally left in the previous version were removed. -------- version 1.2.2 ----------------------------------------------- ** 2000.10.09: Startup Timing Options Added Two options have been added to allow the modeler more control over the timing of BGP speakers at the simulation startup. One option allows the base startup wait time to be specified by the modeler. The base startup wait time is the minimum period of time from the beginning of the simulation during which each BGP protocol session may not perform any functions (other than internal housekeeping and internal initialization). This wait period is typically used to allow other parts of the simulation, such as intra-domain forwarding tables, to get set up. A second option allows the modeler to add jitter to the startup wait times on a per-BGP protocol session basis. A range of possible jitter values, to be added to the base startup wait time, can be specified. Values from that range are chosen uniformly at random for each BGP protocol session. If the range specified is empty, no jitter is added to the base startup wait time. -------- version 1.2.1 ----------------------------------------------- ** 2000.09.27: Fixed Makefile Omission Some sections of the primary BGP Makefile did not include commands to compile the SSF.OS.BGP4.Path package. They have been added. -------- version 1.2.0 ----------------------------------------------- ** 2000.09.21: Loopback Addresses Used; IBGP Physical Connection Requirements Relaxed Virtual, or loopback, interfaces can now be used as the connection address for IBGP peering. This means that the previous requirement that all IBGP neighbors be physically connected by a point-to-point link no longer exists. ** 2000.09.15: BGP Speaker Configuration Requirements Changed The modeler now has two basic options for configuring an individual BGP protocol session. Autoconfiguration can be used, in which case the modeler forfeits the right to configure any specifics of the BGP speaker. Alternatively, manual configuration can be used, in which case the modeler is required to explicitly configure almost every aspect of the speaker. ** 2000.08.18: BGP-4 Package Restructured The entire BGP-4 package has been Reorganized to conform more closely with the terminology and organization suggested in RFC 1771 and actual implementations. Classes have been renamed and grouped in sub-packages, and "BGP" has been stripped from the beginning of most class names. NeighborData was renamed to PeerEntry, and RouteTree was renamed to the base class RIBElement, with AdjRIBIn, LocRIB and AdjRIBOut extending it. RoutingTable was removed completely. ** 2000.08.02: Corrected Withdrawal Behavior Previously, withdrawals were not sent when a better route to a destination was selected to replace a worse one. ** 2000.07.27: Added Policy Configuration Policy rules for filtering inbound and outbound routes can now be configured, on a per-peer basis, in DML. It includes capabilities for performing path attribute manipulation as well. ** 2000.07.20: Hold Timer Negotiation Previously, Hold Timer values could be set at each end of a BGP peering session, but those two values could differ. Now, however, the Hold Timer value is negotiated at the establishment of the session, as is prescribed in RFC 1771. (Each BGP instance proposes a value for the timer and the minimum of the two is used by both.) -------- version 1.1.0 ----------------------------------------------- ** 2000.07.14: Route Reflection Support Added Route reflection is an extension (not mentioned in BGP RFC) to Internal BGP. It relaxes the requirement that there be a fully- connected mesh between all Internal BGP peers. See the README file for pointers on configuring BGP to use route reflection. ** 2000.07.07: Internal BGP Support Added Finally, multiple BGP routers can co-exist in the same autonomous system. Without route reflection, it is required that a fully- connected mesh of direct (point-to-point) links connects all such BGP routers in the same AS. ** 2000.07.07: Bug in Next Hop Comparison Removed A bug that incorrectly compared the NEXT_HOP attributes has been corrected. The problem was in the BGPRoute.equal_next_hop() method, and does not appear to have affected any previous models. ** 2000.07.06: Updated Debugging Message Output Format The debugging message output format was cleaned up enormously. It is now more accurate, more concise, and more consistent. -------- version 1.0.12 ---------------------------------------------- ** 2000.07.05: Updated forwarding1 Example Minor updates to the documentation for the forwarding1 example were made, and the pre-generated output files for that example are no longer included with the distribution since they are fairly large. -------- version 1.0.11 ---------------------------------------------- ** 2000.04.27: Fixed Bug in Outgoing Route Trees (Adj-RIBs-Out) Instead of inserting routes into the trees based on their destination IP prefixes, they were being inserted based on the BGP ID's of the peers from whom the advertised routes were received. This almost certainly did not have any effect in previous versions of BGP, as the outgoing routes are flushed quickly, and where they were inserted in the tree made little difference. It surfaced here because by using the BGP finite state machine and TCP to start up connections, it was the first time that all BGP speakers did not start up perfectly synchronized, and some routes built up in the outgoing route trees. As BGP becomes more dynamic, outgoing route trees will be used more frequently. ** 2000.02.03: Neighbor Connection Process Used Previously, (potential) peers would be detected at initialization and all connections would be assumed to exist at the start of the simulation. (In terms of the BGP finite state machine, all connections were set to the Established state at start-up.) Potential peers are still detected during initialization, but connections are now established by the process specified in the BGP RFC. (TCP connections are first established, then Open and KeepAlive messages are exchanged.) ** 2000.02.03: Old Configuration Attribute Removed The 'bgp' configuration construct is no longer available as it was redundant. All configurable BGP options that were allowed in that construct can be placed inside the 'ProtocolSession' construct instead. -------- version 1.0.10 ---------------------------------------------- ** 2000.01.28: TCP Used for Neighbor Connections Now instead of using IP directly to communicate with peers, a BGP speaker first sets up a connection using TCP with Sockets. The implementation is slightly fragile in that it assumes that all connections will be made in the first second of the simulation. At time 1.0, a BGP speaker begins advertising its AS prefix to its neighbors. No point-to-point connections should ever have a delay big enough to cause a problem with this assumption, however. ** 2000.01.22: Helper Classes Removed The BGPSessionHelper class was incorporated into the BGPSession class. Other helper classes used in examples and tests were similarly removed. -------- version 1.0.9 ----------------------------------------------- ** 2000.01.21: Route Aggregation Added During Phase 3 of the Decision Process, overlapping routes in Loc-RIB are aggregated before Adj-RIBs-Out are updated (and thus before updates are sent to peers). Aggregation (and route management in general) is extremely complex in BGP, and I'm sure there will be changes and corrections to this implementation in time. A new test, called forwarding2, was also added to test that forwarding tables still function properly when aggregation is used in a hierarchically addressed network. ** 2000.01.21: Bug in Phase 1 of Decision Process Removed A bug which prematurely terminated route selection in certain cases was fixed. ** 2000.01.21: Initial Advertisement Propagation Modified The way that BGP routers advertise their own ASes at startup was changed so that instead of composing messages and sending them manually, the AS prefix is added to the Loc-RIB route table and Phase 3 of the Decision Process is invoked. This has the same effect of advertising the AS to each neighbor. (Note that although the AS prefix is now in Loc-RIB, it does *not* get added to the local router's forwarding table.) ** 2000.01.21: AS Prefix Calculation Bug Removed A bug which miscalculated AS prefixes in certain cases was fixed. ** 2000.01.21: AS_status Attribute Usage Broadened Previously, if two Net attributes were nested, they could not both contain the 'AS_status' attribute (with value 'boundary'). This is no longer the case. If such nested Nets exist in a DML file, it does not mean that there are two overlapping ASes--the outer AS encompasses everything in its Net except for the inner AS. There is no limit to the number of levels of nesting. -------- version 1.0.8 ----------------------------------------------- ** 1999.12.13: Turning Debugging Off Added a note about turning debugging off in order to get performance improvements. -------- version 1.0.7 ----------------------------------------------- ** 1999.12.13: Test and Example Output Updated Output files in tests and examples is updated to reflect cosmetic changes due to newer versions of SSFNet components. -------- version 1.0.6 ----------------------------------------------- ** 1999.12.12: Minimum Route Advertisement Interval Timer Bug Fixed A bug which caused an array index value to be set incorrectly was fixed. (A couple of other tiny cosmetic tweaks were also made here and there.) -------- version 1.0.5 ----------------------------------------------- ** 1999.09.29: Makefiles Made Portable All Makefiles have been made generic for portability. They now use 'sh' as the shell and don't use any obscure features. They also now include Makefile.common which sets the top-level SSFNet directory as well as the Java class path. ** 1999.09.22: Timer Intervals Jittered The KeepAlive interval, MinASOriginationInterval, and MinRouteAdvertisementInterval are now jittered as specified in section 9.2.3.3 of RFC 1771. Validation test keep-peer modified to behave appropriately in light of the new jitter behavior. (For release 1.0.5, jitter is turned off. In subsequent releases, it may or may not be on by default.) -------- version 1.0.4 ----------------------------------------------- ** 1999.09.16: BGP OSPF Interaction Each time a route is added to the local router's forwarding table, it is also passed to OSPF. -------- version 1.0.3 ----------------------------------------------- ** 1999.09.07: Validation Process Improved All validation tests are now much simpler to run. Makefiles have been added for each and the output is concise, simple, and is independent of the order in which simultaneous events are handled by the simulator. The main Makefile (in the BGP4 directory) can be used to run a full validation on the implementation. ** 1999.08.30: Withdrawals Handled BGP speakers now properly handle UPDATE messages containing withdrawals. A withdrawals validation test was also added to check the behavior. -------- version 1.0.2 ----------------------------------------------- ** 1999.08.26: Drop Connection on Notification A BGP speaker should immediately drop its connection with a peer if it receives a Notification message from that peer. Previously, this was not the case in this implementation. Now it is. -------- version 1.0.1 ----------------------------------------------- ** 1999.08.26: Updated for JSSF 0.5.0 Many minor changes to comply with updates in JSSF 0.5.0 and SSFNet 0.7.8. ====================================================================== ========= 1999.08.25: VERSION 1.0 includes everything below ========== ====================================================================== ** 1999.08.09: Dump and Resume Functionality Complete The run-time option 'resume' is now available to the modeler to resume a simulation that was saved in a previous run using 'dump'. Some updates to the usage for 'dump' have also been made. A simulation can be dumped to files with suffix F at time N with the following 'bgpoptions' attribute in DML input: Net [ # top-level Net bgpoptions [ dump [ at N filesuffix F ] ] # ... everything else ] The 'filesuffix' attribute indicates that for each BGP speaking router in the simulation, a file called bgp_dump_-F.dml will be created containing all relevant state information in DML form, where is the BGP ID of the speaker (an IP address). If 'filesuffix' is not specified, files will be of the form bgp_dump_.dml. The suffix can be useful if multiple dumps are saved at once. To resume a simulation dumped as in the example above, one would use the following 'bgpoptions' attribute: bgpoptions [ resume [ at N filesuffix F ] ] Take note that although BGP can fully restore its state, other parts of the simulation whose state changes may not yet have that capability. Thus, a dumped and resumed simulation may not give the same results as when run straight through from start to finish, even though BGP is has restored correctly. Care should also be taken to resume simulations from the same point in time when they were dumped. A warning message will be issued if the times differ, and the results of such a resumed simulation may not be well-defined. ---------------------------------------------------------------------- ** 1999.08.01: Internal Gobbledygook Cleaned Up Lots of internal improvements made. BitString class added as a more intuitive alternative to representing bits as booleans; RadixTree reimplemented to use BitString; BGPDebug, BGPNeighborData and BGPOptions classes added to modularize code and aid development. ---------------------------------------------------------------------- ** 1999.07.23: Run-Time Option Functionality Added In order to allow the user to specify options to BGP (other than the basic configuration options), functionality was added which looks for a DML attribute called 'bgpoptions' inside the top-level 'Net' attribute. Only one option useful to modelers is recognized at this time (there are many which are useful for debugging and validation but not for common usage). This option is called 'dumpat', and allows the user to specify a simulation time (in seconds) at which to dump the state of each BGP speaker. As an example, a DML file dumped BGP state 10 seconds into the simulation would look something like this: Net [ bgpoptions [ dumpat 10.0 ] # ... everything else ] A schema for BGP options will be presented soon to specify available BGP options and their usage. ---------------------------------------------------------------------- ** 1999.07.19: Neighbor Discovery Simplified Instead of sending out messages on all links, all neighboring hosts and routers on point-to-point links are queried to see if BGP is being implemented there. If so, they are assumed to be BGP peers. Otherwise, no communication is initiated with them. This eliminates needless attempted communication with non-neighbors and the associated error messages that arise from such attempts. ---------------------------------------------------------------------- ** 1999.06.22: Autonomous System Support Reorganized Since autonomous systems are a network property which is used only by certain routing protocols (namely BGP), support for the 'type AS' attribute of Net has been removed, and a new, user-defined attribute (UDA) 'AS_status' has been added, which will be ignored during Net configuration but can be recognized by any protocols that wish to look for it. The only currently valid value for 'AS_status' is 'boundary', indicating that a particular Net marks the outer boundary of an autonomous system. DML files need only replace 'type AS' with 'AS_status boundary' to conform with this modification. ---------------------------------------------------------------------- ** 1999.06.10: Configuration Inconveniences Removed No longer does 'as' or 'asprefix' need to be specified in order for BGP to be correctly configured. BGP can now get both of these attributes from the environment. Additionally, BGP checks for attributes configured in the 'bgp [ ]' attribute of its router. (This is in addition to attributes which are configured in the 'ProtocolSession [ ]' block in the router; configuration using the 'bgp' block is preferred.) ---------------------------------------------------------------------- ** 1999.05.24: Configuration Simplified DML configuration for BGP has been greatly simplified. All parameters whose values could be determined during simulation set-up or during the early stages of simulation have been removed from the configuration specification. Also, several configurable timer values have been added as parameters. Here is how the new schema looks: bgp [ version %S connect_retry_interval %F<1 # some timer interval values, min_as_orig_interval %F<1 # measured in seconds hold_timer_interval %F<1 # keep_alive_interval %F<1 # min_route_ad_interval %F<1 # ip_ttl %I<1 # IP's time-to-live parameter ] Notable changes: 1. 'id' removed this was removed since it can always be calculated during the simulation; the reason it had been included previously was because the information necessary for calculating the id was not available to a BGP during configuration (it still isn't, but is no big deal to get it at time 0) 2. 'asprefix' removed this was going to be removed eventually anyway; BGP will have to get it from the local OSPF router, which calculates it, or perhaps it can be gotten more simply under the new CIDR IP address assignment scheme 3. 'rtrid' removed rtrid's purpose was to specify which router a specific BGP configuration was for; with the new DML, however, the DML file entry for a router that will be running BGP will probably contain a bgp [ ... ] entry, making rtrid unnecessary 4. 'as' removed the AS number should be retrievable by other means currently under debate 5. 'numneighbors' and 'neighbor [ ... ]' removed neighbors (and all of their attributes) can be retrieved at time 0 of a simulation 6. several constant value attributes added the following time intervals are ones which a BGP administrator should be able to configure: Connect Retry, Minimum AS Origination, Hold Timer, Keep Alive, Minimum Route Advertisement. 'ip_ttl' also added to allow the minIpHeader TTL value to be set (BGP uses minIP for now) Although 'asprefix' is not in the schema, BGP will still understand that parameter if used. This is because the BGP interaction with OSPF has not yet been nailed down; BGP will eventually ask OSPF for the AS prefix value it requires. For now, asprefix needs to be specified. Similarly, 'as' is not in the schema, but will be understood and needs to be specified until the AS number can be retrieved from the local router. ---------------------------------------------------------------------- ** 1999.04.12: Forwarding Table Integration The standardized forwarding table which is used by a Router does not alone contain enough information for BGP to perform its duties. BGP keeps its own internal tables, or Routing Information Bases (RIBs). One RIB is essentially the same as the standard forwarding table, but contains additional information about each route in the table. In the first implementation of BGP, that table was actually used for lookups by the router when forwarding packets. Now, however, it is internal to BGP and invisible to the rest of the world. Whenever BGP adds or removes routes from this table, however, the corresponding route is added or removed from the standard forwarding table at that Router. (A warning to those who look at the BGP RIB code: many of the comments are outdated and still refer to the internal forwarding table as the main forwarding table. This could be very confusing if you are trying to understand the how the code works!) ---------------------------------------------------------------------- ** 1999.04.09: Configuration More Robust [obsoleted by modifications on 1999.05.24] Configuration can now be done from within a cf*.dml file, a bgp*.dml file, or from a combination of both. Having only partial configurations (ie, values are not specified for all attributes) in either file is undesirable, but should not cause a problem. With a couple of exceptions, any attribute left completely unspecified in configuration can be determined at the beginning of the simulation (by querying neighbors, etc.). In configuring with a cf*.dml file, the only attribute which MUST be specified is asprefix. (BGP would normally get this value from OSPF, though it is currently unimplemented. Expect this to be implemented soon.) In configuring with a bgp*.dml file, the only two required attributes are asprefix and rtrid. rtrid is required in order to identify to which BGP-speaking router in the simulation each set of attributes should be applied. There are a couple of other rules that must be followed during configuration as well. Any time that numneighbors is specified, the correct number of embedded neighbor configurations must appear as well. Within any neighbor configuration, num MUST appear, and at least one of ip, interface, or localip must appear. The fact that configuration can be done in three different ways (via a cf*.dml file, a bgp*.dml file, or by querying the environment when the simulation starts), combined with the multiple different attributes that need to be configured, means that there are actually multiple ways to go about configuring a simulation for using any one particular set of attribute values. (For example, you can specify some attribute values in cf*.dml, some in bgp*.dml, and leave some to be determined by the simulation, or you could put them all in bgp*.dml, or all in cf*.dml, or ....) Because of this, the code for doing configuration quickly gets complex. While not all possible different ways of doing configuration have been tested, a large number of them have, especially the most common, straightforward methods (such as specifying all attribute values in just one place).