[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                           May 1998


Expiration Date: November 1998                                FORE Systems
File name: draft-ietf-ospf-opaque-05.txt












                        The OSPF Opaque LSA Option






                                Rob Coltun
                               FORE Systems
                              (703) 245-4543
                             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                           May 1998


     Table Of Contents

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

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

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

          2.2 Acknowledgments .......................................... 4

          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 Neighbor Structure ................. 8

          5.0 Management Considerations ................................ 8

          6.0 Security Considerations .................................. 10

          7.0 References ............................................... 12

          Appendix A: OSPF Data Formats ................................ 13

          A.1 The Options Field ........................................ 13

          A.2 Opaque LSA ............................................... 15




















Coltun                                                             [Page 2]


Internet-Draft                    Opaque                           May 1998


     1.0  Abstract

     This memo defines enhancements to the OSPF protocol to support a new
     class of link-state advertisements (LSA) called Opaque LSAs.  Opaque
     LSAs provide a generalized mechanism to allow for the future extensi-
     bility of OSPF. Opaque LSAs consist of a standard LSA header followed
     by application-specific information.  The information field may be
     used directly by OSPF or by other applications.  Standard OSPF link-
     state database flooding mechanisms are used to distribute Opaque LSAs
     to all or some limited portion of the OSPF topology.

     2.0  Overview


     Over the last several 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 defines enhancements to the OSPF protocol to support a new
     class of link-state advertisements (LSA) called Opaque LSAs.  Opaque
     LSAs provide a generalized mechanism to allow for the future extensi-
     bility of OSPF. The information contained in Opaque LSAs may be used
     directly by OSPF or indirectly by some application wishing to distri-
     bute information throughout the OSPF domain.  For example, the OSPF
     LSA may be used by routers to distribute IP to link-layer address
     resolution information (see [ARA] for more information).  The exact
     use of Opaque LSAs is beyond the scope of this draft.

     Opaque LSAs consist of a standard LSA header followed by a 32-bit
     aligned application-specific information field.  Like any other LSA,
     the Opaque LSA uses the link-state database distribution mechanism for
     flooding this information throughout the topology.  The link-state
     type field of the Opaque LSA identifies the LSA's range of topological
     distribution. This range is referred to as the Flooding Scope.

     It is envisioned that an implementation of the Opaque option provides
     an application interface for 1) encapsulating application-specific
     information in a specific Opaque type, 2) sending and receiving
     application-specific information, and 3) if required, informing the
     application of the change in validity of previously received informa-
     tion when topological changes are detected.


     2.1  Organization Of This Document

     This document first defines the three types of Opaque LSAs followed by



Coltun                                                             [Page 3]


Internet-Draft                    Opaque                           May 1998


     a description of OSPF packet processing. The packet processing sec-
     tions include modifications to the flooding procedure and to the
     neighbor state machine. Appendix A then gives the packet formats.


     2.2 Acknowledgments

     The author would like to thank Dennis Ferguson, Acee Lindem, John Moy,
     Sandra Murphy, Man-Kit Yeung, 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 types 9, 10 and 11 link-state advertisements.  Opaque
     LSAs consist of a standard LSA header followed by a 32-bit aligned
     application-specific information field.  Standard link-state database
     flooding mechanisms are used for distribution of Opaque LSAs.  The
     range of topological distribution (i.e., the flooding scope) of an
     Opaque LSA is identified by its link-state type.  This section docu-
     ments the flooding of Opaque LSAs.

     The flooding scope associated with each Opaque link-state type is
     defined as follows.

          o Link-state type 9 denotes a link-local scope. Type-9 Opaque
          LSAs are not flooded beyond the local (sub)network.

          o Link-state type 10 denotes an area-local scope. Type-10 Opaque
          LSAs are not flooded beyond the borders of their associated area.

          o Link-state type 11 denotes that the LSA is flooded throughout
          the Autonomous System (AS). The flooding scope of type-11 LSAs
          are equivalent to the flooding scope of AS-external (type-5)
          LSAs.  Specifically type-11 Opaque LSAs are 1) flooded throughout
          all transit areas, 2) not flooded into stub areas from the back-
          bone and 3) not originated by routers into their connected stub
          areas.  As with type-5 LSAs, if a type-11 Opaque LSA is received
          in a stub area from a neighboring router within the stub area the
          LSA is rejected.

     The link-state ID of the Opaque LSA is divided into an Opaque type
     field (the first 8 bits) and a type-specific ID (the remaining 24
     bits).  Opaque type values in the range of 0-127 are reserved for
     definition by the IANA (iana@ISI.EDU) whereas Opaque type values in
     the range of 128-255 are reserved for private and experimental use.



Coltun                                                             [Page 4]


Internet-Draft                    Opaque                           May 1998


     The packet format of the Opaque LSA is given in Appendix A.

     The responsibility for proper handling of the Opaque LSA's flooding
     scope is placed on both the sender and receiver of the LSA.  The
     receiver must always store a valid received Opaque LSA in its link-
     state database.  The receiver must not accept Opaque LSAs that violate
     the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA is not
     accepted in a stub area).  The flooding scope effects both the build-
     ing of the Database Summary List during the initial synchronization of
     the link-state database and the flooding procedure.

     The following describes the modifications to these procedures that are
     necessary to insure conformance to 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.  Section 13 of [OSPF] describes the OSPF
     flooding procedure.  The following describes the Opaque LSA's type-
     specific flooding restrictions.


          o If the Opaque LSA is type 9 (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 par-
          ticular target neighbor), the Opaque LSA must not be flooded out
          that interface (or to that neighbor).  An implementation should
          keep track of the IP interface associated with each Opaque LSA
          having a link-local flooding scope.

          o If the Opaque LSA is type 10 (the flooding scope is area-local)
          and the area associated with Opaque LSA (upon reception) is not
          the same as the area associated with the target interface, the
          Opaque LSA must not be flooded out the interface.  An implementa-
          tion should keep track of the OSPF area associated with each
          Opaque LSA having an area-local flooding scope.

          o If the Opaque LSA is type 11 (the LSA is flooded throughout the
          AS) and the target interface is associated with a stub area the
          Opaque LSA must not be flooded out the interface.  A type-11
          Opaque LSA that is received on an interface associated with a
          stub area must be discarded and not acknowledged (the neighboring
          router has flooded the LSA in error).

     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,



Coltun                                                             [Page 5]


Internet-Draft                    Opaque                           May 1998


     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;
     the O-bit is not set in packets other than Database Description pack-
     ets.  Then, in the next step of the Database Exchange process, Opaque
     LSAs are included in the Database summary list that is 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.  However, when send-
     ing Link State Update packets as multicasts, a non-opaque-capable
     neighbor may (inadvertently) receive Opaque LSAs. The non-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 this 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, Summary LSAs and types 9
                 and 10 Opaque LSAs contained in the area structure,
                 along with AS External and type-11 Opaque LSAs
                 contained in the global structure. AS External and
                 type-11 Opaque LSAs are omitted from a virtual
                 neighbor's Database summary list. AS External LSAs



Coltun                                                             [Page 6]


Internet-Draft                    Opaque                           May 1998


                 and type-11 Opaque LSAs are omitted from the
                 Database summary list if the area has been
                 configured as a stub area (see Section 3.6 of [OSPF]).

                 Type-9 Opaque LSAs are omitted from the Database
                 summary list if the interface associated with the
                 neighbor is not the interface associated with the
                 Opaque LSA (as noted upon reception).

                 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
                 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.6 and 10.8 of [OSPF].






























Coltun                                                             [Page 7]


Internet-Draft                    Opaque                           May 1998


     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 imple-
     mentation. In addition to the data structures listed below, this
     specification references the various data structures (e.g., OSPF
     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 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
          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 sec-
          tion 3 of this document.


     5.0 Management Considerations


     This section identifies the current OSPF MIB [OSPFMIB] capabilities
     that are applicable to the Opaque option and lists the additional
     management information which is required for its support.

     Opaque LSAs are types 9, 10 and 11 link-state advertisements.  The
     link-state ID of the Opaque LSA is divided into an Opaque type field
     (the first 8 bits) and a type-specific ID (the remaining 24 bits).
     The packet format of the Opaque LSA is given in Appendix A.  The range
     of topological distribution (i.e., the flooding scope) of an Opaque
     LSA is identified by its link-state type.




Coltun                                                             [Page 8]


Internet-Draft                    Opaque                           May 1998


          o Link-State type 9 Opaque LSAs have a link-local scope. Type-9
          Opaque LSAs are flooded on a single local (sub)network but are
          not flooded beyond the local (sub)network.

          o Link-state type 10 Opaque LSAs have an area-local scope. Type-
          10 Opaque LSAs are flooded throughout a single area but are not
          flooded beyond the borders of the associated area.

          o Link-state type 11 Opaque LSAs have an Autonomous-System-wide
          scope.  The flooding scope of type-11 LSAs are equivalent to the
          flooding scope of AS-external (type-5) LSAs.

     The OSPF MIB provides a number of objects that can be used to manage
     and monitor an OSPF router's Link-State Database.  The ones that are
     relevant to the Opaque option are as follows.

          The ospfGeneralGroup defines two objects for keeping track of
          newly originated and newly received LSAs (ospfOriginateNewLsas
          and ospfRxNewLsas respectively).

          The OSPF MIB defines a set of optional traps.  The ospfOrigina-
          teLsa trap signifies that a new LSA has been originated by a
          router and the ospfMaxAgeLsa trap signifies that one of the LSAs
          in the router's link-state database has aged to MaxAge.

          The ospfAreaTable describes the configured parameters and cumula-
          tive statistics of the router's attached areas. This table
          includes a count of the number of LSAs contained in the area's
          link-state database (ospfAreaLsaCount), and a sum of the LSA's LS
          checksums contained in this area (ospfAreaLsaCksumSum).  This sum
          can be used to determine if there has been a change in a router's
          link-state database, and to compare the link-state database of
          two routers.

          The ospfLsdbTable describes the OSPF Process's link-state data-
          base (excluding AS-external LSAs).  Entries in this table are
          indexed with an Area ID, a link-state type, a link-state ID and
          the originating router's Router ID.


     The management objects that are needed to support the Opaque option
     are as follows.

          An Opaque-option-enabled object is needed to indicate if the
          Opaque option is enabled on the router.

          The origination and reception of new Opaque LSAs should be
          reflected in the counters ospfOriginateNewLsas and ospfRxNewLsas



Coltun                                                             [Page 9]


Internet-Draft                    Opaque                           May 1998


          (inclusive for types 9, 10 and 11 Opaque LSAs).

          If the OSPF trap option is supported, the origination of new
          Opaque LSAs and purging of MaxAge Opaque LSAs should be reflected
          in the ospfOriginateLsa and ospfMaxAgeLsa traps (inclusive for
          types 9, 10 and 11 Opaque LSAs).

          The number of type-10 Opaque LSAs should be reflected in
          ospfAreaLsaCount; the checksums of type-10 Opaque LSAs should be
          included in ospfAreaLsaChksumSum.

          Type-10 Opaque LSAs should be included in the ospfLsdbTable.
          Note that this table does not include a method of examining the
          Opaque type field (in the Opaque option this is a sub-field of
          the link-state ID).

          Up until now, LSAs have not had a link-local scope so there is no
          method of requesting the number of, or examining the LSAs that
          are associated with a specific OSPF interface. A new group of
          management objects are required to support type-9 Opaque LSAs.
          These objects should include a count of type-9 Opaque LSAs, a
          checksum sum and a table for displaying the link-state database
          for type-9 Opaque LSAs on a per-interface basis.  Entries in this
          table should be indexed with an Area ID, interface's IP address,
          Opaque type, link-state ID and the originating router's Router
          ID.

          Prior to the introduction of type-11 Opaque LSAs, AS-External
          (type-5) LSAs have been the only link-state types which have an
          Autonomous-System-wide scope.  A new group of objects are
          required to support type-11 Opaque LSAs.  These objects should
          include a count of type-11 Opaque LSAs, a type-11 checksum sum
          and a table for displaying the type-11 link-state database.
          Entries in this table should be indexed with the Opaque type,
          link-state ID and the originating router's Router ID.  The type-
          11 link-state database table will allow type-11 LSAs to be
          displayed once for the router rather than once in each non-stub
          area.


     6.0 Security Considerations


     There are two types of issues that need be addressed when looking at
     protecting routing protocols from misconfigurations and malicious
     attacks.  The first is authentication and certification of routing
     protocol information.  The second is denial of service attacks result-
     ing from repetitive origination of the same router advertisement or



Coltun                                                            [Page 10]


Internet-Draft                    Opaque                           May 1998


     origination a large number of distinct advertisements resulting in
     database overflow.  Note that both of these concerns exist indepen-
     dently of a router's support for the Opaque option.

     To address the authentication concerns, OSPF protocol exchanges are
     authenticated.  OSPF supports multiple types of authentication; the
     type of authentication in use can be configured on a per network seg-
     ment basis. One of OSPF's authentication types, namely the Crypto-
     graphic authentication option, is believed to be secure against pas-
     sive attacks and provide significant protection against active
     attacks. When using the Cryptographic authentication option, each
     router appends a "message digest" to its transmitted OSPF packets.
     Receivers then use the shared secret key and received digest to verify
     that each received OSPF packet is authentic.

     The quality of the security provided by the Cryptographic authentica-
     tion option depends completely on the strength of the message digest
     algorithm (MD5 is currently the only message digest algorithm speci-
     fied), the strength of the key being used, and the correct implementa-
     tion of the security mechanism in all communicating OSPF implementa-
     tions. It also requires that all parties maintain the secrecy of the
     shared secret key.  None of the standard OSPF authentication types
     provide confidentiality. Nor do they protect against traffic analysis.
     For more information on the standard OSPF security mechanisms, see
     Sections 8.1, 8.2, and Appendix D of [OSPF].

     [DIGI] describes the extensions to OSPF required to add digital signa-
     ture authentication to Link State data and to provide a certification
     mechanism for router data.  [DIGI] also describes the added LSA pro-
     cessing and key management as well as a method for migration from, or
     co-existence with, standard OSPF V2.

     Repetitive origination of advertisements are addressed by OSPF by man-
     dating a limit on the frequency that new instances of any particular
     LSA can be originated and accepted during the flooding procedure.  The
     frequency at which new LSA instances may be originated is set equal to
     once every MinLSInterval seconds, whose value is 5 seconds (see Sec-
     tion 12.4 of [OSPF]).  The frequency at which new LSA instances are
     accepted during flooding is once every MinLSArrival seconds, whose
     value is set to 1 (see Section 13, Appendix B and G.5 of [OSPF]).

     Proper operation of the OSPF protocol requires that all OSPF routers
     maintain an identical copy of the OSPF link-state database.  However,
     when the size of the link-state database becomes very large, some
     routers may be unable to keep the entire database due to resource
     shortages; we term this "database overflow".  When database overflow
     is anticipated, the routers with limited resources can be accommodated
     by configuring OSPF stub areas and NSSAs.  [OVERFLOW] details a way of



Coltun                                                            [Page 11]


Internet-Draft                    Opaque                           May 1998


     gracefully handling unanticipated database overflows.




     7.0 References


         [ARA] Coltun, R., Heinanen, J., "The OSPF Address Resolution
         Advertisement Option", work in progress.

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

         [DIGI] S. Murphy, M. Badger, B. Wellington, "OSPF with Digital Signatures",
         RFC 2154, Trusted Information Systems, June 1997.

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

         [NSSA] Coltun, R., Fuller, V., "The OSPF NSSA Option", RFC 1587,
         March 1994.

         [OSPF] Moy, J., "OSPF Version 2", RFC 2328, Cascade, April 1998.

         [OSPFMIB] F. Baker, R. Coltun, "OSPF Version 2 Management Information
         Base", RFC 1850, November 1995.

         [OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765,
         Cascade, March 1995.





















Coltun                                                            [Page 12]


Internet-Draft                    Opaque                           May 1998


     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.

     Six 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 | * |
                    +------------------------------------+

                              The Options Field


     E-bit
          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



Coltun                                                            [Page 13]


Internet-Draft                    Opaque                           May 1998


          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 14]


Internet-Draft                    Opaque                           May 1998


     A.2 Opaque LSA

     Opaque LSAs are Type 9, 10 and 11 link-state advertisements.  These
     advertisements may be used directly by OSPF or indirectly by some
     application wishing to distribute information throughout the OSPF
     domain.  The function of the Opaque LSA option is to provide for
     future extensibility of OSPF.

     Opaque LSAs contain some number of octets (of application-specific
     data) 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 (type 9), area-local (type 10) or the entire OSPF routing
     domain (type 11).  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   |   9, 10 or 11 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Opaque Type  |               Opaque ID                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      Advertising Router                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      LS Sequence Number                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         LS checksum           |           Length              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       +                                                               +
       |                      Opaque Information                       |
       +                                                               +
       |                              ...                              |


     Link-State Type

          The link-state type of the Opaque LSA identifies the LSA's range
          of topological distribution. This range is referred to as the
          Flooding Scope.  The following explains the flooding scope of
          each of the link-state types.

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




Coltun                                                            [Page 15]


Internet-Draft                    Opaque                           May 1998


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

          o A value of 11 denotes that the LSA is flooded throughout the
          Autonomous System (e.g., has the same scope as type-5 LSAs).
          Opaque LSAs with AS-wide scope are not flooded into stub areas.



     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 range of 0-127 are reserved for
          definition by the IANA (iana@ISI.EDU) whereas Opaque type values
          in the range of 128-255 are reserved for private and experimental
          use.

































Coltun                                                            [Page 16]


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