ChangeLog.opaque.txt 9.5 KB

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