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