rfc2174.txt

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

                enabled, go to (3).
          (2-2) If the FORWARD_DELAY_TIMER corresponding to the
                downstream port was already started, increment the
                timer. If the timer expires, mark the bit in the
                broadcast/multicast routing table corresponding to the
                port and stop the timer.
          (2-2) Otherwise, start the FORWARD_DELAY_TIMER.
      (3) Return to Step 1 to process the next entry.

    Step 2 - Process Unicast Routing Information

    First, add the cost associated with the link, usually 1, to the
    metric. If the result is greater than 16, 16 is used. Then, look up
    the unicast routing table for the corresponding entry. There are two
    cases.

     Case 1  no corresponding entry is found

       If the new metric is 16, return to step 1 to process the next
       entry.  Otherwise,
       (1) Create a new route entry in the routing table
       (2) Initialize EXPIRATION_TIMER and GC_TIMER




Murakami & Maruyama          Informational                     [Page 17]

RFC 2174                         MAPOS                         June 1997


       (3) The port corresponding to the new route is the next_hop port
           for the route. Thus, mark the bit in the broadcast/multicast
           routing table corresponding to the new next_hop port and
           start FORWARD_DELAY_TIMER. If this new route is for the
           switch with the minimum switch number, select it as the VSS
           and use its broadcast/multicast routing table. (See NOTE 1.)
       (4) Set the route change flag and invoke triggered update process
       (5) Return to step 1 to process the next entry.

           [NOTE 1]
             There are two implementations;
              (1) Prepare a spanning tree for each route and use
                  only one corresponding to the current VSS. In this
                  case, each unicast route entry has a broadcast/unicast
                  routing table.
              (2) Prepare only one spanning tree corresponding to the
                  current VSS. In this case, a switch has only one
                  broadcast/multicast routing table.
              In this document, the former is assumed.

      Case 2. A corresponding entry is found

       In this case, the update message is processed differently
       according to the new metric value.

       (a) new_metric < 16 & new_metric > current_metric

          (1)If and only if the update is from the same port(next_hop
             port) as the existing one,
            (1-1) Update the entry
            (1-2) Initialize EXPIRATION_TIMER and GC_TIMER

          (2) If the corresponding bit to the port, which the update
              message is received, is marked in the broadcast/multicast
              routing table, clear the bit.
          (3) Return to Step 1 and process the next entry.

       (b) new_metric < 16 & new_metric < current_metric

          (1) Update the entry and clear the bit in the
              broadcast/multicast routing table corresponding to the old
              next_hop port.
          (2) Initialize EXPIRATION_TIMER, GC_TIMER, and
              PORT_EXPIRATION_TIMER for the new next_hop port.
          (3) Mark a bit in the broadcast/multicast routing table
              corresponding to the new next_hop port and start
              FORWARD_DELAY_TIMER.




Murakami & Maruyama          Informational                     [Page 18]

RFC 2174                         MAPOS                         June 1997


          (4) Set the route change flag and invoke triggered update with
              poisoned reverse for the new next_hop.
          (5) Return to Step 1 to process the next entry.

       (c) new_metric < 16 & new_metric = current_metric

          If a new route with the same metric value as the existing
          routing table entry is received, use the old one as follows;

          (1) If the new next hop is equal to the current one,
              initialize EXPIRATION_TIMER and GC_TIMER. Otherwise,
              ignore this update.
          (2) If the bit corresponding to the port, from which the
              update message was received, is marked in the
              broadcast/multicast routing table, clear the bit.
          (3) Return to Step 1 to process the next entry.

       (d) the new metric = 16 & the new next hop = the current one

          If the current metric is not equal to 16, this is a new
          unreachable information. Then,
          (1) Update the entry and clear the bit in the
              broadcast/multicast routing table corresponding to the old
              next_hop port.
          (2) If this route is for the current VSS, select a new VSS in
              the valid routing table entries. Valid means that the
              destination is reachable.
          (3) Set the route change flag and invoke triggered update
              process to notify the unreachable route.
          Otherwise,
              do nothing and return to Step 1 to process the next entry.

       (e) the new metric = 16 & the new next hop /= the current one

          (1) If the bit corresponding to the port, from which the
              update message was received, is marked in the
              broadcast/multicast routing table, clear the bit.
          (2) Return to Step 1 to process the next entry.













Murakami & Maruyama          Informational                     [Page 19]

RFC 2174                         MAPOS                         June 1997


5.5 Timers

   The timer routine increments the following timers and executes its
   associated process on their expiration.

    (1) EXPIRATION_TIMER and GC_TIMER

    The EXPIRATION_TIMERs and GC_TIMERs of each entry in the unicast
    routing table are incremented every FULL_UPDATE_TIME (10 seconds by
    default). When a EXPIRATION_TIMER expires, the metric is changed to
    unreachable(16), update process is triggered, and GC_TIMER is
    started. When a GC_TIMER expires, the entry is deleted from the
    local routing table. EXPIRATION_TIMER and GC_TIMER are cleared every
    time a switch receives a routing update.

    (2) FORWARD_DELAY_TIMER

    FORWARD_DELAY_TIMER is completely handled in the receive process and
    has no relation to the timer routine.

    (3) PORT_EXPIRATION_TIMER

    PORT_EXPIRATION_TIMERs associated with each bit in the
    broadcast/multicast routing table are incremented every
    FULL_UPDATE_TIME (10 seconds by default).  When the timer expires,
    the corresponding downstream switch is considered to be down and the
    corresponding bit in the broadcast/multicast routing table is
    cleared. This timer is cleared by the receive process every time a
    poisoned reverse packet is received from the corresponding switch.

6. Further considerations on implementation

6.1 Port State

   A switch assumes that every port is connected to a switch initially.
   Thus, it sends update packets to every port. When a node is connected
   to a port, the switch recognizes it by receiving an NSP request
   packet, and stops sending SSP packets to the port. Whenever a switch
   detects a connection failure such as loss of signal and out-of-
   synchronization, it should clear the internal state table
   corresponding of the port.

6.2 Half way connection problem

   A port consists of two channels, transmit and receive. Although it is
   easy for a node or a switch to detect a receive channel failure,
   transmit channel failure may not be detected, causing half way
   connection.  This results in a black hole.



Murakami & Maruyama          Informational                     [Page 20]

RFC 2174                         MAPOS                         June 1997


   Thus, whenever a switch receives a SSP update packet from a port, it
   SHOULD check the status of the corresponding transmit channel.
   SONET/SDH has a feedback mechanism for that purpose. The status of
   the local transmit channel received at the remote end can be sent
   back utilizing the overhead part, FEBE(Far End Block Error) and
   FERF(Far End Receive Failure), of the corresponding receive channel.
   If the signals indicates that the transmit channel has a problem, the
   SSP packet received from the remote end should be silently discarded.
   However, some SONET/SDH services do not provide path overhead
   transparency.

   Although, SONET/SDH APS(Automatic Protection Switching) can be
   utilized to switch service from a failed line to a spare line, the
   function is out of scope of this protocol.

7. Security Considerations

   Security issues are not discussed in this memo.

References

   [1]   Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
         over SONET/SDH Version 1," RFC2171, June 1997.

   [2]   CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
         Rates, 1990.

   [3]   CCITT Recommendation G.708: Network Node Interface for
         Synchronous Digital Hierarchy, 1990.

   [4]   CCITT Recommendation G.709: Synchronous Multiplexing Structure,
         1990.

   [5]   American National Standard for Telecommunications - Digital
         Hierarchy - Optical Interface Rates and Formats Specification,
         ANSI T1.105-1991.

   [6]   Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
         Rutgers University, June 1988.

   [7]   Malkin, G., "RIP Version 2 - Carrying Additional Information ",
         RFC1723, Xylogics, Inc., November 1994.

   [8]   Pusateri, T., "Distance Vector Multicast Routing Protocol",
         September 1996, Work in Progress.

   [9]   Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
         Node Switch Protocol," RFC2173, June 1997.



Murakami & Maruyama          Informational                     [Page 21]

RFC 2174                         MAPOS                         June 1997


   [10]  Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
         Numbers," RFC2172, June 1997.

Acknowledgements

   The authors would like to acknowledge the contributions and
   thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
   Kobayashi, Paul Francis, Toshiaki Yoshida, Takahiro Sajima, and
   Satoru Yagi.

Authors' Address

             Ken Murakami
             NTT Software Laboratories
             3-9-11, Midori-cho
             Musashino-shi
             Tokyo 180, Japan
             E-mail: [e-mail]

             Mitsuru Maruyama
             NTT Software Laboratories
             3-9-11, Midori-cho
             Musashino-shi
             Tokyo 180, Japan
             E-mail: [e-mail]


























Murakami & Maruyama          Informational                     [Page 22]