Internet DRAFT - draft-retana-ospf-ils
draft-retana-ospf-ils
Network Working Group A. Retana
Internet-Draft Hewlett-Packard Co.
Intended status: Informational A. Lindem
Expires: January 14, 2013 Ericsson
July 13, 2012
OSPF Incremental Link State Database Synchronization
draft-retana-ospf-ils-01
Abstract
The ability of OSPF to transport non-routing information to be used
by other applications was defined by the Opaque LSA Option. In order
to not impact the convergence of routing information, this document
describes a simple process to incrementally synchronize the routing
and non-routing information residing in an OSPF link-state database.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Retana & Lindem Expires January 14, 2013 [Page 1]
Internet-Draft OSPF Incremental LSDB Sync July 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3
3. Incremental LSDB Synchronization Process . . . . . . . . . . . 3
3.1. Graceful Restart . . . . . . . . . . . . . . . . . . . . . 4
3.2. Flooding and Database Synchronization . . . . . . . . . . . 5
4. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Changes between the -00 and -01 versions. . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Retana & Lindem Expires January 14, 2013 [Page 2]
Internet-Draft OSPF Incremental LSDB Sync July 2012
1. Introduction
Opaque LSAs [RFC5250] provide the ability for OSPFv2 [RFC2328] to
transport non-routing information to be used by other applications.
A similar capability exists in OSPFv3 [RFC5340] through the use of
the U-bit and an appropriate LSA Function Code. Throughout this
document Opaque LSAs and ones with unrecognized link-state types will
be referred to simply as "opaque".
The presence of opaque information in the OSPF Link-State Database
(LSDB) may result in longer database exchange times, especially in
cases where the amount of data is significantly larger than the
routing-specific information. In order to not impact the convergence
of routing information, this document describes a simple process to
incrementally synchronize the information residing in an OSPF LSDB.
The process uses existing mechanisms.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. Incremental LSDB Synchronization Process
The Incremental LSBD Synchronization (ILS) process consists of the
following steps:
LSA Prioritization
The contents of the local LSDB are classified to determine
which LSAs require prioritized synchronization.
In general, LSAs containing routing-specific information MUST
be classified as requiring prioritized synchronization, while
other LSAs MAY be classified as not requiring it.
All routers in the OSPF routing domain should use the same
criteria for LSA prioritization. While this is not required
for correct OSPF operation, it is required for deterministic
operation of the applications using the opaque LSAs.
Prioritized LSDB Synchronization
This step corresponds to the adjacency establishment process
as described in [RFC2328].
Retana & Lindem Expires January 14, 2013 [Page 3]
Internet-Draft OSPF Incremental LSDB Sync July 2012
LSAs classified as not requiring prioritized synchronization
MUST NOT be included in Database Description (DBD) Packets
during the Database Exchange Process. The OSPF routing table
structure SHOULD be calculated before moving on to the next
step.
Final LSDB Synchronization
In this step, any remaining LSAs in the LSDB SHOULD be
synchronized. The routers MUST use the Out-of-Band LSDB
Resynchronization [RFC4811] (OOB Resync) mechanism, which
provides a way to resynchronize the LSDB without affecting
the advertised neighbor state.
The process is described in terms of LSAs containing (or not)
routing-specific information, but it may be generalized to include
any other criteria considered significant in the local network and
protocol instance.
The last step in the process MAY be used recursively to achieve an
incremental LSDB synchronization through different types of data,
making it also applicable to environments where only non-routing
information exists.
3.1. Graceful Restart
The restart of the OSPF software in a router also presents an
opportunity for LSDB synchronization. Because the restarting router
is still in the forwarding path, it is important for the routing
information in the LSDB to be synchronized as fast as possible. ILS
can be used, with minor modifications, to reduce the synchronization
time and the probability of network topology changes.
Graceful OSPF Restart
Graceful OSPF Restart for OSPFv2 [RFC3623] and OSPFv3
[RFC5187] don't specify any changes to the adjacency
establishment process.
ILS can be used by the Helper Neighbor during the Grace
Period; if so, then the Helper Node MUST include any Grace-
LSAs in the DBD Packets during the Prioritized LSDB
Synchronization step.
OSPF Restart Signaling
OSPF Restart Signaling [RFC4812] defines a mechanism to
inform neighbors about a local restart, in which the LSDB
synchronization is achieved using OOB Resync. In other
words, the Prioritized LSDB Synchronization step would use
OOB Resync if the non-restarting router uses ILS. No other
Retana & Lindem Expires January 14, 2013 [Page 4]
Internet-Draft OSPF Incremental LSDB Sync July 2012
changes to the process are needed.
3.2. Flooding and Database Synchronization
In order to maintain OSPF reliable flooding, separate neighbor
flooding state must be maintained for the lower priority LSAs and
used when determining whether a lower priority LSA has been flooded
or put on a neighbor's retransmission list.
The rules for flooding lower-priority LSAs and deleting lower
priority MaxAge LSAs are modified for ILS synchronization. Neighbor
state MUST be maintained as to whether low-priority LSAs have been
synchronized with a given neighbor. In this document, this lower
priority state will be referred to as ILS-state. This ILS-state will
not advance until a neighbor reaches Full state and will return to
Down ILS-state should the neighbor fall from Full state.
If a given neighbor's ILS-state is Exchange or higher, then lower
priority LSAs should be flooded to that neighbor. This similar to
the general LSA flooding rules in Section 13.1 of [RFC2328].
Consistent with Section 14.1 in [RFC2328], a lower priority MaxAge
LSA cannot be removed the Link State Database if any the router is in
Exchange or Loading ILS-state.
If multiple ILS synchronizations are used for synchronization
different priorities of LSAs, separate ILS-state MUST be maintained
for each priority and the previously described rules MUST be applied
at each priority.
4. Backward Compatibility
The operation of ILS depends on the support of OOB Resync during
synchronization; no backwards compatibility issues exist there
[RFC4811]. If OOB Resync is not supported by one of the routers,
then the LSDB synchronization would fall back to the adjacency
establishment process as described in [RFC2328].
If OOB Resync is supported, but ILS has not been implemented by all
the routers involved, the operation is still backwards compatible.
Note that the process (Section 3) depends on the database description
by the local router. In other words, a router may decide to not
fully describe the contents of its LSDB to its neighbor during the
adjacency establishment process, and later use OOB Resync to
incrementally describe the difference; the receiver doesn't need to
be aware of ILS. The benefits of ILS may only be partially realized
if not supported by all the routers involved in synchronization.
Retana & Lindem Expires January 14, 2013 [Page 5]
Internet-Draft OSPF Incremental LSDB Sync July 2012
5. IANA Considerations
This memo includes no request to IANA.
6. Security Considerations
The process described in this document does not introduce any new
security issues into the OSPF protocol.
7. Acknowledgements
The authors would like to thank Abhay Roy and Liem Nguyen for their
comments, and Dimitri Papadimitriou for his comments and for
providing the motivation for this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
State Database (LSDB) Resynchronization", RFC 4811,
March 2007.
8.2. Informative References
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, November 2003.
[RFC4812] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart
Signaling", RFC 4812, March 2007.
[RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful
Restart", RFC 5187, June 2008.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
Retana & Lindem Expires January 14, 2013 [Page 6]
Internet-Draft OSPF Incremental LSDB Sync July 2012
Appendix A. Changes between the -00 and -01 versions.
o Added a new section explaining how to maintain reliable flooding
for the low priority LSAS.
o Updated authors and contact information.
Authors' Addresses
Alvaro Retana
Hewlett-Packard Co.
2610 Wycliff Road
Raleigh, NC 27607
USA
Email: alvaro.retana@hp.com
Acee Lindem
Ericsson
102 Carric Bend Court
Cary, NC 27519
USA
Email: acee.lindem@ericsson.com
Retana & Lindem Expires January 14, 2013 [Page 7]
