rfc1793.txt

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

      For OSPF broadcast and NBMA networks that have been configured as
      demand circuits, there are no changes to the Interface State
      Machine.

   3.2.  Sending and Receiving OSPF Hellos

      The following sections describe the required modifications to OSPF
      Hello Packet processing on point-to-point demand circuits.

      For OSPF broadcast and NBMA networks that have been configured as
      demand circuits, there is no change to the sending and receiving
      of Hellos, nor are there any changes to the Neighbor State
      Machine. This is because the proper operation of the Designated
      Router election algorithm requires periodic exchange of Hello
      Packets.

      3.2.1.  Negotiating Hello suppression

         On point-to-point demand circuits, both endpoints must agree to
         suppress the sending of Hello Packets.  To ensure this
         agreement, a router sets the DC-bit in OSPF Hellos and Database
         Description Packets sent out the demand interface.  Receiving
         an Hello or a Database Description Packet with the DC-bit set
         indicates agreement. Receiving an Hello with the DC-bit clear
         and also listing the router's Router ID in the body of the
         Hello message, or a Database Description Packet with the DC-bit
         clear (either one indicating bidirectional connectivity)
         indicates that the other end refuses to suppress Hellos. In
         these latter cases, the router reverts to the normal periodic
         sending of Hello Packets out the interface (see Section 9.5 of
         [1]).

         A demand point-to-point circuit need be configured in only one
         of the two endpoints (see Section 4.1).  If a router
         implementing Sections 2 and 3 of this memo receives an Hello
         Packet with the DC-bit set, it should treat the point-to-point
         link as a demand circuit, making the appropriate changes to its
         Hello Processing (see Section 3.2.2) and flooding (see Section
         3.3).

         Even if the above negotiation fails, the router should continue
         setting the DC-bit in its Hellos and Database Descriptions (the
         neighbor will just ignore the bit). The router will then
         automatically attempt to renegotiate Hello suppression whenever
         the link goes down and comes back up.  For example, if the
         neighboring router is rebooted with software that is capable of
         operating over demand circuits (i.e., implements Sections 2 and
         3 of this memo), a future negotiation will succeed.



Moy                                                            [Page 11]

RFC 1793               OSPF over Demand Circuits              April 1995


         Also, even if the negotiation to suppress Hellos fails, the
         flooding modifications described in Section 3.3 are still
         performed over the link.

      3.2.2.  Neighbor state machine modifications

         When the above negotiation succeeds, Hello Packets are sent
         over point-to-point demand circuits only until initial link-
         state database synchronization is achieved with the neighbor
         (i.e., the state of the neighbor connection reaches "Full", as
         defined in Section 10.1 of [1]). After this, Hellos are
         suppressed and the data-link connection to the neighbor is
         assumed available until evidence is received to the contrary.
         When the router finds that the neighbor is no longer available,
         presumably from something like a discouraging diagnostic code
         contained in a response to a failed call request, the neighbor
         connection transitions back to "Down" and Hellos are sent
         periodically (at Intervals of PollInterval) in an attempt to
         restart synchronization with the neighbor.

         This requires changes to the OSPF Neighbor State Machine (see
         Section 10.3 of [1]). The receipt of Hellos from demand circuit
         neighbors in state "Loading" or "Full" can no longer be
         required. In other words, the InactivityTimer event defined in
         Section 10.2 of [1] has no effect on demand circuit neighbors
         in state "Loading" or "Full".  An additional clarification is
         needed in the Neighbor State Machine's LLDown event. For demand
         circuits, this event should be mapped into the "discouraging
         diagnostic code" discussed previously in Section 1, and should
         not be generated when the data-link connection has been closed
         simply to save resources. Nor should LLDown be generated if a
         data-link connection fails due to temporary lack of resources.

   3.3.  Flooding over demand circuits

      Flooding over demand circuits (point-to-point or otherwise) is
      modified if and only if all routers have indicated that they can
      process LSAs having DoNotAge set. This is determined by examining
      the link state database of the OSPF area containing the demand
      circuit.  All LSAs in the database must have the DC-bit set.  If
      one or more LSAs have the DC-bit clear, flooding over demand
      circuits is unchanged from [1].  Otherwise, flooding is changed as
      follows.

        (1) Only truly changed LSAs are flooded over demand circuits.
            When a router receives a new LSA instance, it checks first
            to see whether the contents have changed. If not, the new
            LSA is simply a periodic refresh and it is not flooded out



Moy                                                            [Page 12]

RFC 1793               OSPF over Demand Circuits              April 1995


            attached demand circuits (it is still flooded out other
            interfaces however).  This check should be performed in Step
            5b of Section 13 in [1]. When comparing an LSA to its
            previous instance, the following are all considered to be
            changes in contents:

            o   The LSA's Options field has changed.

            o   One or both of the LSA instances has LS age set to
                MaxAge (or DoNotAge+MaxAge).

            o   The length field in the LSA header has changed.

            o   The contents of the LSA, excluding the 20-byte link
                state header, have changed. Note that this excludes
                changes in LS Sequence Number and LS Checksum.

        (2) When it has been decided to flood an LSA over a demand
            circuit, DoNotAge should be set in the copy of the LSA that
            is flooded out the demand interface. (There is one
            exception: DoNotAge should not be set if the LSA's LS age is
            equal to MaxAge.) Setting DoNotAge will cause the routers on
            the other side of the demand circuit to hold the LSA in
            their databases indefinitely, removing the need for periodic
            refresh. Note that it is perfectly possible that DoNotAge
            will already be set. This simply indicates that the LSA has
            already been flooded over demand circuits. In any case, the
            flooded copy's LS age field must also be incremented by
            InfTransDelay (see Step 5 of Section 13.3 in [1], and
            Section 2.2 of this memo), as protection against flooding
            loops.

            The previous paragraph also pertains to LSAs flooded over
            demand circuits in response to Link State Requests. It also
            pertains to LSAs that are retransmitted over demand
            circuits.

   3.4.  Virtual link support

      OSPF virtual links are essentially unnumbered point-to-point links
      (see Section 15 of [1]). Accordingly, demand circuit support for
      virtual links resembles that described for point-to-point links in
      the previous sections. The main difference is that a router
      implementing Sections 2 and 3 of this memo, and supporting virtual
      links, always treats virtual links as if they were demand
      circuits. Otherwise, when a virtual link's underlying physical
      path contains one or more demand circuits, periodic OSPF protocol
      exchanges over the virtual link would unnecessarily keep the



Moy                                                            [Page 13]

RFC 1793               OSPF over Demand Circuits              April 1995


      underlying demand circuits open.

      Demand circuit support on virtual links can be summarized as
      follows:

        o   Instead of modifying the Interface state machine for virtual
            links as was done for point-to-point links in Section 3.1,
            the Interface state machine for virtual links remains
            unchanged. A virtual link is considered to be in state
            "Point-to-point" if an intra-area path (through the virtual
            link's transit area) exists to the other endpoint. Otherwise
            it is considered to be in state "Down". See Section 15 of
            [1] for more details.

        o   Virtual links are always treated as demand circuits. In
            particular, over virtual links a router always negotiates to
            suppress the sending of Hellos. See Sections 3.2.1 and 3.2.2
            for details.

        o   In the demand circuit support over virtual links, there is
            no "discouraging diagnostic code" as described in Section 1.
            Instead, the connection is considered to exist if and only
            if an intra-area path (through the virtual link's transit
            area) exists to the other endpoint. See Section 15 of [1]
            for more details.

        o   Since virtual links are always treated as demand circuits,
            flooding over virtual links always proceeds as in Section
            3.3.

   3.5.  Point-to-MultiPoint Interface support

      The OSPF Point-to-MultiPoint interface has recently been developed
      for use with non-mesh-connected network segments. A common example
      is a Frame Relay subnet where PVCs are provisioned between some
      pairs of routers, but not all pairs. In this case the Point-to-
      Multipoint interface represents the single physical interface to
      the Frame relay network, over which multiple point-to-point OSPF
      conversations (one on each PVC) are taking place. For more
      information on the Point-to-MultiPoint interface, see [8].

      Since an OSPF Point-to-MultiPoint interface essentially consists
      of multiple point-to-point links, demand circuit support on the
      Point-to-Multipoint interface strongly resembles demand circuit
      support for point-to-point links. However, since the Point-to-
      MultiPoint interface requires commonality of its component point-
      to-point links' configurations, there are some differences.




Moy                                                            [Page 14]

RFC 1793               OSPF over Demand Circuits              April 1995


      Demand circuit support on Point-to-Multipoint interfaces can be
      summarized as follows:

        o   Instead of modifying the Interface state machine for Point-
            to-Multipoint interfaces as was done for point-to-point
            links in Section 3.1, the Interface state machine for
            Point-to-Multipoint interfaces remains unchanged.

        o   When ospfIfDemand is set on a Point-to-MultiPoint interface,
            the router tries to negotiate Hello suppression separately
            on each of interface's component point-to-point links. This
            negotiation proceeds as in Section 3.2.1.  Negotiation may
            fail on some component point-to-point links, and succeed on
            others. This is acceptable. On those component links where
            the negotiation fails, Hellos will always be sent;
            otherwise, Hellos will cease to be sent when the Database
            Description process completes on the component link (see
            Section 3.2.2).

        o   Section 3.3 defines the demand circuit flooding behavior for
            all OSPF interface types. This includes Point-to-Multipoint
            interfaces.

4.  Examples

   This section gives three examples of the operation over demand
   circuits. The first example is probably the most common and certainly
   the most basic. It shows a single point-to-point demand circuit
   connecting two routers.  The second illustrates what happens when
   demand circuits and leased lines are used in parallel. The third
   explains what happens when a router has multiple demand circuits and
   cannot keep them all open (for resource reasons) at the same time.

   4.1.  Example 1: Sole connectivity through demand circuits

      Figure 1 shows a sample internetwork with a single demand circuit
      providing connectivity to the LAN containing Host H2.  Assume that
      all three routers (RTA, RTB and RTC) have implemented the
      functionality in Section 2 of this memo, and thus will be setting
      the DC-bit in their LSAs. Furthermore assume that Router RTB has
      been configured to treat the link to Router RTC as a demand
      circuit, but Router RTC has not been so configured. Finally assume
      that the LAN interface connecting Router RTA to Host H1 is
      initially down.

      The following sequence of events may then transpire, starting with
      Router RTB booting and bringing up its link to Router RTC:




Moy                                                            [Page 15]

RFC 1793               OSPF over Demand Circuits              April 1995


        Time T0: RTB negotiates Hello suppression

            Router RTB will start sending Hellos over the demand circuit