OSPF Link-Local Signaling
RFC 5613
| Document | Type |
RFC - Proposed Standard
(August 2009; No errata)
Obsoletes RFC 4813
Was draft-ietf-ospf-lls (ospf WG)
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 5613 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Ross Callon | ||
| Send notices to | (None) | ||
Network Working Group A. Zinin
Request for Comments: 5613 Alcatel-Lucent
Obsoletes: 4813 A. Roy
Category: Standards Track L. Nguyen
Cisco Systems
B. Friedman
Google, Inc.
D. Yeung
Cisco Systems
August 2009
OSPF Link-Local Signaling
Abstract
OSPF is a link-state intra-domain routing protocol. OSPF routers
exchange information on a link using packets that follow a well-
defined fixed format. The format is not flexible enough to enable
new features that need to exchange arbitrary data. This document
describes a backward-compatible technique to perform link-local
signaling, i.e., exchange arbitrary data on a link. This document
replaces the experimental specification published in RFC 4813 to
bring it on the Standards Track.
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Zinin, et al. Standards Track [Page 1]
RFC 5613 OSPF Link-Local Signaling August 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 2
2. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 3
2.1. L-Bit in Options Field . . . . . . . . . . . . . . . . . . 4
2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 4
2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Extended Options and Flags TLV . . . . . . . . . . . . . . 5
2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 6
2.6. Private TLVs . . . . . . . . . . . . . . . . . . . . . . . 7
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11
Appendix B. Changes from RFC 4813 . . . . . . . . . . . . . . . . 11
1. Introduction
This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3
[OSPFV3] allowing additional information to be exchanged between
routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed
and do not allow for extension. This document proposes appending an
optional data block composed of Type/Length/Value (TLV) triplets to
existing OSPFv2 and OSPFv3 packets to carry this additional
information. Throughout this document, OSPF will be used when the
specification is applicable to both OSPFv2 and OSPFv3. Similarly,
OSPFv2 or OSPFv3 will be used when the text is protocol specific.
One potential way of solving this task could be introducing a new
packet type. However, that would mean introducing extra packets on
the network that may not be desirable and may cause backward
compatibility issues. This document describes how to exchange data
using standard OSPF packet types.
1.1. Requirements Notation
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 [KEY].
Show full document text