home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_j_p / draft-ietf-ospf-opaque-00.txt < prev    next >
Text File  |  1996-11-25  |  24KB  |  780 lines
  1.  
  2.  
  3. Internet-Draft                    Opaque                      November 1996
  4.  
  5.  
  6. Expiration Date: May 1997                                     FORE Systems
  7. File name: draft-ietf-ospf-opaque-00.txt
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18.  
  19.  
  20.                         The OSPF Opaque LSA Option
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.                                 Rob Coltun
  28.                                FORE Systems
  29.                               (301) 571-2521
  30.                              rcoltun@fore.com
  31.  
  32.  
  33.  
  34.  
  35.  
  36.  
  37.      Status Of This Memo
  38.  
  39.      This document is an Internet-Draft.  Internet-Drafts are working docu-
  40.      ments of the Internet Engineering Task Force (IETF), its areas, and
  41.      its working groups.  Note that other groups may also distribute work-
  42.      ing documents as Internet-Drafts.
  43.  
  44.      Internet-Drafts are draft documents valid for a maximum of six months
  45.      and may be updated, replaced, or obsoleted by other documents at any
  46.      time.  It is inappropriate to use Internet- Drafts as reference
  47.      material or to cite them other than as "work in progress".
  48.  
  49.      To learn the current status of any Internet-Draft, please check the
  50.      "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
  51.      Directories on ds.internic.net (US East Coast), nic.nordu.net
  52.      (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
  53.  
  54.  
  55.  
  56.  
  57. Coltun                                                             [Page 1]
  58.  
  59.  
  60.  
  61.  
  62.  
  63. Internet-Draft                    Opaque                      November 1996
  64.  
  65.  
  66.      Table Of Contents
  67.  
  68.           1.0 Abstract ................................................. 3
  69.  
  70.           2.0 Overview ................................................. 3
  71.  
  72.           2.1 Organization Of This Document ............................ 3
  73.  
  74.           2.2 Acknowledgments .......................................... 3
  75.  
  76.           3.0 The Opaque LSA ........................................... 4
  77.  
  78.           3.1 Flooding Opaque LSAs ..................................... 5
  79.  
  80.           3.2 Modifications To The Neighbor State Machine .............. 6
  81.  
  82.           4.0 Protocol Data Structures ................................. 8
  83.  
  84.           4.1 Additions To The OSPF Interface Structure ................ 8
  85.  
  86.           4.2 Additions To The OSPF Neighbor Structure ................. 8
  87.  
  88.           5.0 References ............................................... 9
  89.  
  90.           Appendix A: OSPF Data Formats ................................ 10
  91.  
  92.           A.1 The Options Field ........................................ 10
  93.  
  94.           A.2 Opaque LSA ............................................... 12
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Coltun                                                             [Page 2]
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Internet-Draft                    Opaque                      November 1996
  124.  
  125.  
  126.      1.0  Abstract
  127.  
  128.      This memo documents enhancements to the OSPF protocol to support a new
  129.      type of link-state advertisement (LSA) called the Opaque LSA.  The
  130.      Opaque LSA option defines a general mechanism to allow for future
  131.      extensibility of OSPF. The information contained in Opaque LSAs may be
  132.      used directly by OSPF or by other protocols.  Opaque LSAs contain some
  133.      number of octets padded to 32-bit alignment.  The standard OSPF link-
  134.      state database flooding mechanisms are use for distribution of Opaque
  135.      LSAs.  Opaque LSAs are flooded throughout all or some limited portion
  136.      of the OSPF topology.
  137.  
  138.      2.0  Overview
  139.  
  140.  
  141.      Over the last few years the OSPF routing protocol [OSPF] has been
  142.      widely deployed throughout the Internet.  As a result of this deploy-
  143.      ment and the evolution of networking technology, OSPF has been
  144.      extended to support many options; this evolution will obviously con-
  145.      tinue.
  146.  
  147.      This memo documents enhancements to the OSPF protocol to support a new
  148.      type of link-state advertisement (LSA) called the Opaque LSA which
  149.      defines an optional generalized mechanism to allow for future extensi-
  150.      bility of OSPF. The information contained in Opaque LSAs may be used
  151.      directly by OSPF or by other protocols.  For example, the OSPF LSA may
  152.      be used to distribute BGP AS Path information (as documented in The
  153.      OSPF External Attributes LSA [EAL]) which is then used by BGP route-
  154.      leaking mechanisms. The option may also be used to distribute IP QoS
  155.      information which may be used directly by an OSPF path computation.
  156.      The exact use of the Opaque LSA is beyond the scope of this draft.
  157.  
  158.      The data contained in the Opaque LSA is some number of 32-bit aligned
  159.      octets.  Like any other LSA, the Opaque LSA uses the link-state data-
  160.      base distribution mechanism for flooding this information throughout
  161.      the topology.  The Flooding Scope identifies the range of the topology
  162.      to which this LSA may be distributed to.
  163.  
  164.  
  165.      2.1  Organization Of This Document
  166.  
  167.      This document first defines the Opaque LSA followed by a description
  168.      of OSPF packet processing which includes modifications to the flooding
  169.      procedure and the neighbor state machine needed to support the Opaque
  170.      LSA.  Appendix A then gives the packet formats.
  171.  
  172.  
  173.      2.2 Acknowledgments
  174.  
  175.  
  176.  
  177. Coltun                                                             [Page 3]
  178.  
  179.  
  180.  
  181.  
  182.  
  183. Internet-Draft                    Opaque                      November 1996
  184.  
  185.  
  186.      The author would like to thank Dennis Ferguson, John Moy, Zhaohui
  187.      "Jeffrey" Zhang and the rest of the OSPF Working Group for the ideas
  188.      and support they have given to this project.
  189.  
  190.  
  191.  
  192.      3.0 The Opaque LSA
  193.  
  194.      Opaque LSAs are the Type 15 link-state advertisements.  These adver-
  195.      tisements are originated by any router.  The data contained in the
  196.      Opaque LSA consists of some number of octets aligned to a 32-bit boun-
  197.      dary.  Like any other LSA, the Opaque LSA uses the link-state database
  198.      distribution mechanism for flooding this information throughout the
  199.      topology.  The Flooding Scope field in the Opaque LSA identifies the
  200.      range of the topology to which this LSA may be distributed to.  This
  201.      section documents the flooding of Opaque LSAs.
  202.  
  203.      The following are possible values of the Flooding Scope field.
  204.  
  205.           o A value of 0 denotes a link-local scope. Opaque LSAs with a
  206.           Flooding Scope of 0 are not flooded beyond the local
  207.           (sub)network.
  208.  
  209.           o A value of 1 denotes an area-local scope. Opaque LSAs with a
  210.           flooding scope of 1 are not flooded beyond the area that they are
  211.           originated into.
  212.  
  213.           o A value of 2 denotes that the LSA is flooded throughout the
  214.           Autonomous System.
  215.  
  216.      Origination of Opaque LSAs are unique to the application using it.
  217.      The link-state ID of the Opaque LSA is divided into a type field (the
  218.      first 8 bits) a type-specific ID (the remaining 24 bits).  The packet
  219.      format of the Opaque LSA is given in Appendix A.
  220.  
  221.      The responsibility for proper handling of the Opaque LSA's Flooding
  222.      Scope field is placed on the sender of the LSA.  The receiver must
  223.      always store a valid received Opaque LSA in its link-state database.
  224.      Flooding scope effects both the building of the Database summary list
  225.      during the initial synchronization of the link-state database and the
  226.      flooding procedure.
  227.  
  228.      In order to make the use of the Opaque LSAs predictable, it is recom-
  229.      mended that all routers within the scope of use have the same Opaque
  230.      LSA capabilities. For example, if the Opaque LSA is to be used for
  231.      flooding Opaque information throughout a single area, all routers
  232.      within the area should support the Opaque option.
  233.  
  234.  
  235.  
  236.  
  237. Coltun                                                             [Page 4]
  238.  
  239.  
  240.  
  241.  
  242.  
  243. Internet-Draft                    Opaque                      November 1996
  244.  
  245.  
  246.      The following describes the modifications to these procedures that are
  247.      necessary to insure proper use of the Opaque LSA's Scoping Rules.
  248.  
  249.  
  250.      3.1  Flooding Opaque LSAs
  251.  
  252.      The flooding of Opaque LSAs must follow the rules of Flooding Scope as
  253.      specified in this section. The flooding mechanisms must suppress the
  254.      flooding of Opaque LSAs as described in the following.
  255.  
  256.  
  257.           o If the Flooding Scope is link-local and the interface that the
  258.           LSA was received on is not the same as the target interface
  259.           (e.g., the interface associated with a particular neighbor), the
  260.           Opaque LSA must not be flooded out that interface (or to that
  261.           neighbor).  An implementation should keep track of the IP inter-
  262.           face associated with each Opaque LSA having a link-local flooding
  263.           scope.
  264.  
  265.           o If the Flooding Scope is area-local and the area associated
  266.           with Opaque LSA is not the area associated with a particular
  267.           interface, the Opaque LSA must not be flooded out the interface.
  268.           An implementation should keep track of the OSPF area associated
  269.           with each Opaque LSA having an area-local flooding scope.
  270.  
  271.      When opaque-capable routers and non-opaque-capable OSPF routers are
  272.      mixed together in a routing domain, the Opaque LSAs are not flooded to
  273.      the non-opaque-capable routers. As a general design principle,
  274.      optional OSPF advertisements are only flooded to those routers that
  275.      understand them.
  276.  
  277.      An opaque-capable router learns of its neighbor's opaque capability at
  278.      the beginning of the "Database Exchange Process" (see Section 10.6 of
  279.      [OSPF], receiving Database Description packets from a neighbor in
  280.      state ExStart). A neighbor is opaque-capable if and only if it sets
  281.      the O-bit in the Options field of its Database Description packets.
  282.      Then, in the next step of the Database Exchange process, Opaque LSAs
  283.      are included in the Database summary list sent to the neighbor (see
  284.      Sections 3.2 below and 10.3 of [OSPF]) if and only if the neighbor is
  285.      opaque-capable.
  286.  
  287.      When flooding Opaque-LSAs to adjacent neighbors, a opaque-capable
  288.      router looks at the neighbor's opaque capability.  Opaque LSAs are
  289.      only flooded to opaque capable neighbors. To be more precise, in Sec-
  290.      tion 13.3 of [OSPF], Opaque LSAs are only placed on the link-state
  291.      retransmission lists of opaque-capable neighbors.  Note however that
  292.      when sending Link State Update packets as multicasts, a non-opaque-
  293.      capable neighbor may (inadvertently) receive Opaque LSAs. The non-
  294.  
  295.  
  296.  
  297. Coltun                                                             [Page 5]
  298.  
  299.  
  300.  
  301.  
  302.  
  303. Internet-Draft                    Opaque                      November 1996
  304.  
  305.  
  306.      opaque-capable router will then simply discard the LSA (see Section 13
  307.      of [OSPF], receiving LSAs having unknown LS types).
  308.  
  309.  
  310.      3.2 Modifications To The Neighbor State Machine
  311.  
  312.      The state machine as it exists in section 10.3 of [OSPF] remains
  313.      unchanged except for the action associated with State: ExStart, Event:
  314.      NegotiationDone which is where the Database summary list is built.  To
  315.      incorporate the Opaque LSA in OSPF the action is changed to the fol-
  316.      lowing.
  317.  
  318.       State(s):  ExStart
  319.  
  320.          Event:  NegotiationDone
  321.  
  322.      New state:  Exchange
  323.  
  324.         Action:  The router must list the contents of its entire area
  325.                  link-state database in the neighbor Database summary
  326.                  list.  The area link-state database consists of the
  327.                  Router LSAs, Network LSAs and Summary LSAs
  328.                  contained in the area structure, along with Opaque and
  329.                  AS External LSAs contained in the global structure.
  330.                  AS External LSAs are omitted from a
  331.                  virtual neighbor's Database summary list.  AS
  332.                  External LSAs are omitted from the Database
  333.                  summary list if the area has been configured
  334.                  as a stub (see Section 3.6 of [OSPF]).
  335.  
  336.                  Opaque LSAs are omitted from the Database
  337.                  summary list if the following conditions
  338.                  are met: 1) the Flooding Scope is link-local
  339.                  and the interface associated with the Opaque
  340.                  LSA (upon reception) does not equal the
  341.                  interface associated with the neighbor;
  342.                  2) the Flooding Scope is area-local and the
  343.                  area associated with Opaque LSA is not the
  344.                  area associated with the neighbor's interface.
  345.  
  346.                  Any advertisement whose age is equal to MaxAge is
  347.                  omitted from the Database summary list. It is
  348.                  instead added to the neighbor's link-state
  349.                  retransmission list.  A summary of the Database
  350.                  summary list will be sent to the neighbor in
  351.                  Database Description packets.  Each Database
  352.                  Description Packet has a DD sequence number, and is
  353.                  explicitly acknowledged.  Only one Database
  354.  
  355.  
  356.  
  357. Coltun                                                             [Page 6]
  358.  
  359.  
  360.  
  361.  
  362.  
  363. Internet-Draft                    Opaque                      November 1996
  364.  
  365.  
  366.                  Description Packet is allowed to be outstanding at
  367.                  any one time. For more detail on the sending and
  368.                  receiving of Database Description packets, see
  369.                  Sections 10.8 and 10.6 of [OSPF].
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402.  
  403.  
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417. Coltun                                                             [Page 7]
  418.  
  419.  
  420.  
  421.  
  422.  
  423. Internet-Draft                    Opaque                      November 1996
  424.  
  425.  
  426.      4.0  Protocol data structures
  427.  
  428.      The Opaque option is described herein in terms of its operation on
  429.      various protocol data structures. These data structures are included
  430.      for explanatory uses only, and are not intended to constrain an OSPF
  431.      implementation. Besides the data structures listed below, this specif-
  432.      ication will also reference the various data structures (e.g., OSPF
  433.      interfaces and neighbors) defined in [OSPF].
  434.  
  435.      In an OSPF router, the following item is added to the list of global
  436.      OSPF data structures described in Section 5 of [OSPF]:
  437.  
  438.           o Opaque capability. Indicates whether the router is running the
  439.           Opaque option (i.e., capable of storing Opaque LSAs).  Such a
  440.           router will continue to inter-operate with non-opaque-capable
  441.           OSPF routers.
  442.  
  443.      4.1 Additions To The OSPF Interface Structure
  444.  
  445.      The OSPF interface structure is described in Section 9 of [OSPF]. In
  446.      an opaque-capable router, the following item is added to the OSPF
  447.      interface structure. Note that the Opaque capability parameter is
  448.      really a description of this router's view of the attached network.
  449.      As such, it should be configured identically on all routers attached
  450.      to a common network; otherwise incorrect or incomplete distribution of
  451.      Opaque LSAs may occur.
  452.  
  453.           o OpaqueInterfaceOn. This configurable parameter indicates
  454.           whether Opaque LSAs should be flooded over the attached network.
  455.           The parameter can assume a value of disabled or enabled.  When
  456.           set to disabled, Opaque LSAs will not be flooded out the inter-
  457.           face; when set to enabled Opaque LSAs will be flooded out the
  458.           interface.  The default value for this parameter is enabled when
  459.           the router's Opaque capability is enabled.  This parameter may
  460.           not be enabled if the router's Opaque capability is disabled.
  461.           The state of this parameter is reflected by setting (or reset-
  462.           ting) the O-bit in the option field as appropriate for all OSPF
  463.           packets sent out this interface.
  464.  
  465.      4.2 Additions To The OSPF Neighbor Structure
  466.  
  467.  
  468.      The OSPF neighbor structure is defined in Section 10 of [OSPF].  In an
  469.      opaque-capable router, the following items are added to the OSPF
  470.      neighbor structure:
  471.  
  472.           o Neighbor Options. This field was already defined in the OSPF
  473.           specification. However, in opaque-capable routers there is a new
  474.  
  475.  
  476.  
  477. Coltun                                                             [Page 8]
  478.  
  479.  
  480.  
  481.  
  482.  
  483. Internet-Draft                    Opaque                      November 1996
  484.  
  485.  
  486.           option which indicates the neighbor's Opaque capability. This new
  487.           option is learned in the Database Exchange process through recep-
  488.           tion of the neighbor's Database Description packets, and deter-
  489.           mines whether Opaque LSAs are flooded to the neighbor. For a more
  490.           detailed explanation of the flooding of the Opaque LSA see 3 of
  491.           this document.
  492.  
  493.  
  494.  
  495.  
  496.      5.0 References
  497.  
  498.  
  499.  
  500.          [OSPF] Moy, J., "OSPF Version 2", IETF Internet Draft,
  501.                 Cascade, September 1996.
  502.  
  503.          [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
  504.                  Inc., March 1994.
  505.  
  506.          [NSSA] Coltun, R. and V. Fuller, "The OSPF NSSA Option", RFC 1587,
  507.                 RainbowBridge Communications, Stanford University, March 1994.
  508.  
  509.          [DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793,
  510.                 Cascade, April 1995.
  511.  
  512.          [EAL] Ferguson, D., "The OSPF External Attributes LSA", work in
  513.                progress.
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537. Coltun                                                             [Page 9]
  538.  
  539.  
  540.  
  541.  
  542.  
  543. Internet-Draft                    Opaque                      November 1996
  544.  
  545.  
  546.      Appendix A: OSPF Data formats
  547.  
  548.  
  549.      This appendix describes the format of the Options Field followed by
  550.      the packet format of the Opaque LSA.
  551.  
  552.  
  553.      A.1 The Options Field
  554.  
  555.      The OSPF Options field is present in OSPF Hello packets, Database
  556.      Description packets and all link-state advertisements.  The Options
  557.      field enables OSPF routers to support (or not support) optional capa-
  558.      bilities, and to communicate their capability level to other OSPF
  559.      routers. Through this mechanism routers of differing capabilities can
  560.      be mixed within an OSPF routing domain.
  561.  
  562.      When used in Hello packets, the Options field allows a router to
  563.      reject a neighbor because of a capability mismatch.  Alternatively,
  564.      when capabilities are exchanged in Database Description packets a
  565.      router can choose not to forward certain link-state advertisements to
  566.      a neighbor because of its reduced functionality.  Lastly, listing
  567.      capabilities in link-state advertisements allows routers to forward
  568.      traffic around reduced functionality routers, by excluding them from
  569.      parts of the routing table calculation.
  570.  
  571.      Seven bits of the OSPF Options field have been assigned, although only
  572.      the O-bit is described completely by this memo.  Each bit is described
  573.      briefly below. Routers should reset (i.e.  clear) unrecognized bits in
  574.      the Options field when sending Hello packets or Database Description
  575.      packets and when originating link-state advertisements. Conversely,
  576.      routers encountering unrecognized Option bits in received Hello Pack-
  577.      ets, Database Description packets or link-state advertisements should
  578.      ignore the capability and process the packet/advertisement normally.
  579.  
  580.  
  581.  
  582.                     +------------------------------------+
  583.                     | * | O | DC | EA | N/P | MC | E | T |
  584.                     +------------------------------------+
  585.  
  586.                           The Options Field
  587.  
  588.  
  589.      T-bit
  590.           This bit describes the router's TOS-based routing capability, as
  591.           specified in Sections 9.5, 10.8, 12.1.2 and 16.9 of [OSPF].
  592.  
  593.      E-bit
  594.  
  595.  
  596.  
  597. Coltun                                                            [Page 10]
  598.  
  599.  
  600.  
  601.  
  602.  
  603. Internet-Draft                    Opaque                      November 1996
  604.  
  605.  
  606.           This bit describes the way AS-external-LSAs are flooded, as
  607.           described in Sections 3.6, 9.5, 10.8 and 12.1.2 of [OSPF].
  608.  
  609.      MC-bit
  610.           This bit describes whether IP multicast datagrams are forwarded
  611.           according to the specifications in [MOSPF].
  612.  
  613.      N/P-bit
  614.           This bit describes the handling of Type-7 LSAs, as specified in
  615.           [NSSA].
  616.  
  617.      DC-bit
  618.           This bit describes the router's handling of demand circuits, as
  619.           specified in [DEMD].
  620.  
  621.      EA-bit
  622.           This bit describes the router's willingness to receive and for-
  623.           ward External-Attributes-LSAs, as specified in [EAL].
  624.  
  625.  
  626.      O-bit
  627.           This bit describes the router's willingness to receive and for-
  628.           ward Opaque-LSAs as specified in this document.
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657. Coltun                                                            [Page 11]
  658.  
  659.  
  660.  
  661.  
  662.  
  663. Internet-Draft                    Opaque                      November 1996
  664.  
  665.  
  666.      A.2 Opaque LSA
  667.  
  668.      Opaque LSAs are the Type 15 link-state advertisements. These adver-
  669.      tisements are originated by any router and may be used directly by
  670.      OSPF or indirectly by other protocols such as BGP wishing to distri-
  671.      bute information throughout the OSPF domain.  The primary function of
  672.      the Opaque LSA is to provide for future extensibility to OSPF.
  673.  
  674.      The data contained in the Opaque LSA consists of some number of octets
  675.      padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses
  676.      the link-state database distribution mechanism for flooding this
  677.      information throughout the topology.  However, the Opaque LSA has a
  678.      Flooding Scope associated with it so that the scope of flooding may be
  679.      link-local, area-local or the entire OSPF routing domain.
  680.  
  681.      Origination of Opaque LSAs are unique to the application using it.
  682.      Section 3 of this document describes the flooding procedures for the
  683.      Opaque LSA.
  684.  
  685.  
  686.         0                   1                   2                   3
  687.         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
  688.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  689.        |            LS age             |     Options   |     15        |
  690.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  691.        |  Opaque Type  |               Opaque ID                       |
  692.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  693.        |                      Advertising Router                       |
  694.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  695.        |                      LS Sequence Number                       |
  696.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  697.        |         LS checksum           |           Length              |
  698.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  699.        |       Flooding Scope          |          Reserved             |
  700.        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  701.        |                                                               |
  702.        +                                                               +
  703.        |                      Opaque Information                       |
  704.        +                                                               +
  705.        |                              ...                              |
  706.  
  707.  
  708.  
  709.      Syntax Of The Opaque LSA's Link-State ID
  710.  
  711.           The link-state ID of the Opaque LSA is divided into an Opaque
  712.           Type field (the first 8 bits) and an Opaque ID (the remaining 24
  713.           bits).  Opaque type values in the 128-255 range are reserved for
  714.  
  715.  
  716.  
  717. Coltun                                                            [Page 12]
  718.  
  719.  
  720.  
  721.  
  722.  
  723. Internet-Draft                    Opaque                      November 1996
  724.  
  725.  
  726.           private and experimental use.
  727.  
  728.  
  729.      Flooding Scope
  730.  
  731.           The flooding Scope identifies the range of the topology to which
  732.           this LSA may be distributed to. The following denotes the possi-
  733.           ble values of the Flooding Scope field.
  734.  
  735.           o A value of 0 denotes a link-local scope. Opaque LSAs with a
  736.           Flooding Scope of 0 are not flooded beyond the local
  737.           (sub)network.
  738.  
  739.           o A value of 1 denotes an area-local scope. Opaque LSAs with a
  740.           flooding scope of 1 are not flooded beyond the area that they are
  741.           originated into.
  742.  
  743.           o A value of 2 denotes that the LSA is flooded throughout the
  744.           Autonomous System (e.g., has the same scope as type-5 LSAs).
  745.  
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777. Coltun                                                            [Page 13]
  778.  
  779.  
  780.