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)
|
|
---|---|---|---|
Authors | Barry Friedman , Liem Nguyen , Abhay Roy , Alex Zinin , Derek Yeung | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized 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]. Zinin, et al. Standards Track [Page 2] RFC 5613 OSPF Link-Local Signaling August 2009 2. Proposed Solution To perform link-local signaling (LLS), OSPF routers add a specialShow full document text