----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2002.12.20 1. Bug fixes 1.1 When an opaque LSA is being removed from (or added to) the LSDB, it does not mean a change in network topology. Therefore, SPF recalculation should not be triggered in that case. There was an assertion failure problem "assert (rn && rn->info)" inside the function "ospf_ase_incremental_update()", because the upper function "ospf_lsa_maxage_walker_remover()" called it when a type-11 opaque LSA is removed due to MaxAge. 1.2 Type-9 LSA is defined to have "link-local" flooding scope. In the Database exchange procedure with a new neighbor, a type-9 LSA was added in the database summary of a DD message, even if the link is different from the one that have bound to. 2. Feature enhancements 2.1 Though a "wildcard" concept to handle type-9/10/11 LSAs altogether has introduced about a year ago, it was only a symbol definition and actual handling mechanism was not implemented. Now it works. ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2002.7.8 1. Bug fixes 1.1 When "ospf_delete_opaque_functab()" is called, internal structure "oipt" remain unfreed. If register/delete functab is repeated, illegal memory access happens due to this "oipt". 1.2 In "free_opaque_info_per_id()", there was a crucial typo which ignores a condition test. "if (oipi->lsa != NULL);" <-- semicolon! 2. Feature enhancements None. ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2001.12.03 1. Bug fixes 1.1 Though a new member "oi" has added to "struct ospf_lsa" to control flooding scope of type-9 Opaque-LSAs, the value was always NULL because no one set it. 1.2 In the function "show_ip_ospf_database_summary()" and "show_lsa_ detail_adv_router()", VTY output for type-11 Opaque-LSAs did not work properly. 1.3 URL for the opaque-type assignment reference has changed. 1.4 In the file "ospf_mpls_te.c", printf formats have changed to avoid compiler warning messages; "%lu" -> "%u", "%lx" -> "%x". Note that this hack depends on OS, compiler and their versions. 1.5 One of attached documentation "opaque_lsa.txt" has changed to reflect the latest coding. 2. Feature enhancements 2.1 Knowing that it is an ugly hack, an "officially unallocated" opaque-type value 0 has newly introduced as a "wildcard", which matches to all opaque-type. This value must not be flooded to the network, of course. 2.2 The Opaque-core module makes use of newly introduced hooks to dispatch every LSDB change (LSA installation and deletion) to preregistered opaque users. Therefore, by providing appropriate callback functions as new parameters of "ospf_register_opaque_functab()", an opaque user can refer to every LSA instance to be installed into, or to be deleted from, the LSDB. ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2001.10.31 1. Bug fixes 1.1 Since each LSA has their own lifetime, they will remain in a routing domain (being stored in LSDB of each router), until their age naturally reach to MaxAge or explicitly being flushed by the originated router. Therefore, if a router restarted with a short downtime, it is possible that previously flooded self-originated LSAs might received if the NSM status is not less than Exchange. There were some problems in the way of handling self-originated Opaque-LSAs if they are contained in a received LSUpd message, but not installed to the local LSDB yet. Regardless of some conditions to start originating Opaque-LSAs (there should be at least one opaque-capable full-state neighbor), the function "ospf_flood()" will be called to flood and install this brand-new looking LSA. As the result, when the NSM of an opaque-capable neighbor gets full, internal state inconsistency happens; a user of Opaque-LSA such as MPLS-TE can refer to self-originated LSAs in the local LSDB, but cannot modify their contents... Above problems have fixed with a policy "flush it from the whole routing domain and keep silent until the flushing completed". By using this sweeping technique, we can be free from confusion caused by self-originated LSAs received via network. 1.2 The function "ospf_opaque_type_name()" contained massive ifdefs corresponding to each "opaque-type". These unnecessary ifdefs are removed completely. 1.3 In the function "ospf_delete_opaque_functab()", there was an improper loop control that causes illegal memory access. Original coding was "next = nextnode (node)". 1.4 The function "ospf_mpls_te_ism_change()" could not handle the case when the ISM changes from Waiting to DR/BDR/Other. So, there was a case that even if one of an ISM become operational and MPLS-TE module has started, the corresponding Opaque-LSA cannot be originated. 1.5 The function "ospf_opaque_lsa_reoriginate_schedule()" did not allow to be called multiple times, simply because handling module for the given "lsa-type & opaque-type" already exists. But this assumption seems to be wrong. Change the policy to allow this function to be called multiple times and let the caller to decide what should do when the corresponding callback function "(* functab->lsa_originator)()" is called. 2. Feature enhancements 2.1 The global bitmap "opaque" has introduced instead of former flag "OpaqueCapable", to store complex conditions to handle Opaque-LSAs. 2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic -06.txt", no significant changes with 05 version, though. ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2001.08.03 1. Bug fixes 1.1 Even if the ospfd started with opaque capability enabled, when the ospfd receives an unknown opaque-type (unregistered by the function "ospf_register_opaque_functab()" beforehand), the LSA was discarded. As the result, only the opaque-LSAs that have commonly registered by opaque-capable ospf routers can be flooded in a routing domain. This behavior has fixed so that arbitrary opaque-type LSAs can be flooded among opaque-capable ospf routers. If the ospfd has opaque-LSA capability but disabled at runtime, received opaque-LSAs can be accepted and registered to LSDB as is, but not be flooded to the network; those opaque LSAs will remain in LSDB until explicitly flushed by incoming LSUpd messages with MaxAge, or their age naturally reaches to MaxAge. 1.2 The function "ospf_register_opaque_functab()" did not check if the entry corresponding to the given "lsa-type, opaque-type" combination already exists or not. This problem has fixed not to allow multiple registration. 1.3 Since type-11 (AS external) LSAs will be flooded beyond areas, there is little relationship between "struct lsa" and "struct area". More specifically, the pointer address "lsa->area" can be NULL if the lsa-type is 11, thus an illegal memory access will happen. This problem has fixed. 1.4 When self-originated opaque-LSAs are received via network and if the corresponding opaque-type functions are not available (they have already deleted) at that time, those LSAs were dropped due to "unknown opaque-type" error. After the problem 1.1 has fixed, those "self-originated" LSAs were registered to LSDB and then flooded to the network, even if the processing functions did not exist... After all, this problem has fixed so that those LSAs should explicitly be flushed from the routing domain immediately, if the processing functions cannot find at that time. 1.5 Some typo have fixed. --- EXAMPLE --- static int opaque_lsa_originate_callback (list funclist, void *lsa_type_dependent) ^^^^^ --- EXAMPLE --- 2. Feature enhancements 2.1 According to the description of rfc2328 in section 10.8, any change in the router's optional capabilities should trigger the option re-negotiation procedures with neighbors. --- EXCERPT --- If for some reason the router's optional capabilities change, the Database Exchange procedure should be restarted by reverting to neighbor state ExStart. --- EXCERPT --- For the opaque-capability changes, this feature has implemented. More specifically, if "ospf opaque-lsa" or "no ospf opaque-lsa" VTY command is given at runtime, all self-originated LSAs will be flushed immediately and then all neighbor status will be forced to ExStart by generating SeqNumberMismatch events. 2.1 When we change opaque-capability dynamically (ON -> OFF -> ON), there was no trigger at "OFF->ON" timing to reactivate opaque LSA handling modules (such as MPLS-TE) that have once forcibly stopped at "ON->OFF" timing. Now this dynamic reactivation feature has added. 2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic -05.txt", no significant changes with 04 version, though. ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- Changes 2001.03.28 Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.