1----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- 2Changes 2001.12.03 3 41. Bug fixes 5 6 1.1 Though a new member "oi" has added to "struct ospf_lsa" to control 7 flooding scope of type-9 Opaque-LSAs, the value was always NULL 8 because no one set it. 9 10 1.2 In the function "show_ip_ospf_database_summary()" and "show_lsa_ 11 detail_adv_router()", VTY output for type-11 Opaque-LSAs did not 12 work properly. 13 14 1.3 URL for the opaque-type assignment reference has changed. 15 16 1.4 In the file "ospf_mpls_te.c", printf formats have changed to 17 avoid compiler warning messages; "%lu" -> "%u", "%lx" -> "%x". 18 Note that this hack depends on OS, compiler and their versions. 19 20 1.5 One of attached documentation "opaque_lsa.txt" has changed to 21 reflect the latest coding. 22 232. Feature enhancements 24 25 2.1 Knowing that it is an ugly hack, an "officially unallocated" 26 opaque-type value 0 has newly introduced as a "wildcard", 27 which matches to all opaque-type. 28 This value must not be flooded to the network, of course. 29 30 2.2 The Opaque-core module makes use of newly introduced hooks to 31 dispatch every LSDB change (LSA installation and deletion) to 32 preregistered opaque users. 33 Therefore, by providing appropriate callback functions as new 34 parameters of "ospf_register_opaque_functab()", an opaque user 35 can refer to every LSA instance to be installed into, or to be 36 deleted from, the LSDB. 37 38----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- 39Changes 2001.10.31 40 411. Bug fixes 42 43 1.1 Since each LSA has their own lifetime, they will remain in a 44 routing domain (being stored in LSDB of each router), until their 45 age naturally reach to MaxAge or explicitly being flushed by the 46 originated router. Therefore, if a router restarted with a short 47 downtime, it is possible that previously flooded self-originated 48 LSAs might received if the NSM status is not less than Exchange. 49 50 There were some problems in the way of handling self-originated 51 Opaque-LSAs if they are contained in a received LSUpd message, 52 but not installed to the local LSDB yet. 53 Regardless of some conditions to start originating Opaque-LSAs 54 (there should be at least one opaque-capable full-state neighbor), 55 the function "ospf_flood()" will be called to flood and install 56 this brand-new looking LSA. 57 As the result, when the NSM of an opaque-capable neighbor gets 58 full, internal state inconsistency happens; a user of Opaque-LSA 59 such as MPLS-TE can refer to self-originated LSAs in the local 60 LSDB, but cannot modify their contents... 61 62 Above problems have fixed with a policy "flush it from the whole 63 routing domain and keep silent until the flushing completed". 64 By using this sweeping technique, we can be free from confusion 65 caused by self-originated LSAs received via network. 66 67 1.2 The function "ospf_opaque_type_name()" contained massive ifdefs 68 corresponding to each "opaque-type". 69 These unnecessary ifdefs are removed completely. 70 71 1.3 In the function "ospf_delete_opaque_functab()", there was an 72 improper loop control that causes illegal memory access. 73 Original coding was "next = nextnode (node)". 74 75 1.4 The function "ospf_mpls_te_ism_change()" could not handle the 76 case when the ISM changes from Waiting to DR/BDR/Other. 77 So, there was a case that even if one of an ISM become 78 operational and MPLS-TE module has started, the corresponding 79 Opaque-LSA cannot be originated. 80 81 1.5 The function "ospf_opaque_lsa_reoriginate_schedule()" did not 82 allow to be called multiple times, simply because handling 83 module for the given "lsa-type & opaque-type" already exists. 84 But this assumption seems to be wrong. 85 Change the policy to allow this function to be called multiple 86 times and let the caller to decide what should do when the 87 corresponding callback function "(* functab->lsa_originator)()" 88 is called. 89 902. Feature enhancements 91 92 2.1 The global bitmap "opaque" has introduced instead of former flag 93 "OpaqueCapable", to store complex conditions to handle Opaque-LSAs. 94 95 2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic 96 -06.txt", no significant changes with 05 version, though. 97 98----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- 99Changes 2001.08.03 100 1011. Bug fixes 102 103 1.1 Even if the ospfd started with opaque capability enabled, when 104 the ospfd receives an unknown opaque-type (unregistered by the 105 function "ospf_register_opaque_functab()" beforehand), the LSA 106 was discarded. As the result, only the opaque-LSAs that have 107 commonly registered by opaque-capable ospf routers can be 108 flooded in a routing domain. 109 110 This behavior has fixed so that arbitrary opaque-type LSAs can 111 be flooded among opaque-capable ospf routers. 112 If the ospfd has opaque-LSA capability but disabled at runtime, 113 received opaque-LSAs can be accepted and registered to LSDB as 114 is, but not be flooded to the network; those opaque LSAs will 115 remain in LSDB until explicitly flushed by incoming LSUpd 116 messages with MaxAge, or their age naturally reaches to MaxAge. 117 118 1.2 The function "ospf_register_opaque_functab()" did not check 119 if the entry corresponding to the given "lsa-type, opaque-type" 120 combination already exists or not. 121 This problem has fixed not to allow multiple registration. 122 123 1.3 Since type-11 (AS external) LSAs will be flooded beyond areas, 124 there is little relationship between "struct lsa" and "struct 125 area". More specifically, the pointer address "lsa->area" can 126 be NULL if the lsa-type is 11, thus an illegal memory access 127 will happen. This problem has fixed. 128 129 1.4 When self-originated opaque-LSAs are received via network and 130 if the corresponding opaque-type functions are not available 131 (they have already deleted) at that time, those LSAs were 132 dropped due to "unknown opaque-type" error. 133 After the problem 1.1 has fixed, those "self-originated" LSAs 134 were registered to LSDB and then flooded to the network, even 135 if the processing functions did not exist... 136 137 After all, this problem has fixed so that those LSAs should 138 explicitly be flushed from the routing domain immediately, if 139 the processing functions cannot find at that time. 140 141 1.5 Some typo have fixed. 142 143 --- EXAMPLE --- 144 static int 145 opaque_lsa_originate_callback (list funclist, void *lsa_type_dependent) 146 ^^^^^ 147 --- EXAMPLE --- 148 1492. Feature enhancements 150 151 2.1 According to the description of rfc2328 in section 10.8, any 152 change in the router's optional capabilities should trigger 153 the option re-negotiation procedures with neighbors. 154 155 --- EXCERPT --- 156 If for some reason the router's optional 157 capabilities change, the Database Exchange procedure should be 158 restarted by reverting to neighbor state ExStart. 159 --- EXCERPT --- 160 161 For the opaque-capability changes, this feature has implemented. 162 More specifically, if "ospf opaque-lsa" or "no ospf opaque-lsa" 163 VTY command is given at runtime, all self-originated LSAs will 164 be flushed immediately and then all neighbor status will be 165 forced to ExStart by generating SeqNumberMismatch events. 166 167 2.1 When we change opaque-capability dynamically (ON -> OFF -> ON), 168 there was no trigger at "OFF->ON" timing to reactivate opaque 169 LSA handling modules (such as MPLS-TE) that have once forcibly 170 stopped at "ON->OFF" timing. 171 Now this dynamic reactivation feature has added. 172 173 2.2 The MPLS-TE module now referes to "draft-katz-yeung-ospf-traffic 174 -05.txt", no significant changes with 04 version, though. 175 176----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- 177Changes 2001.03.28 178 179 Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd. 180