OSPF Working Group S. Kini
Internet-Draft W. Lu
Intended Status: Standards Track A. Tian
Expires: April 2011 Ericsson
October 18, 2010
OSPF Fast Notifications
draft-kini-ospf-fast-notification-00.txt
Status of this Memo
Distribution of this memo is unlimited.
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 21, 2011.
Copyright Notice
Copyright (c) 2010 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.
Kini et al Expires April 2011 [Page 1]
Internet Draft OSPF Fast Notification October 18, 2010
Abstract
Several applications could use a mechanism to quickly notify one or
more routers about control-protocol events. Current mechanisms to
convey such information to routers multiple hops away involves hop-
by-hop protocol-specific control plane processing as well as hop-by-
hop control plane forwarding. The delay due to control planes
involvement in processing/forwarding, adversely affects the
application's goal (e.g. fast convergence). This document describes a
framework to use data plane forwarding to convey control protocol
information multiple hops away. It also defines some sample
applications within this framework.
Kini et al Expires April 2011 [Page 2]
Internet Draft OSPF Fast Notification October 18, 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A: OSPF fast convergence on link-down using FN . . . . . . 7
A.1. OSPF procedural changes . . . . . . . . . . . . . . . . . 7
A.2. FN service using spanning tree . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Kini et al Expires April 2011 [Page 3]
Internet Draft OSPF Fast Notification October 18, 2010
1. Introduction
There are several applications that could use a mechanism to quickly
notify one or more routers in a network about a specific control-
protocol event. If the destination router(s) is more than one hop
away then the message has to be forwarded by the intermediate
routers. This forwarding typically does not exclusively happen via
the forwarding plane.
Some applications establish adjacent neighbor relationship with
single hop neighbors. Information that needs to be conveyed multiple
hops away is first conveyed to adjacent neighbors that are a single
hop away. Each neighbor then performs application specific processing
and forwards information further. The delay in receiving the
information at a router is gated by the processing and forwarding
speed of the control plane at each hop along a path from the
originating router.
A typical example of an application that sends information to
directly connected adjacent neighbors is a link-state routing
interior gateway protocol (IGP) such as [OSPF]. When conveying a Link
State Advertisement (LSA) to all routers in the area, OSPF's flooding
algorithm transmits the LSA to its single hop away adjacent neighbor.
The received LSA undergoes processing according to OSPF's processing
rules and is then forwarded to OSPF neighbors further away from the
router originating the LSA. As explained earlier the delay in
receiving a LSA at a router is gated by the processing and forwarding
speed of the control plane at each hop along a path from the
originating OSPF router.
Some applications need to send information to routers that are
multiple hops away even though they do not have adjacency
relationship with directly connected neighbors. In such cases the
forwarding of application messages depends on the forwarding plane
being setup by an underlying protocol that has established adjacent
neighbor relationship with routers that are a single hop away. In
scenarios where the data plane forwarding is changing due to the
underlying protocol, the applications message forwarding speed and
reliability is gated by the speed and mechanisms of the underlying
protocols hop-by-hop message processing and forwarding by control-
plane.
A typical example of an application that could use a mechanism to
send information to non-directly connected neighbors is IP
FastReroute (IP-FRR). It could use a forwarding mechanism that has
been setup by an underlying protocol to trigger (on failure) a non-
directly connected neighbor, to switch traffic to an alternate path.
To reliably deliver the applications message, the forwarding
Kini et al Expires April 2011 [Page 4]
Internet Draft OSPF Fast Notification October 18, 2010
mechanism has to be resilient against failures and the changed
topology.
2. Conventions used in this document
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. Scope
This document describes a framework for quickly delivering
notifications from one router to one or more routers using data plane
as the main forwarding mechanism. It also defines some solutions
under this framework to address the needs of some specific
applications.
4. Requirements
Fast notifications (henceforth referred to as FN) must be designed as
a set of services that can satisfy the requirements of different
control-protocol applications. FN should avoid introducing new
protocols and should re-use existing, commonly used protocols as much
as possible.
Deploying FN must not introduce new encapsulation requirements for
routers unless those encapsulations are already available in the data
plane for those applications. Notifying multiple routers should use
multicast whenever possible.
5. Architecture
A choice of protocol to realize FN must be based on the set of
commonly deployed protocols. These protocols must preferably have
applicability in a wide set of network architectures such as IP-
routing, L3VPN, L2VPN etc. Also, the knowledge of the network
topology would be particularly useful for path computation purposes.
The logical candidate for these requirements would be a link-state
interior gateway protocol (IGP) such as OSPF or IS-IS.
To implement a specific FN service, a router must convey its
capability to the set of routers that setup forwarding to one or more
routers in that set for specific packets in a way such that data-
plane forwarding of notifications. It must also convey its share of
the information that is needed to implement that FN service.
To convey this information via OSPF, an opaque LSA is used. An Opaque
type field "FN" is defined. The type specific ID indicates a
Kini et al Expires April 2011 [Page 5]
Internet Draft OSPF Fast Notification October 18, 2010
particular FN service. The content of the LSA is a variable list of
TLVs that include information required to implement that FN service.
Different FN services will have different sets of TLVs. A specific
instance of a FN service and how an application might use it is
specified in Appendix A.
5. Security Considerations
Security considerations of the application also apply when FN service
is used by the application. If additional security considerations
arise due to the way in which FN is used by the application, then
those should be resolved in the document that explains how an
application uses FN.
6. IANA Considerations
IANA needs to allocate a OSPF opaque type field for FN. Within that
LSID values for different FN services will have to be allocated. Also
a TLV type field will have to be allocated.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[OSPF] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
8. Acknowledgements
The authors would like to thank Joel Halpern for his comments.
Kini et al Expires April 2011 [Page 6]
Internet Draft OSPF Fast Notification October 18, 2010
Appendix A: OSPF fast convergence on link-down using FN
OSPF fast convergence is gated by how quickly the flooding algorithm
can propagate the LSA throughout the area. This requires hop-by-hop
processing and forwarding by control plane. If a FN service can
transmit the link-down notification to all routers in the area then
OSPF's fast convergence can be improved in the link-down scenario.
A.1. OSPF procedural changes OSPF's procedures must be modified to use
the FN service as follows. OSPF transmits a copy of the updated
Router LSA (on link-down) using a FN service in addition to the
normal processing and flooding done by OSPF. The destination IP
address of the link-state update (LSU) packet is set to the one
dictated by the FN service. If Cryptographic authentication is
required, a shared secret key must be configured for the area. The
Cryptographic sequence number in the LSU must be set to zero. On
receiving a LSU via FN, the router accepts it if authentication
succeeds. There must be no acknowledgement for such an LSU. If the
received LSA is older than the one in the LSDB, the received LSA is
discarded. If the received LSA is newer, the LSA is stored alongside
the older copy and a timer T-discard-FN-LSA is started. A flag FN-
LSA-present is used in the LSDB entry to indicate that a newer
version of the LSA (received via FN) is present. SPF is triggered.
During SPF, if the FN-LSA-present flag is true then the LSA received
via FN is used instead. When a LSA is received via the flooding
procedure of [OSPF], and is determined to be newer, it is compared
with the LSA copy received via FN (if one exists). If the two copies
are the same, the LSA received via FN becomes the only entry in the
LSDB. If the two copies are different, the LSA received through the
flooding procedure of [OSPF] becomes the only copy in the LSDB and
SPF is triggered. In both cases the flag FN-LSA-present is cleared
and the timer T-discard-FN-LSA is canceled. When the timer T-discard-
FN-LSA expires, the corresponding LSA copy received via FN is
discarded (FN-LSA-present flag is cleared) and SPF is triggered.
A.2. FN service using spanning tree
One way to provide the FN service for this application is as follows.
A multicast spanning tree (with a specially allocated multicast
destination IP address) is used to send the link-down notification
message. The tree must be consistently computed at all routers. It
must be computed as a shortest path tree rooted at the highest
router-id. During tree computation only routers that are capable of
this FN service are picked. When multiple paths are available the
neighboring node in the graph with highest LSID is picked. When
multiple paths are available through multiple interfaces to a
neighboring node, a numbered interface is preferred over an
Kini et al Expires April 2011 [Page 7]
Internet Draft OSPF Fast Notification October 18, 2010
unnumbered interface. A higher IP address is preferred among numbered
interfaces and a higher ifIndex is preferred among unnumbered
interfaces. Multicast forwarding state is installed using such a tree
as a bi-directional tree. Each router on the tree can send packets to
all other routers on that tree. Even when the topology changes such
that the tree breaks, the link-down notification is delivered to all
routers.
Kini et al Expires April 2011 [Page 8]
Internet Draft OSPF Fast Notification October 18, 2010
Authors' Addresses
Sriganesh Kini
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: sriganesh.kini@ericsson.com
Wenhu Lu
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: wenhu.lu@ericsson.com
Albert Tian
Ericsson
300 Holger Way, San Jose, CA 95134
EMail: albert.tian@ericsson.com
Kini et al Expires April 2011 [Page 9]