[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-coltun-ospf-opaque) 00 01 02 03 04 05 RFC 2370

Internet-Draft                    Opaque                      November 1996


Expiration Date: May 1997                                     FORE Systems
File name: draft-ietf-ospf-opaque-00.txt












                        The OSPF Opaque LSA Option






                                Rob Coltun
                               FORE Systems
                              (301) 571-2521
                             rcoltun@fore.com






     Status Of This Memo

     This document is an Internet-Draft.  Internet-Drafts are working docu-
     ments of the Internet Engineering Task Force (IETF), its areas, and
     its working groups.  Note that other groups may also distribute work-
     ing 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".

     To learn the current status of any Internet-Draft, please check the
     "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
     Directories on ds.internic.net (US East Coast), nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).




Coltun                                                             [Page 1]


Internet-Draft                    Opaque                      November 1996


     Table Of Contents

          1.0 Abstract ................................................. 3

          2.0 Overview ................................................. 3

          2.1 Organization Of This Document ............................ 3

          2.2 Acknowledgments .......................................... 3

          3.0 The Opaque LSA ........................................... 4

          3.1 Flooding Opaque LSAs ..................................... 5

          3.2 Modifications To The Neighbor State Machine .............. 6

          4.0 Protocol Data Structures ................................. 8

          4.1 Additions To The OSPF Interface Structure ................ 8

          4.2 Additions To The OSPF Neighbor Structure ................. 8

          5.0 References ............................................... 9

          Appendix A: OSPF Data Formats ................................ 10

          A.1 The Options Field ........................................ 10

          A.2 Opaque LSA ............................................... 12






















Coltun                                                             [Page 2]


Internet-Draft                    Opaque                      November 1996


     1.0  Abstract

     This memo documents enhancements to the OSPF protocol to support a new
     type of link-state advertisement (LSA) called the Opaque LSA.  The
     Opaque LSA option defines a general mechanism to allow for future
     extensibility of OSPF. The information contained in Opaque LSAs may be
     used directly by OSPF or by other protocols.  Opaque LSAs contain some
     number of octets padded to 32-bit alignment.  The standard OSPF link-
     state database flooding mechanisms are use for distribution of Opaque
     LSAs.  Opaque LSAs are flooded throughout all or some limited portion
     of the OSPF topology.

     2.0  Overview


     Over the last few years the OSPF routing protocol [OSPF] has been
     widely deployed throughout the Internet.  As a result of this deploy-
     ment and the evolution of networking technology, OSPF has been
     extended to support many options; this evolution will obviously con-
     tinue.

     This memo documents enhancements to the OSPF protocol to support a new
     type of link-state advertisement (LSA) called the Opaque LSA which
     defines an optional generalized mechanism to allow for future extensi-
     bility of OSPF. The information contained in Opaque LSAs may be used
     directly by OSPF or by other protocols.  For example, the OSPF LSA may
     be used to distribute BGP AS Path information (as documented in The
     OSPF External Attributes LSA [EAL]) which is then used by BGP route-
     leaking mechanisms. The option may also be used to distribute IP QoS
     information which may be used directly by an OSPF path computation.
     The exact use of the Opaque LSA is beyond the scope of this draft.

     The data contained in the Opaque LSA is some number of 32-bit aligned
     octets.  Like any other LSA, the Opaque LSA uses the link-state data-
     base distribution mechanism for flooding this information throughout
     the topology.  The Flooding Scope identifies the range of the topology
     to which this LSA may be distributed to.


     2.1  Organization Of This Document

     This document first defines the Opaque LSA followed by a description
     of OSPF packet processing which includes modifications to the flooding
     procedure and the neighbor state machine needed to support the Opaque
     LSA.  Appendix A then gives the packet formats.


     2.2 Acknowledgments



Coltun                                                             [Page 3]


Internet-Draft                    Opaque                      November 1996


     The author would like to thank Dennis Ferguson, John Moy, Zhaohui
     "Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas
     and support they have given to this project.



     3.0 The Opaque LSA

     Opaque LSAs are the Type 15 link-state advertisements.  These adver-
     tisements are originated by any router.  The data contained in the
     Opaque LSA consists of some number of octets aligned to a 32-bit boun-
     dary.  Like any other LSA, the Opaque LSA uses the link-state database
     distribution mechanism for flooding this information throughout the
     topology.  The Flooding Scope field in the Opaque LSA identifies the
     range of the topology to which this LSA may be distributed to.  This
     section documents the flooding of Opaque LSAs.

     The following are possible values of the Flooding Scope field.

          o A value of 0 denotes a link-local scope. Opaque LSAs with a
          Flooding Scope of 0 are not flooded beyond the local
          (sub)network.

          o A value of 1 denotes an area-local scope. Opaque LSAs with a
          flooding scope of 1 are not flooded beyond the area that they are
          originated into.

          o A value of 2 denotes that the LSA is flooded throughout the
          Autonomous System.

     Origination of Opaque LSAs are unique to the application using it.
     The link-state ID of the Opaque LSA is divided into a type field (the
     first 8 bits) a type-specific ID (the remaining 24 bits).  The packet
     format of the Opaque LSA is given in Appendix A.

     The responsibility for proper handling of the Opaque LSA's Flooding
     Scope field is placed on the sender of the LSA.  The receiver must
     always store a valid received Opaque LSA in its link-state database.
     Flooding scope effects both the building of the Database summary list
     during the initial synchronization of the link-state database and the
     flooding procedure.

     In order to make the use of the Opaque LSAs predictable, it is recom-
     mended that all routers within the scope of use have the same Opaque
     LSA capabilities. For example, if the Opaque LSA is to be used for
     flooding Opaque information throughout a single area, all routers
     within the area should support the Opaque option.




Coltun                                                             [Page 4]


Internet-Draft                    Opaque                      November 1996


     The following describes the modifications to these procedures that are
     necessary to insure proper use of the Opaque LSA's Scoping Rules.


     3.1  Flooding Opaque LSAs

     The flooding of Opaque LSAs must follow the rules of Flooding Scope as
     specified in this section. The flooding mechanisms must suppress the
     flooding of Opaque LSAs as described in the following.


          o If the Flooding Scope is link-local and the interface that the
          LSA was received on is not the same as the target interface
          (e.g., the interface associated with a particular neighbor), the
          Opaque LSA must not be flooded out that interface (or to that
          neighbor).  An implementation should keep track of the IP inter-
          face associated with each Opaque LSA having a link-local flooding
          scope.

          o If the Flooding Scope is area-local and the area associated
          with Opaque LSA is not the area associated with a particular
          interface, the Opaque LSA must not be flooded out the interface.
          An implementation should keep track of the OSPF area associated
          with each Opaque LSA having an area-local flooding scope.

     When opaque-capable routers and non-opaque-capable OSPF routers are
     mixed together in a routing domain, the Opaque LSAs are not flooded to
     the non-opaque-capable routers. As a general design principle,
     optional OSPF advertisements are only flooded to those routers that
     understand them.

     An opaque-capable router learns of its neighbor's opaque capability at
     the beginning of the "Database Exchange Process" (see Section 10.6 of
     [OSPF], receiving Database Description packets from a neighbor in
     state ExStart). A neighbor is opaque-capable if and only if it sets
     the O-bit in the Options field of its Database Description packets.
     Then, in the next step of the Database Exchange process, Opaque LSAs
     are included in the Database summary list sent to the neighbor (see
     Sections 3.2 below and 10.3 of [OSPF]) if and only if the neighbor is
     opaque-capable.

     When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable
     router looks at the neighbor's opaque capability.  Opaque LSAs are
     only flooded to opaque capable neighbors. To be more precise, in Sec-
     tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state
     retransmission lists of opaque-capable neighbors.  Note however that
     when sending Link State Update packets as multicasts, a non-opaque-
     capable neighbor may (inadvertently) receive Opaque LSAs. The non-



Coltun                                                             [Page 5]


Internet-Draft                    Opaque                      November 1996


     opaque-capable router will then simply discard the LSA (see Section 13
     of [OSPF], receiving LSAs having unknown LS types).


     3.2 Modifications To The Neighbor State Machine

     The state machine as it exists in section 10.3 of [OSPF] remains
     unchanged except for the action associated with State: ExStart, Event:
     NegotiationDone which is where the Database summary list is built.  To
     incorporate the Opaque LSA in OSPF the action is changed to the fol-
     lowing.

      State(s):  ExStart

         Event:  NegotiationDone

     New state:  Exchange

        Action:  The router must list the contents of its entire area
                 link-state database in the neighbor Database summary
                 list.  The area link-state database consists of the
                 Router LSAs, Network LSAs and Summary LSAs
                 contained in the area structure, along with Opaque and
                 AS External LSAs contained in the global structure.
                 AS External LSAs are omitted from a
                 virtual neighbor's Database summary list.  AS
                 External LSAs are omitted from the Database
                 summary list if the area has been configured
                 as a stub (see Section 3.6 of [OSPF]).

                 Opaque LSAs are omitted from the Database
                 summary list if the following conditions
                 are met: 1) the Flooding Scope is link-local
                 and the interface associated with the Opaque
                 LSA (upon reception) does not equal the
                 interface associated with the neighbor;
                 2) the Flooding Scope is area-local and the
                 area associated with Opaque LSA is not the
                 area associated with the neighbor's interface.

                 Any advertisement whose age is equal to MaxAge is
                 omitted from the Database summary list. It is
                 instead added to the neighbor's link-state
                 retransmission list.  A summary of the Database
                 summary list will be sent to the neighbor in
                 Database Description packets.  Each Database
                 Description Packet has a DD sequence number, and is
                 explicitly acknowledged.  Only one Database



Coltun                                                             [Page 6]


Internet-Draft                    Opaque                      November 1996


                 Description Packet is allowed to be outstanding at
                 any one time. For more detail on the sending and
                 receiving of Database Description packets, see
                 Sections 10.8 and 10.6 of [OSPF].















































Coltun                                                             [Page 7]


Internet-Draft                    Opaque                      November 1996


     4.0  Protocol data structures

     The Opaque option is described herein in terms of its operation on
     various protocol data structures. These data structures are included
     for explanatory uses only, and are not intended to constrain an OSPF
     implementation. Besides the data structures listed below, this specif-
     ication will also reference the various data structures (e.g., OSPF
     interfaces and neighbors) defined in [OSPF].

     In an OSPF router, the following item is added to the list of global
     OSPF data structures described in Section 5 of [OSPF]:

          o Opaque capability. Indicates whether the router is running the
          Opaque option (i.e., capable of storing Opaque LSAs).  Such a
          router will continue to inter-operate with non-opaque-capable
          OSPF routers.

     4.1 Additions To The OSPF Interface Structure

     The OSPF interface structure is described in Section 9 of [OSPF]. In
     an opaque-capable router, the following item is added to the OSPF
     interface structure. Note that the Opaque capability parameter is
     really a description of this router's view of the attached network.
     As such, it should be configured identically on all routers attached
     to a common network; otherwise incorrect or incomplete distribution of
     Opaque LSAs may occur.

          o OpaqueInterfaceOn. This configurable parameter indicates
          whether Opaque LSAs should be flooded over the attached network.
          The parameter can assume a value of disabled or enabled.  When
          set to disabled, Opaque LSAs will not be flooded out the inter-
          face; when set to enabled Opaque LSAs will be flooded out the
          interface.  The default value for this parameter is enabled when
          the router's Opaque capability is enabled.  This parameter may
          not be enabled if the router's Opaque capability is disabled.
          The state of this parameter is reflected by setting (or reset-
          ting) the O-bit in the option field as appropriate for all OSPF
          packets sent out this interface.

     4.2 Additions To The OSPF Neighbor Structure


     The OSPF neighbor structure is defined in Section 10 of [OSPF].  In an
     opaque-capable router, the following items are added to the OSPF
     neighbor structure:

          o Neighbor Options. This field was already defined in the OSPF
          specification. However, in opaque-capable routers there is a new



Coltun                                                             [Page 8]


Internet-Draft                    Opaque                      November 1996


          option which indicates the neighbor's Opaque capability. This new
          option is learned in the Database Exchange process through recep-
          tion of the neighbor's Database Description packets, and deter-
          mines whether Opaque LSAs are flooded to the neighbor. For a more
          detailed explanation of the flooding of the Opaque LSA see 3 of
          this document.




     5.0 References



         [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft,
                Cascade, September 1996.

         [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
                 Inc., March 1994.

         [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
                RainbowBridge Communications, Stanford University, March 1994.

         [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
                Cascade, April 1995.

         [EAL] Ferguson, D., "The OSPF External Attributes LSA", work in
               progress.























Coltun                                                             [Page 9]


Internet-Draft                    Opaque                      November 1996


     Appendix A: OSPF Data formats


     This appendix describes the format of the Options Field followed by
     the packet format of the Opaque LSA.


     A.1 The Options Field

     The OSPF Options field is present in OSPF Hello packets, Database
     Description packets and all link-state advertisements.  The Options
     field enables OSPF routers to support (or not support) optional capa-
     bilities, and to communicate their capability level to other OSPF
     routers. Through this mechanism routers of differing capabilities can
     be mixed within an OSPF routing domain.

     When used in Hello packets, the Options field allows a router to
     reject a neighbor because of a capability mismatch.  Alternatively,
     when capabilities are exchanged in Database Description packets a
     router can choose not to forward certain link-state advertisements to
     a neighbor because of its reduced functionality.  Lastly, listing
     capabilities in link-state advertisements allows routers to forward
     traffic around reduced functionality routers, by excluding them from
     parts of the routing table calculation.

     Seven bits of the OSPF Options field have been assigned, although only
     the O-bit is described completely by this memo.  Each bit is described
     briefly below. Routers should reset (i.e.  clear) unrecognized bits in
     the Options field when sending Hello packets or Database Description
     packets and when originating link-state advertisements. Conversely,
     routers encountering unrecognized Option bits in received Hello Pack-
     ets, Database Description packets or link-state advertisements should
     ignore the capability and process the packet/advertisement normally.



                    +------------------------------------+
                    | * | O | DC | EA | N/P | MC | E | T |
                    +------------------------------------+

                          The Options Field


     T-bit
          This bit describes the router's TOS-based routing capability, as
          specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of [OSPF].

     E-bit



Coltun                                                            [Page 10]


Internet-Draft                    Opaque                      November 1996


          This bit describes the way AS-external-LSAs are flooded, as
          described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].

     MC-bit
          This bit describes whether IP multicast datagrams are forwarded
          according to the specifications in [MOSPF].

     N/P-bit
          This bit describes the handling of Type-7 LSAs, as specified in
          [NSSA].

     DC-bit
          This bit describes the router's handling of demand circuits, as
          specified in [DEMD].

     EA-bit
          This bit describes the router's willingness to receive and for-
          ward External-Attributes-LSAs, as specified in [EAL].


     O-bit
          This bit describes the router's willingness to receive and for-
          ward Opaque-LSAs as specified in this document.




























Coltun                                                            [Page 11]


Internet-Draft                    Opaque                      November 1996


     A.2 Opaque LSA

     Opaque LSAs are the Type 15 link-state advertisements. These adver-
     tisements are originated by any router and may be used directly by
     OSPF or indirectly by other protocols such as BGP wishing to distri-
     bute information throughout the OSPF domain.  The primary function of
     the Opaque LSA is to provide for future extensibility to OSPF.

     The data contained in the Opaque LSA consists of some number of octets
     padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses
     the link-state database distribution mechanism for flooding this
     information throughout the topology.  However, the Opaque LSA has a
     Flooding Scope associated with it so that the scope of flooding may be
     link-local, area-local or the entire OSPF routing domain.

     Origination of Opaque LSAs are unique to the application using it.
     Section 3 of this document describes the flooding procedures for the
     Opaque LSA.


        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            LS age             |     Options   |     15        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Opaque Type  |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Flooding Scope          |          Reserved             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                      Opaque Information                       |
       +                                                               +
       |                              ...                              |



     Syntax Of The Opaque LSA's Link-State ID

          The link-state ID of the Opaque LSA is divided into an Opaque
          Type field (the first 8 bits) and an Opaque ID (the remaining 24
          bits).  Opaque type values in the 128-255 range are reserved for



Coltun                                                            [Page 12]


Internet-Draft                    Opaque                      November 1996


          private and experimental use.


     Flooding Scope

          The flooding Scope identifies the range of the topology to which
          this LSA may be distributed to. The following denotes the possi-
          ble values of the Flooding Scope field.

          o A value of 0 denotes a link-local scope. Opaque LSAs with a
          Flooding Scope of 0 are not flooded beyond the local
          (sub)network.

          o A value of 1 denotes an area-local scope. Opaque LSAs with a
          flooding scope of 1 are not flooded beyond the area that they are
          originated into.

          o A value of 2 denotes that the LSA is flooded throughout the
          Autonomous System (e.g., has the same scope as type-5 LSAs).
































Coltun                                                            [Page 13]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/