ChangeLog.opaque.txt 8.4 KB

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