n = Upper limit on the number of adjacencies to be brought up
simultaneously (used in Recommendation 5).
R(i) = RxmtInterval value used during the i-th retransmission of an
LSA (used in Recommendation 3).
Rmax = The maximum allowed value of RxmtInterval (used in
Recommendation 3). Example value is 40 seconds.
Rmin = The minimum allowed value of RxmtInterval (used in
Recommendation 3). Example value is 5 seconds.
T = Minimum time that has to elapse before the existing gap
between sending successive LSAs to a neighbor is considered
for change (used in Recommendation 4). Example value is 1
second.
U(t) = Number of unacknowledged LSAs to a neighbor at time t (used in
Recommendation 4).
Appendix C. Other Recommendations and Suggestions
(1) Explicit Marking: In Section 2, we recommended that OSPF packets
be classified to "high" and "low" priority classes based on
examining the OSPF packet header. In some cases (particularly in
the receiver), this examination may be computationally costly.
An alternative would be the use of different TOS/Precedence field
settings for the two priority classes. [Ref1] recommends setting
the TOS field to 0 and the Precedence field to 6 for all OSPF
packets. We recommend this same setting for the "low" priority
OSPF packets and a different setting for the "high" priority OSPF
packets in order to be able to classify them separately without
having to examine the OSPF packet header. Two examples are given
below:
Example 1: For "low" priority packets, set TOS field to 0 and
Precedence field to 6, and for "high" priority packets
set TOS field to 4 and Precedence field to 6.
Example 2: For "low" priority packets, set TOS field to 0 and
Precedence field to 6, and for "high" priority packets
set TOS field to 0 and Precedence field to 7.
Note that the TOS/Precedence bits have been redefined by Diffserv
(RFC 2474, [Ref14]). Also note that the different TOS/Precedence
field settings suggested above only need to be agreed among the
systems on the link. This recommendation is not needed to be
followed if it is easy to examine the OSPF packet header and
thereby separately classify "high" and "low" priority packets.
(2) Further Prioritization of OSPF Packets: Besides the packets
designated as "high" priority in Recommendation 1 of Section 2,
there may be a need for further priority separation among the
"low" priority OSPF packets. We recommend the use of three
priority classes: "high", "medium" and "low". While receiving a
packet from a neighbor and while transmitting a packet to a
neighbor, try to process a "high priority" packet ahead of
"medium" and "low" priority packets and a "medium" priority
packet ahead of "low priority" packets. The "high" priority
packets are as designated in Recommendation 1 of Section 2. We
provide below two candidate examples for "medium" priority
packets. All OSPF packets not designated as "high" or "medium"
priority are "low" priority. If Cryptographic Authentication
(AuType = 2) is used (as specified in [Ref1]), then prioritized
treatment is to be provided only at the receiver and after
security processing, but not at the transmitter since that may
cause packets to arrive out of sequence and violate the
requirements of "Autype = 2".
One example of "medium" priority packet is the Database
Description (DBD) packet from a slave (during the database
synchronization process) that is used as an acknowledgment.
A second example is an LSA carrying intra-area topology change
information (this may trigger SPF calculation and rerouting of
Label Switched Paths, so fast processing of this packet may
improve OSPF/Label Distribution Protocol (LDP) convergence
times). However, if the processing cost of identifying and
separately queueing the LSA in this example is deemed to be high,
then the implementer may decide not to do it.
(3) Processing a Large Number of LSA Purges: Occasionally, some
events in the network, such as router ID changes, may result in a
large number of LSA re-originations and LSA purges. In such a
scenario, one may consider processing LSAs in different order,
e.g., processing LSA purges ahead of LSA originations. We,
however, do not recommend out-of-order LSA processing for several
reasons. First, detecting the LSA type ahead of queueing may be
computationally expensive. Out-of-order processing may also
cause subtle bugs. We do not want to recommend a major change in
the LSA processing paradigm for a relatively rare event such as
router ID change. However, a router with a changing ID may flush
the old LSAs gradually without causing a storm.
Contributing Authors and Their Addresses
In addition to the editor, several people contributed to this
document. The names and contact information of all authors are given
below.
Anurag S. Maunder
Erlang Technology
2880 Scott Boulevard
Santa Clara, CA 95052
USA
Phone: (408) 420-7617
EMail: anuragm@erlangtech.com
Gerald R. Ash
AT&T
Room D5-2A01
200 Laurel Avenue
Middletown, NJ, 07748
USA
Phone: (732) 420-4578
EMail: gash@att.com
Vishwas Manral
Sinett Corp,
2/1 Embassy Icon Annex,
Infantry Road,
Bangalore 560 001
India
Phone: +91-(805)-137-7023
EMail: vishwas@sinett.com
Vera D. Sapozhnikova
AT&T
Room C5-2C29
200 Laurel Avenue
Middletown, NJ, 07748
USA
Phone: (732) 420-2653
EMail: sapozhnikova@att.com
Editor’s Address
Gagan L. Choudhury
AT&T
Room D5-3C21
200 Laurel Avenue
Middletown, NJ, 07748
USA
Phone: (732) 420-3721
EMail: gchoudhury@att.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.