| ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- |
| 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. |