idnits 2.17.1 draft-ogier-ospf-dbex-opt-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 235. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 217. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 223. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 16, 2007) is 5969 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group R. Ogier 3 Internet-Draft December 16, 2007 4 Category: Informational 5 Expires: June 16, 2008 7 OSPF Database Exchange Summary List Optimization 8 draft-ogier-ospf-dbex-opt-03.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on June 16, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 This document describes a backward compatible optimization for the 41 Database Exchange process in OSPFv2 and OSPFv3. In this 42 optimization, a router does not list an LSA in Database Description 43 packets sent to a neighbor, if the same or a more recent instance of 44 the LSA was listed in a Database Description packet already received 45 from the neighbor. This optimization reduces Database Description 46 overhead by about 50% in large networks. This optimization does not 47 affect synchronization, since it only omits unnecessary information 48 from Database Description packets. 50 1. Introduction 52 In OSPFv2 [RFC2328] and OSPFv3 [RFC2740], when two neighboring 53 routers become adjacent, they synchronize their link-state databases 54 via the Database Exchange process. Each router sends the other 55 router a set of Database Description (DD) packets that describes the 56 router's link-state database. This is done by listing each LSA 57 (i.e., including the header of each LSA) in one of the sent DD 58 packets. This procedure allows each router to determine whether the 59 other router has newer LSA instances that should be requested via 60 Link State Request packets. 62 The optimization simply observes that it is not necessary for a 63 router (master or slave) to list an LSA in a DD packet if it knows 64 the neighbor already has an instance of the LSA that is the same or 65 more recent (and therefore will not request the LSA). To avoid 66 listing such LSAs in DD packets, when an LSA is listed in a DD packet 67 received from the neighbor, and the Database summary list for the 68 neighbor has an instance of the LSA that is the same as or less 69 recent than the one received, the LSA is removed from the summary 70 list. 72 The optimization, called the Database Exchange summary list 73 optimization, does not affect synchronization, since the LSAs that 74 are omitted from DD packets are unnecessary. The optimization is 75 fully backward compatible with OSPF. The optimization reduces 76 Database Description overhead by about 50% in large networks in which 77 routers are usually already nearly synchronized when they become 78 adjacent, since it reduces the total number of LSA headers exchanged 79 by about one-half in such networks. The optimization is especially 80 beneficial in large networks with limited bandwidth, such as large 81 mobile ad hoc networks. 83 2. Specification of Optimization 85 The Database Exchange summary list optimization is defined by 86 modifying Section 10.6 (Receiving Database Description Packets) of 87 RFC 2328 as follows. The second-to-last paragraph of Section 10.6 is 88 replaced with the following augmented paragraph: 90 When the router accepts a received Database Description Packet as the 91 next in sequence, the packet contents are processed as follows. For 92 each LSA listed, the LSA's LS type is checked for validity. If the 93 LS type is unknown (e.g., not one of the LS types 1-5 defined by this 94 specification), or if this is an AS- external-LSA (LS type = 5) and 95 the neighbor is associated with a stub area, generate the neighbor 96 event SeqNumberMismatch and stop processing the packet. Otherwise, 97 the router looks up the LSA in its database to see whether it also 98 has an instance of the LSA. If it does not, or if the database copy 99 is less recent, the LSA is put on the Link state request list so that 100 it can be requested (immediately or at some later time) in Link State 101 Request Packets. In addition, if the Database summary list contains 102 an instance of the LSA that is the same as or less recent than the 103 listed LSA, the LSA is removed from the Database summary list. 105 The above additional step (which updates the Database summary list) 106 may be performed either before or after the router looks up the 107 listed LSA in its database and possibly adds the LSA to the Link 108 state request list. However, to implement the optimization, the 109 additional step must be performed for each LSA listed in the received 110 DD packet (to fully update the Database summary list) before the next 111 DD packet is sent in response. 113 Although the optimization does not require that LSAs be listed in DD 114 packets in any particular order, faster lookup of LSAs in the 115 Database summary list may be possible if LSAs are listed in the same 116 order by all routers. If such an ordering is used, then to encourage 117 different implementations to use the same ordering, this document 118 recommends that LSAs be listed in lexicographically increasing order 119 of (LS type, Link State ID, Advertising Router) for OSPFv2 and (LS 120 type, Advertising Router, Link State ID) for OSPFv3. 122 3. Example 124 This section describes an example to illustrate the database exchange 125 summary list optimization. Assume that routers RT1 and RT2 already 126 have identical databases when they start database exchange. Also 127 assume that the list of LSA headers for the database fits into two DD 128 packets. Then the standard database exchange is as follows when RT1 129 is the first to change the neighbor state to ExStart. Note that each 130 router sends two full DD packets. 132 RT1 (slave) RT2 (master) 134 ExStart Empty DD (Seq=x,I,M,Master) 135 ------------------------------> 136 Empty DD (Seq=y,I,M,Master) ExStart 137 <------------------------------ 138 Exchange Full DD (Seq=y,M,Slave) 139 ------------------------------> 140 Full DD (Seq=y+1,M,Master) Exchange 141 <------------------------------ 142 Full DD (Seq=y+1,Slave) 143 ------------------------------> 144 Full DD (Seq=y+2, Master) 145 <------------------------------ 146 Full Empty DD (Seq=y+2, Slave) 147 ------------------------------> 148 Full 150 If the optimization is used, when RT2 receives the first full DD 151 packet from RT1, it removes from its summary list all LSAs that are 152 listed in the DD packet. Then RT2 sends a DD packet that lists the 153 remaining LSAs (since all of the LSA headers fit into two DD 154 packets). When RT1 receives this DD packet, it removes these 155 remaining LSAs from its summary list (causing it to be empty) and 156 sends an empty DD packet to RT2. 158 With the optimization, each router sends only one full DD packet 159 instead of two, as shown below. 161 RT1 (slave) RT2 (master) 163 ExStart Empty DD (Seq=x,I,M,Master) 164 ------------------------------> 165 Empty DD (Seq=y,I,M,Master) ExStart 166 <------------------------------ 167 Exchange Full DD (Seq=y,M,Slave) 168 ------------------------------> 169 Full DD (Seq=y+1,Master) Exchange 170 <------------------------------ 171 Full Empty DD (Seq=y+1, Slave) 172 ------------------------------> 173 Full 175 4. Security Considerations 177 This document does not raise any new security concerns. 179 5. IANA Considerations 181 This document specifies a simple backward compatible optimization for 182 OSPFv2 and OSPFv3 that does not require any new number assignment. 184 6. Normative References 186 [RFC2328] J. Moy. "OSPF Version 2", RFC 2328, April 1998. 188 [RFC2740] R. Coltun, D. Ferguson, and J. Moy. "OSPF for IPv6", RFC 189 2740, December 1999. 191 Appendix A. Acknowledgments 193 The recommendation to list LSAs in lexicographical order was 194 suggested by Acee Lindem. 196 Author's Address 198 Richard G. Ogier 199 Email: rich.ogier@earthlink.net 201 Intellectual Property Statement 203 The IETF takes no position regarding the validity or scope of any 204 Intellectual Property Rights or other rights that might be claimed to 205 pertain to the implementation or use of the technology described in 206 this document or the extent to which any license under such rights 207 might or might not be available; nor does it represent that it has 208 made any independent effort to identify any such rights. Information 209 on the procedures with respect to rights in RFC documents can be 210 found in BCP 78 and BCP 79. 212 Copies of IPR disclosures made to the IETF Secretariat and any 213 assurances of licenses to be made available, or the result of an 214 attempt made to obtain a general license or permission for the use of 215 such proprietary rights by implementers or users of this 216 specification can be obtained from the IETF on-line IPR repository at 217 http://www.ietf.org/ipr. 219 The IETF invites any interested party to bring to its attention any 220 copyrights, patents or patent applications, or other proprietary 221 rights that may cover technology that may be required to implement 222 this standard. Please address the information to the IETF at 223 ietf-ipr@ietf.org. 225 Disclaimer of Validity 227 This document and the information contained herein are provided 228 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 229 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 230 THE IETF TRUST AND 231 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 232 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 233 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 234 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 235 PARTICULAR PURPOSE. 237 Copyright Statement 239 Copyright (C) The IETF Trust (2007). This document is subject 240 to the rights, licenses and restrictions contained in BCP 78, and 241 except as set forth therein, the authors retain all their rights. 243 Acknowledgment 245 Funding for the RFC Editor function is provided by the IETF 246 Administrative Support Activity (IASA).