datatracker.ietf.org
Sign in
Version 5.6.2.p1, 2014-07-22
Report a bug

Extensions to OSPF for Advertising Optional Router Capabilities
RFC 4970

Document type: RFC - Proposed Standard (July 2007; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4970 (Proposed Standard)
Responsible AD: Bill Fenner
Send notices to: ospf-chairs@tools.ietf.org

Network Working Group                                     A. Lindem, Ed.
Request for Comments: 4970                              Redback Networks
Category: Standards Track                                        N. Shen
                                                             JP. Vasseur
                                                           Cisco Systems
                                                             R. Aggarwal
                                                        Juniper Networks
                                                              S. Shaffer
                                                     BridgePort Networks
                                                               July 2007

    Extensions to OSPF for Advertising Optional Router Capabilities

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) The IETF Trust (2007).

Abstract

   It is useful for routers in an OSPFv2 or OSPFv3 routing domain to
   know the capabilities of their neighbors and other routers in the
   routing domain.  This document proposes extensions to OSPFv2 and
   OSPFv3 for advertising optional router capabilities.  A new Router
   Information (RI) Link State Advertisement (LSA) is proposed for this
   purpose.  In OSPFv2, the RI LSA will be implemented with a new opaque
   LSA type ID.  In OSPFv3, the RI LSA will be implemented with a new
   LSA type function code.  In both protocols, the RI LSA can be
   advertised at any of the defined flooding scopes (link, area, or
   autonomous system (AS)).

Lindem, et al.              Standards Track                     [Page 1]
RFC 4970               OSPF Capability Extensions              July 2007

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  3
   2.  OSPF Router Information (RI) LSA . . . . . . . . . . . . . . .  3
     2.1.  OSPFv2 Router Information (RI) Opaque LSA  . . . . . . . .  3
     2.2.  OSPFv3 Router Information (RI) Opaque LSA  . . . . . . . .  5
     2.3.  OSPF Router Informational Capabilities TLV . . . . . . . .  5
     2.4.  Assigned OSPF Router Informational Capability Bits . . . .  6
     2.5.  Flooding Scope of the Router Information LSA . . . . . . .  7
   3.  Router Information LSA Opaque Usage and Applicability  . . . .  7
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 11

Lindem, et al.              Standards Track                     [Page 2]
RFC 4970               OSPF Capability Extensions              July 2007

1.  Introduction

   It is useful for routers in an OSPFv2 [OSPF] or OSPFv3 [OSPFV3]
   routing domain to know the capabilities of their neighbors and other
   routers in the routing domain.  This can be useful for both the
   advertisement and discovery of OSPFv2 and OSPFv3 capabilities.
   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.

   OSPF uses the options field in LSAs and hello packets to advertise
   optional router capabilities.  In the case of OSPFv2, all the bits in
   this field have been allocated so new optional capabilities cannot be
   advertised.  This document proposes extensions to OSPF to advertise
   these optional capabilities via opaque LSAs in OSPFv2 and new LSAs in
   OSPFv3.  For existing OSPF capabilities, backward- compatibility
   issues dictate that this advertisement is used primarily for
   informational purposes.  For future OSPF features, this advertisement
   MAY be used as the sole mechanism for advertisement and discovery.

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 [RFC-KEYWORDS].

[include full document text]