Return to ChangeLog.opaque.txt CVS log | Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / quagga / doc / mpls |
1.1 ! misho 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.