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