home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2173.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  12.0 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        K. Murakami
  8. Request for Comments: 2173                                   M. Maruyama
  9. Category: Informational                                 NTT Laboratories
  10.                                                                June 1997
  11.  
  12.  
  13.            A MAPOS version 1 Extension - Node Switch Protocol
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  This memo
  18.    does not specify an Internet standard of any kind.  Distribution of
  19.    this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    This document describes a MAPOS extension, Node Switch Protocol, for
  24.    automatic node address assignment. MAPOS is a multiple access
  25.    protocol for transmission of network-protocol datagrams, encapsulated
  26.    in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP
  27.    automates the HDLC address configuration of each node. Using NSP, a
  28.    node retrieves its HDLC address from the switch to which it is
  29.    connected.
  30.  
  31. 1. Introduction
  32.  
  33.    MAPOS[1], Multiple Access Protocol over SONET(Synchronous Optical
  34.    Network)/SDH(Synchronous Digital Hierarchy)[2][3][4][5], is a
  35.    protocol for transmission of HDLC frames over SONET/SDH. A SONET
  36.    switch provides multiple access capability to each node. In MAPOS,
  37.    each node has a unique HDLC address within a switch. The address is
  38.    equivalent to the port number of the switch to which the node is
  39.    connected.  This document describes an extension to MAPOS, Node
  40.    Switch Protocol, which enable automatic HDLC address assignment.
  41.    First, it explains the addressing of MAPOS. Then, it describes the
  42.    NSP protocol for automatic HDLC node address assignment.
  43.  
  44. 2. Node Address Format
  45.  
  46.    This section describes MAPOS Version 1 address format in single and
  47.    multiple switch environment.
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Murakami & Maruyama          Informational                      [Page 1]
  59.  
  60. RFC 2173                         MAPOS                         June 1997
  61.  
  62.  
  63. 2.1 Address Format
  64.  
  65.    In MAPOS network, each end node has a unique HDLC address. As shown
  66.    in Figure 1, the address length is 8 bits. The LSB is always 1 which
  67.    indicates the end of the field.  When a SONET switch receives an HDLC
  68.    frame, it forwards the frame based on the address in the frame
  69.    header.
  70.  
  71.    In unicast, MSB is 0 and the rest of the bits are the port number to
  72.    which a node is connected. Since the LSB is always 1, the minimum and
  73.    maximum addresses are 0x01 and 0x7F, respectively.  Address 0x01 is
  74.    reserved and is assigned to the control processor in a SONET switch.
  75.  
  76.    In broadcast, MSB is 1 and the rest of the bits are all 1s. In
  77.    multicast, MSB is 1 and the rest of the bits, except for the LSB,
  78.    indicate the group address.
  79.  
  80.            +-------------+-+
  81.            | | | | | | | | |
  82.            | |port number|1|
  83.            +-+-----------+-+
  84.             ^             ^
  85.             |             |
  86.             |             +------- EA bit (always 1)
  87.             |
  88.             1 : broadcast, multicast
  89.             0 : unicast
  90.  
  91.                               Figure 1 Address format
  92.  
  93. 2.2 Address in multi-switch environment
  94.  
  95.    In a multi-switch environment, variable-length subnet addressing is
  96.    used. Each switch has a switch number that is unique within the
  97.    system. Subnetted node addresses consist of the switch number and the
  98.    port number to which a node is connected. The address format is "0
  99.    <switch number> <node number> 1" for a unicast address, "all 1" for
  100.    the broadcast address, and "1 <group address> 1" for a multicast
  101.    address.
  102.  
  103.    The address 0x01 is reserved and is assigned to the control processor
  104.    in the "local" switch. That is, it indicates the switch itself to
  105.    which the node is connected. The addresses of the form "0 <switch
  106.    number> <all 0> 1" are reserved, and indicates the control processor
  107.    of the switch designated by the switch number.
  108.  
  109.    In Figure 2, the switch numbers are two bits long. Node N1 is
  110.    connected to port 0x3 of switch S1 numbered 0x1 (01 in binary). Thus,
  111.  
  112.  
  113.  
  114. Murakami & Maruyama          Informational                      [Page 2]
  115.  
  116. RFC 2173                         MAPOS                         June 1997
  117.  
  118.  
  119.    the node address is 0 + 01 + 00011, that is, 00100011(0x23). Node N3
  120.    has an address 01001001(0x49), since the switch number of S2 is 0x2
  121.    (10 in binary) and the port number is 0x09. Note that all the port
  122.    numbers are odd because the LSBs are always 1.
  123.  
  124.                            +------+
  125.                            | node |
  126.                            |  N1  |
  127.                            +------+
  128.                                | 00100011(0x23)
  129.                                |
  130.                                |0x3             |0x3
  131.                +------+    +---+----+       +---+----+     +------+
  132.                | node +----+ SONET  +-------+ SONET  +-----+ node |
  133.                |  N2  | 0x5| Switch |0x9 0x5| Switch |0x9  |  N3  |
  134.                +------+    |   S1   |       |   S2   |     +------+
  135.            00100101(0x25)  |  0x1   |       |  0x2   |   01001001(0x49)
  136.                            +---+----+       +---+----+
  137.                                |0x7             |0x7
  138.  
  139.  
  140.           Figure 2  Addressing in Multiple Switch Environment
  141.  
  142. 4 NSP(Node-Switch Protocol)
  143.  
  144.    This section describes the NSP protocol used for automatic node
  145.    address assignment.
  146.  
  147. 4.1 NSP protocol
  148.  
  149.    NSP is introduced to provide an automatic node address assignment
  150.    function in MAPOS version 1. It reduces the administrative overhead
  151.    of node address configuration for each node and prevents troubles
  152.    such as address inconsistency and collision. When a node is connected
  153.    to a switch and receives SONET signal correctly, the node sends an
  154.    address request packet to the control processor in the local switch.
  155.    The destination address of this packet is 00000001(0x01). When the
  156.    control processor receives the packet, it replies with an address
  157.    assignment packet. The destination is the assigned node address. If
  158.    the node does not receive the address assignment packet within 5
  159.    seconds, it retransmits the address request packet. The
  160.    retransmission continues until the node successfully receives the
  161.    address assignment packet.
  162.  
  163.    Whenever a node detects a transmission error such as carrier loss or
  164.    out-of-synchronization, it SHOULD send an address request packet to
  165.    the control processor and verify its current address. In addition, a
  166.    node MUST verify its address by sending address request packets every
  167.  
  168.  
  169.  
  170. Murakami & Maruyama          Informational                      [Page 3]
  171.  
  172. RFC 2173                         MAPOS                         June 1997
  173.  
  174.  
  175.    30 seconds. The switch regards them as keep-alive packets and
  176.    utilizes them to detect the node's status. If it has not received a
  177.    request packet for more than 90 seconds, it assumes that the node
  178.    went down.  In addition, it also assumes the node went down when a
  179.    switch detects a SONET signal failure.
  180.  
  181. 4.2 Packet Format
  182.  
  183.    The HDLC protocol field of a NSP frame contains 0xFE03 (hexadecimal)
  184.    as defined by the "MAPOS Version 1 Assigned Numbers" [6]. The
  185.    information field contains the NSP packet as shown in Figure 3.
  186.  
  187.  
  188.            +-----------+------------+
  189.            I  command  I  address   I
  190.            +-----------+------------+
  191.            I<- 32bit ->I<- 32 bit ->I
  192.  
  193.                       Figure 3  NSP packet format
  194.  
  195.    The command field is 32 bits long and has the following values (in
  196.    decimal);
  197.  
  198.            1       address request
  199.            2       address assignment
  200.            3       reject(error)
  201.  
  202.    The length of the address field is 32bits. In address request
  203.    packets, the NSP address field SHOULD be filled with zeroes, although
  204.    the switch ignores it. In address assignment packets, the assigned
  205.    address is placed in the least significant byte of the field. The
  206.    rest of the field is padded with zeroes. When the switch can not
  207.    assign the address for some reason, the switch replies with a reject
  208.    command (the values is 3). The value of the address field is
  209.    undefined.
  210.  
  211. 4.3 Consideration for special cases
  212.  
  213.    There are two special cases to consider. One is a point-to-point
  214.    connection without a switch. The other is loop-back, that is, direct
  215.    connection between the input and the output of the same port.
  216.  
  217. 4.3.1 point-to-point
  218.  
  219.    In the case of a point-to-point connection shown in Figure 4, a node
  220.    sends an address request packet to the other node. The destination
  221.    address is 00000001(0x01), that is usually a control processor in a
  222.    switch. When a node receives the address request, it detects the
  223.  
  224.  
  225.  
  226. Murakami & Maruyama          Informational                      [Page 4]
  227.  
  228. RFC 2173                         MAPOS                         June 1997
  229.  
  230.  
  231.    point-to-point connection by examining both the destination address
  232.    and the command contained.  Then, it MUST reply with an address
  233.    assignment packet. The assigned address MUST be 00000011(0x03). Since
  234.    both nodes send an address request to each other, both of them get
  235.    address 00000011(0x03). Since any address can be used in point-to-
  236.    point environment, there is no problem even if both of the nodes have
  237.    the same address.
  238.  
  239.                    ---- address request ----> 0x01
  240.                       0x03 <---- address assignment ----
  241.            +------+                                +------+
  242.            | node +--------------------------------+ node |
  243.            +------+                                +------+
  244.                       0x01 <---- address request ----
  245.                    ---- address assignment ----> 0x03
  246.  
  247.                    Figure 4 Point-to-point connection
  248.  
  249. 4.3.2 loop-back
  250.  
  251.    Another special case is loop-back where the output port of a node is
  252.    simply connected to its input port as shown in Figure 5. In this
  253.    case, the same mechanism as that for point-to-point can be applied
  254.    without modification.  A node sends an address request packet
  255.    destined to 00000001(0x01). The node then receives the same packet.
  256.    Since the destination is 00000001(0x01), it replies with an address
  257.    assignment packet, containing the assigned address 00000011(0x03), to
  258.    the address 0000 0011(0x03).  Thus, the node obtains the address
  259.    00000011(0x03).
  260.  
  261.                      ---- address request ----> 0x01
  262.            +------+  --- address assignment --> 0x03
  263.            |      +-------------->-----------------+
  264.            | node +                                |
  265.            |      +--------------<-----------------+
  266.            +------+
  267.  
  268.                     Figure 5 Loop-back Configuration
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Murakami & Maruyama          Informational                      [Page 5]
  283.  
  284. RFC 2173                         MAPOS                         June 1997
  285.  
  286.  
  287. 5. Security Considerations
  288.  
  289.    Security issues are not discussed in this memo.
  290.  
  291. References
  292.  
  293.    [1]   Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
  294.          over SONET/SDH, Version 1," RFC-2171, June 1997.
  295.  
  296.    [2]   CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
  297.          Rates (1990).
  298.  
  299.    [3]   CCITT Recommendation G.708: Network Node Interface for
  300.          Synchronous Digital Hierarchy (1990).
  301.  
  302.    [4]   CCITT Recommendation G.709: Synchronous Multiplexing Structure
  303.          (1990).
  304.  
  305.    [5]   American National Standard for Telecommunications - Digital
  306.          Hierarchy - Optical Interface Rates and Formats Specification,
  307.          ANSI T1.105-1991.
  308.  
  309.    [6]   Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
  310.          Numbers," RFC-2172, June, 1997.
  311.  
  312. Acknowledgements
  313.  
  314.    The authors would like to acknowledge the contributions and
  315.    thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
  316.    Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
  317.  
  318. Authors' Address
  319.  
  320.      Ken Murakami
  321.      NTT Software Laboratories
  322.      3-9-11, Midori-cho
  323.      Musashino-shi
  324.      Tokyo 180, Japan
  325.      E-mail: murakami@ntt-20.ecl.net
  326.  
  327.      Mitsuru Maruyama
  328.      NTT Software Laboratories
  329.      3-9-11, Midori-cho
  330.      Musashino-shi
  331.      Tokyo 180, Japan
  332.      E-mail: mitsuru@ntt-20.ecl.net
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Murakami & Maruyama          Informational                      [Page 6]
  339.  
  340.