Return to ChangeLog.opaque.txt CVS log

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

quagga

    1: ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
    2: Changes 2001.12.03
    3: 
    4: 1. 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: 
   23: 2. 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: ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
   39: Changes 2001.10.31
   40: 
   41: 1. 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: 
   90: 2. 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: ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
   99: Changes 2001.08.03
  100: 
  101: 1. 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: 
  149: 2. 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: ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * ----- * -----
  177: Changes 2001.03.28
  178: 
  179:   Initial release of Opaque-LSA/MPLS-TE extensions for the zebra/ospfd.