Return to ChangeLog.opaque.txt CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / ospfd

quagga

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