rfc2370.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                          R. Coltun
Request for Comments: 2370                                  FORE Systems
See Also: 2328                                                 July 1998
Category: Standards Track


                       The OSPF Opaque LSA Option

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table Of Contents

   1.0 Abstract .................................................  1
   2.0 Overview .................................................  2
   2.1 Organization Of This Document ............................  2
   2.2 Acknowledgments ..........................................  3
   3.0 The Opaque LSA ...........................................  3
   3.1 Flooding Opaque LSAs .....................................  4
   3.2 Modifications To The Neighbor State Machine ..............  5
   4.0 Protocol Data Structures .................................  6
   4.1 Additions To The OSPF Neighbor Structure .................  6
   5.0 Management Considerations ................................  7
   6.0 Security Considerations ..................................  9
   7.0 IANA Considerations ...................................... 10
   8.0 References ............................................... 10
   9.0 Author's Information ..................................... 11
   Appendix A: OSPF Data Formats ................................ 12
   A.1 The Options Field ........................................ 12
   A.2 The Opaque LSA ........................................... 13
   Appendix B: Full Copyright Statment .......................... 15

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
   extensibility of OSPF. Opaque LSAs consist of a standard LSA header
   followed by application-specific information.  The information field



Coltun                      Standards Track                     [Page 1]

RFC 2370               The OSPF Opaque LSA Option              July 1998


   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
   deployment and the evolution of networking technology, OSPF has been
   extended to support many options; this evolution will obviously
   continue.

   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
   extensibility of OSPF. The information contained in Opaque LSAs may
   be used directly by OSPF or indirectly by some application wishing to
   distribute 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 memo.

   Opaque LSAs consist of a standard LSA header followed by a 32-bit
   qaligned 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
   information when topological changes are detected.

2.1  Organization Of This Document

   This document first defines the three types of Opaque LSAs followed
   by a description of OSPF packet processing. The packet processing
   sections include modifications to the flooding procedure and to the
   neighbor state machine. Appendix A then gives the packet formats.








Coltun                      Standards Track                     [Page 2]

RFC 2370               The OSPF Opaque LSA Option              July 1998


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
   documents 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
       backbone 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).  The packet format of the Opaque LSA is given in Appendix A.
   Section 7.0 describes Opaque type allocation and assignment.

   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




Coltun                      Standards Track                     [Page 3]

RFC 2370               The OSPF Opaque LSA Option              July 1998


   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
       particular target neighbor), the Opaque LSA must not be flooded
       out that interface (or to that neighbor).  An implementation
       should keepk 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
       implementation 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,
   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



Coltun                      Standards Track                     [Page 4]

RFC 2370               The OSPF Opaque LSA Option              July 1998


   packets.  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
   Section 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 following.

     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 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).





Coltun                      Standards Track                     [Page 5]