home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_n_r / draft-rfced-info-mitsuru-00.txt < prev    next >
Text File  |  1997-04-25  |  49KB  |  1,221 lines

  1.  
  2.  
  3. INTERNET-DRAFT           EXPIRES OCTOBER 1997            INTERNET-DRAFT
  4.  
  5. Network Working Group                                   K. Murakami
  6. INTERNET-DRAFT                                          M. Maruyama
  7. Category: Informational                                 NTT Laboratories
  8.                                                         April 1997
  9.  
  10.  
  11.           A MAPOS version 1 Extension - Switch-Switch Protocol
  12.           <draft-rfced-info-mitsuru-00.txt>
  13.  
  14. Status of this Memo
  15.  
  16.    This document is an Internet-Draft.  Internet-Drafts are working
  17.    documents of the Internet Engineering Task Force (IETF), its
  18.    areas, and its working groups.  Note that other groups may also
  19.    distribute working documents as Internet-Drafts.
  20.  
  21.    Internet-Drafts are draft documents valid for a maximum of six
  22.    months and may be updated, replaced, or obsoleted by other
  23.    documents at any time.  It is inappropriate to use Internet-
  24.    Drafts as reference material or to cite them other than as ``work
  25.    in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check
  28.    the ``1id-abstracts.txt'' listing contained in the Internet-
  29.    Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
  30.    (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
  31.    Coast), or ftp.isi.edu (US West Coast).
  32.  
  33. Authors' Note
  34.  
  35.    This memo documents a MAPOS (Multiple Access Protocol over SONET/SDH)
  36.    version 1 extension, Switch Switch Protocol which provides dynamic
  37.    routing for unicast, broadcast, and multicast. This document is NOT
  38.    the product of an IETF working group nor is it a standards track
  39.    document.  It has not necessarily benefited from the widespread and
  40.    in depth community review that standards track documents receive.
  41.  
  42. Abstract
  43.  
  44.    This document describes a MAPOS version 1 extension, SSP (Switch
  45.    Switch Protocol).  MAPOS is a multiple access protocol for
  46.    transmission of network-protocol packets, encapsulated in High-Level
  47.    Data Link Control (HDLC) frames, over SONET/SDH. In MAPOS network, A
  48.    SONET switch provides the multiple access capability to end nodes.
  49.    SSP is a protocol of Distance Vector family and provides unicast and
  50.    broadcast/multicast routing for multiple SONET switch environment.
  51.  
  52. 1. Introduction
  53.  
  54.    This document describes an extension to MAPOS version 1, Switch
  55.    Switch Protocol, for routing both unicast and broadcast/multicast
  56.    frames.  MAPOS[1], Multiple Access Protocol over SONET (Synchronous
  57.    Optical Network) / SDH (Synchronous Digital Hierarchy) [2][3][4][5],
  58.    is a link layer protocol for transmission of HDLC frames over
  59.    SONET/SDH. A SONET switch provides the multiple access capability to
  60.    each node. SSP is a dynamic routing protocol designed for an
  61.    environment where a MAPOS network segment spans over multiple
  62.    switches.  It is a protocol of Distance Vector family. It provides
  63.    both unicast and broadcast/multicast routing. First, this document
  64.    describes the outline of SSP. Next, it explains unicast and
  65.    broadcast/multicast routing algorithms. Then, it describes the SSP
  66.    protocol in detail.
  67.  
  68. 2. Constraints in Designing SSP
  69.  
  70.    SSP is a unified routing protocol supporting both unicast and
  71.    broadcast/multicast. The former and the latter are based on the
  72.  
  73.  
  74.  
  75. Murakami, Maruyama                                              [Page 1]
  76.  
  77. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  78.  
  79.  
  80.    Distance Vector [6][7] and the spanning tree[8] algorithm,
  81.    respectively. In MAPOS version 1, a small number of switches is
  82.    assumed in a segment.  Thus, unlike DVMRP(Distance Vector Multicast
  83.    Routing Protocol)[8], TRPB(Truncated Reverse Path Broadcasting) is
  84.    not supported for simplicity. This means that multicast frames are
  85.    treated just the same as broadcast frames and are delivered to every
  86.    node.
  87.  
  88.    In MAPOS version 1, there are two constraints regarding design of the
  89.    broadcast/multicast routing algorithm;
  90.  
  91.      (1) there is no source address field in MAPOS HDLC frames
  92.  
  93.      (2) there is no TTL(Time To Live) field in MAPOS HDLC frames to
  94.      prevent forwarding loop.
  95.  
  96.    To cope with the first issue, VRPB(Virtual Reverse Path Broadcast)
  97.    algorithm is introduced. In VRPB, all broadcast and multicast frames
  98.    are assumed to be generated by a node under a specific switch called
  99.    VSS(Virtual Source Switch). VSS is the switch which has the smallest
  100.    switch number in a MAPOS network. Each switch determine its place in
  101.    the spanning tree rooted from VSS independently. Whenever a switch
  102.    receives a broadcast/multicast frame, it forwards the frame to all
  103.    upstream and downstream switches except for the one which has sent
  104.    the frame to the local switch.
  105.  
  106.    To cope with the second issue, the forward delay timer is introduced.
  107.    Even if a switch finds a new VSS, it suspends forwarding for a time
  108.    period. This timer ensures that all the switches have a consistent
  109.    routing information and that they are synchronized after a topology
  110.    change.
  111.  
  112. 3. Unicast Routing in SSP
  113.  
  114.    This section describes the address structure of MAPOS version 1 and
  115.    the SSP unicast routing based on it.
  116.  
  117. 3.1 Address Structure of MAPOS version 1
  118.  
  119.    In a multiple switch environment, a node address consists of the
  120.    switch number and the port number to which the node is connected. As
  121.    shown in Figure 1, the address length is 8 bits and the LSB is always
  122.    1, which indicates the end of the address field. An MSB of 0
  123.    indicates a unicast address. The switch and the port number fields
  124.    are variable-length. In this document, an unicast the address is
  125.    represented as "0 <switch-number> <port number>".  Note that a port
  126.    number includes EA bit.
  127.  
  128.    MSB of 1 indicates multicast or broadcast. In the case of broadcast,
  129.    the address field contains all 1s (0xff in hex). In the case of
  130.    multicast, the remaining bits indicate a group address.  The switch
  131.  
  132.  
  133.  
  134. Murakami, Maruyama                                              [Page 2]
  135.  
  136. I/D             MAPOS Version 1 Switch-Switch Protocol       April 1997
  137.  
  138.  
  139.    number field is variable-length. An multicast address is represented
  140.    as "1 <group address>".
  141.  
  142.  
  143.  
  144.            Switch Number(variable length)
  145.                |
  146.                |      +--- Port Number
  147.                |      |
  148.                V      V
  149.              |<->|<------->|
  150.            +-------------+-+
  151.            | | | | | | | | |
  152.            | |           |1|
  153.            +-+-----------+-+
  154.             ^             ^
  155.             |             |
  156.             |             +------- EA bit (always 1)
  157.             |
  158.             1 : broadcast, multicast
  159.             0 : unicast
  160.  
  161.                               Figure 1 Address Format
  162.  
  163.  
  164.    Figure 2 shows an example of a SONET LAN that consists of three
  165.    switches.  In this configuration, two bits of a node address are used
  166.    to indicate the switch number. Node N1 is connected to the port
  167.    0x03(000011 in binary) of the switch S2 numbered 0x2.  Thus, the node
  168.    address is 01000011 in binary. Node N4 has an address 01101001 in
  169.    binary since the connected switch number is 0x3 and the port number
  170.    is 0x09.
  171.  
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.  
  187.  
  188.  
  189.  
  190.  
  191.  
  192.  
  193. Murakami, Maruyama                                              [Page 3]
  194.  
  195. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  196.  
  197.  
  198.  
  199.                         01000011
  200.                         +------+
  201.                         | node |
  202.                         |  N1  |
  203.                         +------+
  204.            01000101         |0x03              |0x03       00101001
  205.            +------+     +---+----+         +---+----+      +------+
  206.            | node +-----+ SONET  +---------+ SONET  +------+ node |
  207.            |  N2  | 0x05| Switch |0x09 0x05| Switch |0x09  |  N3  |
  208.            +------+     |   S2   |         |   S1   |      +------+
  209.                         |  (0x2) |         |  (0x1) |
  210.                         +---+----+         +---+----+
  211.                             |0x07              |0x07
  212.                             |                  |
  213.                             |                  |0x03      01101001
  214.                             |              +---+----+     +------+
  215.                             +--------------+ SONET  +-----+ node |
  216.                                        0x05| Switch |0x09 |  N4  |
  217.                                            |   S3   |     +------+
  218.                                            |  (0x3) |
  219.                                            +---+----+
  220.                                                |0x07
  221.  
  222.                     Figure 2 Multiple SONET Switch Environment
  223.  
  224.  
  225. 3.2 Forwarding Unicast Frames
  226.  
  227.    Unicast frames are forwarded along the shortest path. For example, a
  228.    frame from node N4 destined to N1 is forwarded by switch S3 and S2.
  229.    These SONET switches forwards an HDLC frame based on the destination
  230.    switch number contained in the destination address.
  231.  
  232.    Each switch keeps a routing table with entries for possible
  233.    destination switches. An entry contains the subnet mask, the next hop
  234.    to the adjacent switch along the shortest path to the destination,
  235.    the metric measuring the total distance to the destination, and other
  236.    parameters associated with the entry such as timers. For example, the
  237.    routing table in switch S1 will be as shown in Table 1. The metric
  238.    value 1 means that the destination switch is an adjacent switch. The
  239.    value 16 means that it is unreachable. Although the values between 17
  240.    and 31 also mean unreachable, they are special values utilized for
  241.    split horizon with poisoned reverse [8].
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252. Murakami, Maruyama                                              [Page 4]
  253.  
  254. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  255.  
  256.  
  257.  
  258.      +-------------------------+----------+--------+------------+
  259.      | destination |   subnet  | next hop | metric |   other    |
  260.      |   switch    |   mask    |   port   |        | parameters |
  261.      +-------------+-----------+----------+--------+------------+
  262.      |  01000000   | 11100000  | 00000101 |    1   |            |
  263.      +-------------+-----------+----------+--------+------------+
  264.      |  01100000   | 11100000  | 00000111 |    1   |            |
  265.      +-------------+-----------+----------+--------+------------+
  266.  
  267.                    Table 1  An Example of a Routing Table
  268.  
  269.  
  270.    When a switch receives a unicast frame, it extracts the switch number
  271.    from the destination address. If it equals to the local switch
  272.    number, the frame is sent to the local node through the port
  273.    specified in the destination address.  Otherwise, the switch looks up
  274.    its routing table for a matching destination switch number by masking
  275.    the destination address with the corresponding subnet mask. If a
  276.    matching entry is found, the frame is sent to an adjacent switch
  277.    through the next hop port in the entry. Otherwise, it is silently
  278.    discarded or sent to the control processor for its error processing.
  279.  
  280. 3.4 Protocol Overview
  281.  
  282.    This subsection describes an overview of the unicast routing protocol
  283.    and its algorithm.
  284.  
  285. 3.4.1 Route Exchange
  286.  
  287.    SSP is a distance vector protocol to establish and maintain the
  288.    routing table. In SSP, each switch sends a routing update message to
  289.    every adjacent switches every FULL_UPDATE_TIME (10 seconds by
  290.    default). The update message is a copy of the routing table, that is,
  291.    routes.
  292.  
  293.    When a switch receives an update message from an adjacent switch
  294.    through a port, it adds the cost associated with the port, usually 1,
  295.    to every metric value in the message. The result is a set of new
  296.    metrics from the receiving switch to the destination switches. Next,
  297.    it compares the new metrics with those of the corresponding entries
  298.    in the existing routing table. A smaller metric means a better route.
  299.    Thus, if the new metric is smaller than the existing one, the entry
  300.    is updated with the new metric and next hop. The next hop is the port
  301.    from which the update message was received. Otherwise, the entry is
  302.    left unchanged. If the existing next hop is the same as the new one,
  303.    the metric is updated regardless of the metric value.  If no
  304.    corresponding route is found, a new route entry is created.
  305.  
  306. 3.4.2 Route Expiration
  307.  
  308.  
  309.  
  310.  
  311. Murakami, Maruyama                                              [Page 5]
  312.  
  313. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  314.  
  315.  
  316.    Assume a route to R is advertised by a neighboring switch S. If no
  317.    update message has been received from switch S for the period
  318.    FULL_UPDATE_TIME * 3 (30 seconds by default) or the route is
  319.    advertised with metric 16 by switch S, the route to R is marked as
  320.    unreachable by setting its metric to 16. In other words, the route to
  321.    R is kept advertised even if the route is not refreshed up-to 30
  322.    seconds.
  323.  
  324.    To process this, each routing table entry has an EXPIRATION_TIMER (30
  325.    seconds by default, that is, FULL_UPDATE_TIME *3). If another switch
  326.    advertises a route to R, it replaces the unreachable route. Even if a
  327.    route is marked unreachable, the entry is kept in the routing table
  328.    for the period of FULL_UPDATE_TIME * 3.  This enables the switch to
  329.    notify its neighbors of the unreachable route by sending update
  330.    messages with metric 16. To process this, each routing table entry
  331.    has a garbage collection timer GC_TIMER (30 seconds by default). The
  332.    entry is deleted on expiration of the timer. Figure 3 shows this
  333.    transition.
  334.  
  335.  
  336.          The Last Update           Expiration         Garbage Collection
  337.                |                       |                       |
  338.     Routing    V   T       T       T   V   T       T       T   V
  339.     Table      +-------+-------+-------+-------+-------+-------X
  340.     Entry             metric < 16      |       metric = 16     |
  341.  
  342.                ----------------------->|---------------------->|
  343.                    EXPIRATION_TIMER            GC_TIMER
  344.                                                        Stop Advertising
  345.                                                                |
  346.     Advertised                                                 V
  347.     Metric     --   metric <16   ------+--  metric = 16 -------X
  348.  
  349.                                                     T: FULL_UPDATE_TIME
  350.  
  351.                          Figure 3. Route Expiration
  352.  
  353.  
  354.  
  355. 3.4.3 Slow Convergence Prevention
  356.  
  357.    To prevent slow convergence of routing information, two techniques,
  358.    split horizon with poisoned reverse, and triggered update are
  359.    employed.
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370. Murakami, Maruyama                                              [Page 6]
  371.  
  372. I/D           MAPOS Version 1 Switch-Switch Protocol       April 1997
  373.  
  374.  
  375.  
  376.            Sn <------------- S3 <- S2 <- S1
  377.  
  378.                    (i) Before Outage
  379.  
  380.                                 ->
  381.            Sn <--    X    -- S3 <- S2 <- S1
  382.  
  383.                    (ii) After Outage
  384.  
  385.                       Figure 4 An Example of Slow Convergence
  386.  
  387.  
  388.    Figure 4 shows an example of slow convergence[6]. In (i), three
  389.    switches, S1, S2, and S3, are assumed to have a route to Sn. In (ii),
  390.    the connection to Sn has disappeared because of an outage, but S2
  391.    continue to advertise the route since there is no means for S2 to
  392.    detect the outage immediately and it has the route to Sn in its
  393.    routing table. Thus, S3 misunderstand that S2 has the best route to
  394.    Sn and S2 is the next hop. This results in a transitive loop between
  395.    S2 and S3. S2 and S3 increments the metric of the route to Sn every
  396.    time they advertise the route and the loop continues until the metric
  397.    reaches 16. To suppress the slow convergence problem, split horizon
  398.    with poisoned reverse is used.
  399.  
  400.    In split horizon with poisoned reverse, a route is advertised as
  401.    unreachable to the next hop. The metric is the received metric value
  402.    plus 16. For example, in Figure 4, S2 advertises the route to Sn with
  403.    the metric unreachable only to S3. Thus, S3 never considers that S2
  404.    is the next hop to Sn. This ensures fast convergence on disappearance
  405.    of a route.
  406.  
  407.    Another technique, triggered update, forces a switch to send an
  408.    immediate update instead of waiting for the next periodic update when
  409.    a switch detects a local port failure, or when it receives a message
  410.    that a route has become unreachable, or that its metric has
  411.    increased. This makes the convergence faster.
  412.  
  413. 4. Broadcast/multicast Routing in SSP
  414.  
  415.    This section explains VRPB algorithm and the outline of
  416.    broadcast/multicast routing protocol.
  417.  
  418. 4.1 Virtual Reverse Path Broadcast/Multicast Algorithm
  419.  
  420.    SSP provides broadcast/multicast routing based on a spanning tree
  421.    algorithm.  As described in Section 2, the routing is based on the
  422.    VRPB(Virtual Reverse Path Broadcast) algorithm.  In VRPB, each switch
  423.    assumes that all broadcast and multicast frames are generated by a
  424.    specific switch, VSS(Virtual Source Switch). Thus, unlike DVMRP, a
  425.    MAPOS network has only one spanning tree at any given time.
  426.  
  427.  
  428.  
  429. Murakami, Maruyama                                              [Page 7]
  430.  
  431. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  432.  
  433.  
  434.    The frames are forwarded along the reverse path by computing the
  435.    shortest path from the VSS to all possible recipients.  VSS is the
  436.    switch which has the lowest switch number in the network.  Because
  437.    the routing table contains all the unicast destination addresses
  438.    including the switch numbers, each switch can identify the VSS
  439.    independently by searching for the smallest switch number in its
  440.    unicast routing table.
  441.  
  442.    In Figure 2, switch S1 is the VSS.  Each switch determines its place
  443.    in the spanning tree, relative to the VSS, and which of its ports are
  444.    on the shortest path tree.  Thus, the spanning tree is as shown in
  445.    Figure 5. Except for the VSS, each switch has one upstream port and
  446.    zero or more downstream ports. VSS have no upstream port, since it is
  447.    the root of the spanning tree. In Figure 2.  switch S2's upstream
  448.    port is port 0x09 and it has no downstream port.
  449.  
  450.  
  451.                    S1 (VSS)
  452.                   /  \
  453.                  /    \
  454.                 /      \
  455.                S2      S3
  456.  
  457.                            Figure 5  VRPB Spanning Tree
  458.  
  459.  
  460.    When a switch receives a broadcast/multicast frame, it forwards the
  461.    frame to all of the upstream switch, the downstream switches, and the
  462.    directly connected nodes. However, it does not forward to the switch
  463.    which sent the frame to it. For that purpose, a bit mapped
  464.    broadcast/multicast routing table may be employed.  The
  465.    broadcast/multicast routing process marks all the bits corresponding
  466.    to the ports to which frames should be forwarded. The forwarding
  467.    process refers to it and broadcasts a frame to all the ports with its
  468.    corresponding bit marked.
  469.  
  470. 4.2 Forwarding Broadcast/multicast Frames
  471.  
  472.    When a switch forwards a broadcast/multicast frame, (1) it first
  473.    decides the VSS by referring to its unicast routing table. Then, (2)
  474.    it refers to its broadcast/multicast routing table corresponding to
  475.    the VSS. A cache may be used to reduce the search overhead. (3) Based
  476.    on the routing table, the switch forwards the frame.
  477.  
  478.    Figure 6 shows an example of S2's broadcast/multicast routing table
  479.    for the VSS S1. It is a bit map table and each bit corresponds to a
  480.    port. The value 1 indicates that frames should be forwarded to a node
  481.    or a switch through the port.  If no bit is marked, the frame is
  482.    silently discarded. In the example of Figure 6, port 0x09 is the
  483.    upstream port to its VSS, that is, S1. Other ports, ports 0x05 and
  484.    0x03 are path to N2 and N1 nodes, respectively.
  485.  
  486.  
  487.  
  488. Murakami, Maruyama                                              [Page 8]
  489.  
  490. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  491.  
  492.  
  493.  
  494.              0F  0D  0B  09  07  05  03  01   ---   port number
  495.            +---+---+---+---+---+---+---+---+
  496.            | 0 | 0 | 0 | 1 | 0 | 1 | 1 | 0 |  ---   1: forward
  497.            +---+---+---+---+---+---+---+---+        0: inhibit
  498.  
  499.                  Figure 6 Broadcast/Multicast Routing Table of S2
  500.  
  501.  
  502. 4.3 Forwarding Path Examples
  503.  
  504.    Assume that a broadcast frame is generated by N2 in Figure 2. The
  505.    frame is received by S2.
  506.  
  507.    Then, S2 passes it to all the connected nodes except for the source
  508.    N2. That is, only to N1. At the same time, it also forwards the frame
  509.    to all its upstream and downstream switches. Since S2 has no
  510.    downstream switch, S2 forwards the frame to S1 though its upstream
  511.    port 0x09.
  512.  
  513.    S1 is the VSS and it passes the frame to all the local nodes, that
  514.    is, only to N3. Since it has no upstream switch and S2 is the switch
  515.    which sent the frame to S1, the frame is eventually forwarded only to
  516.    a downstream switch S3.
  517.  
  518.    S3 passes the frame to its local node, N4. Since S3 has only an
  519.    upstream and the frame was received through that port, S3 does not
  520.    forward the frame to any switch.
  521.  
  522.    The resulting path is shown in Figure 7. Although this is not the
  523.    optimal path, VRPB ,at least, ensures that broadcast/multicast frames
  524.    are delivered all the nodes without a loop. Figures 8 and 9 show the
  525.    forwarding path for frames generated by a node under S3 and S4,
  526.    respectively.
  527.  
  528.  
  529.                              +-> N3
  530.                              |
  531.              N2 -> S2 +-> S1 +-> S3 -> N4
  532.                       |
  533.                       +-> N1
  534.  
  535.                          Figure 7  Forwarding Path from N2
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547. Murakami, Maruyama                                              [Page 9]
  548.  
  549. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  550.  
  551.  
  552.  
  553.                              +-> N1
  554.                              |
  555.              N3 -> S1 +-> S2 +-> N2
  556.                       |
  557.                       +-> S3 --> N4
  558.  
  559.                          Figure 8  Forwarding Path from N3
  560.  
  561.  
  562.  
  563.                              +-> N3
  564.                              |
  565.              N4 -> S3 +-> S1 +-> S2 +-> N1
  566.                                     |
  567.                                     +-> N2
  568.                          Figure 9  Forwarding Path from N4
  569.  
  570.  
  571. 4.4 Suppressing Routing Loop
  572.  
  573.    To suppress transitive routing loop, forward delay is employed. A
  574.    switch suspends broadcast/multicast forwarding for a period after a
  575.    new VSS is found in the routing table. This prevents transitive
  576.    routing loop by waiting for all the switches to have the same routing
  577.    information and become synchronized. In addition to controlling
  578.    sending of frames by forward delay, another mechanism is employed to
  579.    prevent transitive routing loop by controlling reception of frames.
  580.    That is, broadcast/multicast frames received through ports other than
  581.    the upstream and downstream ports are discarded.
  582.  
  583. 4.5 Upstream Switch Discovery
  584.  
  585.    The upstream port is determined by the shortest reverse path to the
  586.    VSS.  It is identified by referring to the next hop port of the route
  587.    to VSS in the local unicast routing table. When a new next hop to the
  588.    VSS is discovered, the bit corresponding to the old next hop port is
  589.    cleared, and the bit corresponding to the new one is marked as the
  590.    upstream port in the broadcast/multicast routing table.
  591.  
  592. 4.6 Downstream Switch Discovery
  593.  
  594.    To determine the downstream ports, split horizon with poisoned
  595.    reverse is employed. When a switch receives a route with a metric
  596.    poisoned by split horizon processing through a port as described in
  597.    Section 3.4.3, the port is considered to be a downstream port. In
  598.    Figure 2, S1 is the VSS and the route information is sent back from
  599.    S2 to S1 with metric unreachable based on the split horizon with
  600.    poisoned reverse. Thus, S1 knows that S2 is one of its downstreams.
  601.  
  602. 4.7 Downstream Port Expiration
  603.  
  604.  
  605.  
  606. Murakami, Maruyama                                             [Page 10]
  607.  
  608. I/D              MAPOS Version 1 Switch-Switch Protocol       April 1997
  609.  
  610.  
  611.    When a poison reversed packet is newly received from a port, the
  612.    local switch knows that a new downstream switch has appeared. Then,
  613.    it marks the bit corresponding to the port and starts
  614.    FORWARD_DELAY_TIMER (30second by default, that is, FULL_UPDATE_TIME *
  615.    3) for the port. The forwarding of broadcast/multicast frames to the
  616.    port is prohibited until the timer expires.  Every time the local
  617.    switch receives a poison reversed packet through a port, it
  618.    initializes PORT_EXPIRATION_TIMER(30 seconds by default, that is,
  619.    FULL_UPDATE_TIME *3) corresponding to the port. A continuous loss of
  620.    poison reversed packets or a failure of downstream port results in
  621.    expiration of PORT_EXPIRATION_TIMER, and the corresponding bit is
  622.    cleared.
  623.  
  624.  
  625.                First Update               Last Update
  626.                    |                           |
  627.                    V T   T   T   T   T   T   T V
  628.                    +---+---+---+---+---+---+---+---+---+---+---+---+---
  629.    A bit in
  630.    the routing      0   0   0   1   1   1   1   1   1   1   0   0   0
  631.    table                       ^                           ^
  632.                     <--------->|                <--------->|
  633.                         ^   route up                 ^ route down
  634.                         |                            |
  635.                   FORWARD_DELAY               PORT_EXPIRATION
  636.  
  637.                                            T: FULL_UPDATE_TIME
  638.  
  639.                         Figure 10. Port Expiration
  640.  
  641.  
  642.    When a downstream switch discovers another best path to the VSS or a
  643.    new VSS, it stops split horizon with poison reverse and sends
  644.    ordinary update messages. Whenever the local switch receives an
  645.    ordinary update message from its downstream switch, it SHOULD
  646.    immediately clear the corresponding bit in the routing table and stop
  647.    forwarding of broadcast/multicast frames.
  648.  
  649. 4.8 Node Discovery
  650.  
  651.    When a NSP[9] packet, requesting a node address from a port, is
  652.    received, the local switch considers that a new node is connected,
  653.    and marks the corresponding bit in the broadcast/multicast routing
  654.    table. When the local switch detects that the port went down as
  655.    described in [9], it clear the corresponding bit.
  656.  
  657. 4.9 Invalidating The Broadcast/multicast Routing Table
  658.  
  659.    When a new VSS is discovered or when the VSS becomes unreachable, the
  660.    entire broadcast/multicast routing table is invalidated. That is, a
  661.    change of upstream port affects the entire broadcast/multicast
  662.  
  663.  
  664.  
  665. Murakami, Maruyama                                             [Page 11]
  666.  
  667. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  668.  
  669.  
  670.    routing. However, a change of a downstream port does not affect
  671.    forwarding to other downstream ports, its upstream port, and nodes.
  672.  
  673. 5. Detailed Protocol Operation
  674.  
  675.    This section explains SSP packet format and protocol processing in
  676.    detail.
  677.  
  678. 5.1 Packet Format
  679.  
  680.    This subsection describes the packet encapsulation in HDLC frame and
  681.    the packet format.
  682.  
  683. 5.1.1 Packet Format and Its Encapsulation
  684.  
  685.    SSP packet format is designed based on RIP[6] and its successor, RIP2
  686.    [7]. Figure 11 shows the packet format. A SSP packet is encapsulated
  687.    in the information field of a MAPOS HDLC frame. The HDLC protocol
  688.    field of SSP is 0xFE05 in hex as defined by the ``MAPOS Version 1
  689.    Assigned Numbers'' [10]. The packet is sent encapsulated in a unicast
  690.    packet with the destination address 0000 0001, which indicates the
  691.    control processor of an adjacent switch.
  692.  
  693.  
  694.    (MSB)                                                       (LSB)
  695.    7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
  696.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -------
  697.    |    Command    |   Version     |           unused              | SSP header
  698.    +---------------+---------------+-------------------------------+ -------
  699.    | Address Family Identifier     |            All 0              |
  700.    +-------------------------------+-------------------------------+
  701.    |                         HDLC Address                          | an SSP
  702.    +---------------------------------------------------------------+ route
  703.    |                         Subnet Mask                           | entry
  704.    +---------------------------------------------------------------+
  705.    |                         All 0                                 |
  706.    +---------------------------------------------------------------+
  707.    |                         Metric                                |
  708.    +---------------+---------------+-------------------------------+ ------
  709.    | Address Family Identifier     |            All 0              |
  710.  
  711.                         Figure 11 SSP packet format
  712.  
  713.  
  714.    The maximum packet size is 512 octet. The first four octets is the
  715.    SSP header. The remainder of the message is composed of 1 - 25 route
  716.    entries. Each entry is 20 octets long.
  717.  
  718. 5.1.2 SSP Header
  719.  
  720.    SSP header consists of a command field and a version field. The
  721.  
  722.  
  723.  
  724. Murakami, Maruyama                                             [Page 12]
  725.  
  726. I/D           MAPOS Version 1 Switch-Switch Protocol       April 1997
  727.  
  728.  
  729.    command field is one octet long and holds one of the following
  730.    values;
  731.  
  732.      1 - request     A request to send all or part of SSP routing table.
  733.  
  734.      2 - response    A message containing all, or a part of the sender's
  735.                      SSP routing table.  This message may be sent in
  736.                      response to a request, or it may be an update
  737.                      message generated by the sender.
  738.  
  739.    The Version field indicates the version of SSP being used. The
  740.    current version number is 1.
  741.  
  742. 5.1.3 SSP Route Entries
  743.  
  744.    Each entry has an address family identifier. It indicates an
  745.    attribute of the entry. SSP routing protocol uses 2 as its identifier
  746.    by default. The identifier 0 indicates unspecified. This value is
  747.    used when a switch requests other switches to send the entire SSP
  748.    routing table. A recipient of the message SHOULD ignore all entries
  749.    with unknown value.
  750.  
  751.    The HDLC address is a destination address. It may be a switch address
  752.    or a node address. The subsequent subnet mask is applied to the HDLC
  753.    address to yield the switch number portion. The field is 4 octet long
  754.    and the address is placed in the least significant position.
  755.  
  756.    Metric indicates the distance to the destination node. That is, how
  757.    many switches a message must go through en route to the destination
  758.    node. The metric field must contain a value between 1 and 31. The
  759.    metric of 16 indicates that the destination is not reachable and is
  760.    ignored by recipients. The values between 17 and 31 are utilized for
  761.    poisoned reverse with split horizon and also means unreachable. The
  762.    metric 0 indicates the local switch itself.
  763.  
  764. 5.2 Routing Table
  765.  
  766.    Every switch has an SSP routing table. The table is a collection of
  767.    route entries - one for every destination. An entry consists of the
  768.    following information;
  769.  
  770.     (1) destination : A unicast destination address.
  771.  
  772.     (2) subnet mask : A mask to extract the switch address by applying
  773.     bitwise AND with the destination address
  774.  
  775.     (3) next hop port : The local port number connected to the adjacent
  776.     switch along the path to the destination.
  777.  
  778.     (4) metric : Distance to the destination node. The metric of an
  779.     adjacent switch is 1 and that of local switch is 0.
  780.  
  781.  
  782.  
  783. Murakami, Maruyama                                             [Page 13]
  784.  
  785. I/D           MAPOS Version 1 Switch-Switch Protocol       April 1997
  786.  
  787.  
  788.     (5) timers for unicast routing : Timers associated with unicast
  789.     routing such as EXPIRATION_TIMER and GC_TIMER.
  790.  
  791.     (6) flags : Various flags associated with the route such as route
  792.     change flag to indicate that the route has changed recently or it
  793.     has timed out.
  794.  
  795.     (7) bit map routing table for broadcast/multicast : Each bit
  796.     corresponding to the port to an upstream or a downstream switch of
  797.     the spanning tree is marked in addition to the ports to end nodes.
  798.     Broadcast/multicast frames are forwarded only through those ports
  799.     with their corresponding bit set. Since only one spanning tree
  800.     exists at a time in a network, each route entry does not necessarily
  801.     have to have this field.
  802.  
  803.     (8) timers for broadcast/multicast routing : Timers associated with
  804.     broadcast/multicast routing such as FORWARD_DELAY_TIMER and
  805.     PORT_EXPIRATION_TIMER. These timers are prepared for each bit of
  806.     broadcast/multicast routing table.
  807.  
  808. 5.3 Sending Routing Messages
  809.  
  810. 5.3.1 Packet Construction
  811.  
  812.    Because of the split horizon with poisoned reverse, a routing message
  813.    differs depending on the adjacent switch to which the message is
  814.    being sent. The upstream switch of a route, that is next hop,
  815.    receives a message which contains the corresponding route with a
  816.    metric between 17 and 31. Switches that are not the upstream switch
  817.    of any route receive the same message. Here, we assume that a packet
  818.    for a routing message is constructed for an adjacent switch which is
  819.    connected through the local port N.
  820.  
  821.    First, set the version field to 1, the current SSP version. Then, set
  822.    the command to "response". Set other fields which are supposed to be
  823.    zero to zero.  Next, start filling in entries.
  824.  
  825.    To fill in the entries, perform the following for each route. The
  826.    destination HDLC address, netmask, and its metric are put into the
  827.    entry in the packet.  Routes must be included in the packet even if
  828.    their metrics are unreachable(16).  If the next hop port is N, 16 is
  829.    added to the metric for split horizon with poisoned reverse.
  830.  
  831.    Recall that the maximum packet size is 512 bytes.  When there is no
  832.    more space in a packet, send the current message and start a new one.
  833.    If a triggered update is being generated, only entries whose route
  834.    change flags are set need be included.
  835.  
  836.  
  837. 5.3.2 Sending update
  838.  
  839.  
  840.  
  841.  
  842. Murakami, Maruyama                                             [Page 14]
  843.  
  844. I/D           MAPOS Version 1 Switch-Switch Protocol       April 1997
  845.  
  846.  
  847.    Sending update may be triggered in any of the following ways;
  848.  
  849.     (1) Initial Update
  850.  
  851.     When a switch first comes up, it SHOULD send to all adjacent
  852.     switches a request asking for their entire routing tables. The
  853.     destination address is 00000001. When a port comes on-line, the
  854.     request packet is sent to the port. The packet, requesting the
  855.     entire routing table, MUST have at least an entry with the address
  856.     family identifier 0 meaning unspecified.
  857.  
  858.     When a switch receives a request packet, it first checks the version
  859.     number of the SSP header. If it is not 1, the packet is silently
  860.     discarded. Otherwise, the address family identifier is examined.  If
  861.     the value is 0, the entire SSP routing table is returned in one or
  862.     more response packets destined to 00000001. Otherwise, the request
  863.     is silently discarded.  Although the original RIP specification
  864.     defines the partial routing table request, SSP routing protocol
  865.     omits it for the sake of simplicity.
  866.  
  867.     (2) Periodic Update
  868.  
  869.     Every switch participating in the routing process sends an update
  870.     message (response message) to all its neighbor switches once every
  871.     FULL_UPDATE_TIME (10 seconds). For the periodic update, a response
  872.     packet(s) is used. The destination address is always 00000001. An
  873.     update message contains the entire SSP routing table. The maximum
  874.     packet size is 512byte. Thus, an update message may require several
  875.     packets to be packed.
  876.  
  877.     (3) Triggered Update
  878.  
  879.     When a route in the unicast routing table is changed or a local port
  880.     goes down, the switch advertises a triggered update packet without
  881.     waiting for the full update time. The difference between triggered
  882.     update and the other update is that triggered updates do not have to
  883.     include the entire routing table. Only changed entries should be
  884.     included. Triggered update may be suppressed if a regular periodic
  885.     update is due.
  886.  
  887.     Note that when a route is advertised as unreachable (metric 16) by
  888.     an adjacent switch, update process is triggered as well as
  889.     expiration of the route in the local switch.
  890.  
  891.     (4) On Termination
  892.  
  893.     When a switch goes down, it is desirable to advertise all the routes
  894.     with metric 16, that is, unreachable.
  895.  
  896. 5.4 Receiving Routing Messages
  897.  
  898.  
  899.  
  900.  
  901. Murakami, Maruyama                                             [Page 15]
  902.  
  903. I/D           MAPOS Version 1 Switch-Switch Protocol       April 1997
  904.  
  905.  
  906.    When a switch receives an update, it first checks the version number.
  907.    If it is not 1, the update packet is silently discarded. Otherwise,
  908.    it processes the entries in it one by one.
  909.  
  910.    For each entry, the address family identifier is checked. If it is
  911.    not 2, the entry is ignored. Otherwise, the metric is checked. The
  912.    value should be between 0 and 31.  An entry with illegal metric is
  913.    ignored. Next, the HDLC address and the subnet mask is checked. An
  914.    entry with an invalid address such as broadcast is ignored. If the
  915.    entry passed all these validation checks, it is processed according
  916.    to the following steps;
  917.  
  918.     Step 1 - Process Poisoned Reverse
  919.  
  920.     If the metric value is between 1 and 16, it is an unicast
  921.     information. Go ahead to Step 2.
  922.  
  923.     If the metric value is between 17 and 31, it indicates poisoned
  924.     reverse, that the local switch has been chosen as the next hop for
  925.     the route. However, if the corresponding entry is not included in
  926.     the current routing table or the message is from a port connected to
  927.     its upstream switch, the message is illegal -- ignore it and return
  928.     to Step 1 to process the next entry. Otherwise,
  929.  
  930.  
  931.       (1) Initialize the PORT_EXPIRATION_TIMER corresponding to the
  932.           downstream port.
  933.       (2) Operate the FORWARD_DELAY_TIMER as follows;
  934.           (2-1) If the broadcast/multicast forwarding was already enabled,
  935.                 go to (3).
  936.           (2-2) If the FORWARD_DELAY_TIMER corresponding to the
  937.                 downstream port was already started, increment the
  938.                 timer. If the timer expires, mark the bit in the
  939.                 broadcast/multicast routing table corresponding to the
  940.                 port and stop the timer.
  941.           (2-2) Otherwise, start the FORWARD_DELAY_TIMER.
  942.       (3) Return to Step 1 to process the next entry.
  943.  
  944.  
  945.     Step 2 - Process Unicast Routing Information
  946.  
  947.     First, add the cost associated with the link, usually 1, to the
  948.     metric. If the result is greater than 16, 16 is used. Then, look up
  949.     the unicast routing table for the corresponding entry. There are two
  950.     cases.
  951.  
  952.  
  953.  
  954.  
  955.  
  956.  
  957.  
  958.  
  959.  
  960. Murakami, Maruyama                                             [Page 16]
  961.  
  962. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  963.  
  964.  
  965.  
  966.       Case 1  no corresponding entry is found
  967.  
  968.        If the new metric is 16, return to step 1 to process the next entry.
  969.        Otherwise,
  970.        (1) Create a new route entry in the routing table
  971.        (2) Initialize EXPIRATION_TIMER and GC_TIMER
  972.        (3) The port corresponding to the new route is the next_hop port
  973.            for the route. Thus, mark the bit in the broadcast/multicast
  974.            routing table corresponding to the new next_hop port and start
  975.            FORWARD_DELAY_TIMER. If this new route is for the switch with
  976.            the minimum switch number, select it as the VSS and use its
  977.            broadcast/multicast routing table. (See NOTE 1.)
  978.        (4) Set the route change flag and invoke triggered update process
  979.        (5) Return to step 1 to process the next entry.
  980.  
  981.            [NOTE 1]
  982.              There are two implementations;
  983.               (1) Prepare a spanning tree for each route and use
  984.                   only one corresponding to the current VSS. In
  985.                   this case, each unicast route entry has a
  986.                   broadcast/unicast routing table.
  987.               (2) Prepare only one spanning tree corresponding to the
  988.                   current VSS. In this case, a switch has only one
  989.                   broadcast/multicast routing table.
  990.               In this document, the former is assumed.
  991.  
  992.       Case 2. A corresponding entry is found
  993.  
  994.        In this case, the update message is processed differently according
  995.        to the new metric value.
  996.  
  997.        (a) new_metric < 16 & new_metric > current_metric
  998.  
  999.           (1)If and only if the update is from the same port(next_hop
  1000.              port) as the existing one,
  1001.             (1-1) Update the entry
  1002.             (1-2) Initialize EXPIRATION_TIMER and GC_TIMER
  1003.  
  1004.           (2) If the corresponding bit to the port, which the update
  1005.               message is received, is marked in the broadcast/multicast
  1006.               routing table, clear the bit.
  1007.           (3) Return to Step 1 and process the next entry.
  1008.  
  1009.        (b) new_metric < 16 & new_metric < current_metric
  1010.  
  1011.           (1) Update the entry and clear the bit in the
  1012.               broadcast/multicast routing table corresponding to the old
  1013.               next_hop port.
  1014.           (2) Initialize EXPIRATION_TIMER, GC_TIMER, and PORT_EXPIRATION_TIMER
  1015.               for the new next_hop port.
  1016.  
  1017.  
  1018.  
  1019. Murakami, Maruyama                                             [Page 17]
  1020.  
  1021. I/D             MAPOS Version 1 Switch-Switch Protocol       April 1997
  1022.  
  1023.  
  1024.           (3) Mark a bit in the broadcast/multicast routing table
  1025.               corresponding to the new next_hop port and start
  1026.               FORWARD_DELAY_TIMER.
  1027.           (4) Set the route change flag and invoke triggered update with
  1028.               poisoned reverse for the new next_hop.
  1029.           (5) Return to Step 1 to process the next entry.
  1030.  
  1031.        (c) new_metric < 16 & new_metric = current_metric
  1032.  
  1033.           If a new route with the same metric value as the existing
  1034.           routing table entry is received, use the old one as follows;
  1035.  
  1036.           (1) If the new next hop is equal to the current one, initialize
  1037.               EXPIRATION_TIMER and GC_TIMER. Otherwise, ignore this update.
  1038.           (2) If the bit corresponding to the port, from which the update
  1039.               message was received, is marked in the broadcast/multicast
  1040.               routing table, clear the bit.
  1041.           (3) Return to Step 1 to process the next entry.
  1042.  
  1043.        (d) the new metric = 16 & the new next hop = the current one
  1044.  
  1045.           If the current metric is not equal to 16, this is a new
  1046.           unreachable information. Then,
  1047.           (1) Update the entry and clear the bit in the
  1048.               broadcast/multicast routing table corresponding to the old
  1049.               next_hop port.
  1050.           (2) If this route is for the current VSS, select a new VSS in
  1051.               the valid routing table entries. Valid means that the
  1052.               destination is reachable.
  1053.           (3) Set the route change flag and invoke triggered update
  1054.               process to notify the unreachable route.
  1055.           Otherwise,
  1056.               do nothing and return to Step 1 to process the next entry.
  1057.  
  1058.        (e) the new metric = 16 & the new next hop /= the current one
  1059.  
  1060.           (1) If the bit corresponding to the port, from which the
  1061.               update message was received, is marked in the
  1062.               broadcast/multicast routing table, clear the bit.
  1063.           (2) Return to Step 1 to process the next entry.
  1064.  
  1065.  
  1066. 5.5 Timers
  1067.  
  1068.    The timer routine increments the following timers and executes its
  1069.    associated process on their expiration.
  1070.  
  1071.     (1) EXPIRATION_TIMER and GC_TIMER
  1072.  
  1073.     The EXPIRATION_TIMERs and GC_TIMERs of each entry in the unicast
  1074.     routing table are incremented every FULL_UPDATE_TIME (10 seconds by
  1075.  
  1076.  
  1077.  
  1078. Murakami, Maruyama                                             [Page 18]
  1079.  
  1080. I/D              MAPOS Version 1 Switch-Switch Protocol       April 1997
  1081.  
  1082.  
  1083.     default). When a EXPIRATION_TIMER expires, the metric is changed to
  1084.     unreachable(16), update process is triggered, and GC_TIMER is
  1085.     started. When a GC_TIMER expires, the entry is deleted from the
  1086.     local routing table. EXPIRATION_TIMER and GC_TIMER are cleared every
  1087.     time a switch receives a routing update.
  1088.  
  1089.     (2) FORWARD_DELAY_TIMER
  1090.  
  1091.     FORWARD_DELAY_TIMER is completely handled in the receive process and
  1092.     has no relation to the timer routine.
  1093.  
  1094.     (3) PORT_EXPIRATION_TIMER
  1095.  
  1096.     PORT_EXPIRATION_TIMERs associated with each bit in the
  1097.     broadcast/multicast routing table are incremented every
  1098.     FULL_UPDATE_TIME (10 seconds by default).  When the timer expires,
  1099.     the corresponding downstream switch is considered to be down and the
  1100.     corresponding bit in the broadcast/multicast routing table is
  1101.     cleared. This timer is cleared by the receive process every time a
  1102.     poisoned reverse packet is received from the corresponding switch.
  1103.  
  1104.  
  1105. 6. Further considerations on implementation
  1106.  
  1107. 6.1 Port State
  1108.  
  1109.    A switch assumes that every port is connected to a switch initially.
  1110.    Thus, it sends update packets to every port. When a node is connected
  1111.    to a port, the switch recognizes it by receiving an NSP request
  1112.    packet, and stops sending SSP packets to the port. Whenever a switch
  1113.    detects a connection failure such as loss of signal and out-of-
  1114.    synchronization, it should clear the internal state table
  1115.    corresponding of the port.
  1116.  
  1117. 6.2 Half way connection problem
  1118.  
  1119.    A port consists of two channels, transmit and receive. Although it is
  1120.    easy for a node or a switch to detect a receive channel failure,
  1121.    transmit channel failure may not be detected, causing half way
  1122.    connection.  This results in a black hole.
  1123.  
  1124.    Thus, whenever a switch receives a SSP update packet from a port, it
  1125.    SHOULD check the status of the corresponding transmit channel.
  1126.    SONET/SDH has a feedback mechanism for that purpose. The status of
  1127.    the local transmit channel received at the remote end can be sent
  1128.    back utilizing the overhead part, FEBE(Far End Block Error) and
  1129.    FERF(Far End Receive Failure), of the corresponding receive channel.
  1130.    If the signals indicates that the transmit channel has a problem, the
  1131.    SSP packet received from the remote end should be silently discarded.
  1132.    However, some SONET/SDH services do not provide path overhead
  1133.    transparency.
  1134.  
  1135.  
  1136.  
  1137. Murakami, Maruyama                                             [Page 19]
  1138.  
  1139. I/D          MAPOS Version 1 Switch-Switch Protocol       April 1997
  1140.  
  1141.  
  1142.    Although, SONET/SDH APS(Automatic Protection Switching) can be
  1143.    utilized to switch service from a failed line to a spare line, the
  1144.    function is out of scope of this protocol.
  1145.  
  1146. 7. Security Considerations
  1147.  
  1148.    Security issues are not discussed in this memo.
  1149.  
  1150. References
  1151.  
  1152.    [1]   K. Murakami and M. Maruyama, "MAPOS - Multiple Access Protocol
  1153.          over SONET/SDH Version 1," April 1997.
  1154.  
  1155.    [2]   CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
  1156.          Rates, 1990.
  1157.  
  1158.    [3]   CCITT Recommendation G.708: Network Node Interface for Synchronous
  1159.          Digital Hierarchy, 1990.
  1160.  
  1161.    [4]   CCITT Recommendation G.709: Synchronous Multiplexing Structure,
  1162.          1990.
  1163.  
  1164.    [5]   American National Standard for Telecommunications - Digital
  1165.          Hierarchy - Optical Interface Rates and Formats Specification,
  1166.          ANSI T1.105-1991.
  1167.  
  1168.    [6]   Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058,
  1169.          Rutgers University, June 1988.
  1170.  
  1171.    [7]   G. Malkin., "RIP Version 2 - Carrying Additional Information ",
  1172.          RFC1723, Xylogics, Inc., November 1994.
  1173.  
  1174.    [8]   T. Pusateri, "Distance Vector Multicast Routing Protocol",
  1175.          draft-ietf-idmr-dvmrp-v3-03, September 1996
  1176.  
  1177.    [9]   K. Murakami and M. Maruyama, "A MAPOS version 1 Extension -
  1178.          Node Switch Protocol," April 1997.
  1179.  
  1180.    [10]  M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers,"
  1181.          April, 1997.
  1182.  
  1183.  
  1184. Acknowledgements
  1185.  
  1186.    The authors would like to acknowledge the contributions and
  1187.    thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
  1188.    Kobayashi, Paul Francis, Toshiaki Yoshida, Takahiro Sajima, and
  1189.    Satoru Yagi.
  1190.  
  1191. Authors' Address
  1192.  
  1193.  
  1194.  
  1195.  
  1196. Murakami, Maruyama                                             [Page 20]
  1197.  
  1198. I/D            MAPOS Version 1 Switch-Switch Protocol       April 1997
  1199.  
  1200.  
  1201.  
  1202.              Ken Murakami
  1203.              NTT Software Laboratories
  1204.              3-9-11, Midori-cho
  1205.              Musashino-shi
  1206.              Tokyo 180, Japan
  1207.              E-mail: murakami@ntt-20.ecl.net
  1208.  
  1209.              Mitsuru Maruyama
  1210.              NTT Software Laboratories
  1211.              3-9-11, Midori-cho
  1212.              Musashino-shi
  1213.              Tokyo 180, Japan
  1214.              E-mail: mitsuru@ntt-20.ecl.net
  1215.  
  1216.  
  1217.  
  1218. Murakami, Maruyama                                             [Page 21]
  1219.  
  1220. INTERNET-DRAFT             EXPIRES OCTOBER 1997        INTERNET-DRAFT
  1221.