doc/mpls/ChangeLog.opaque.txt

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