<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>

<!--
     ASCII to XML transformation by Invisible Worlds, Inc.
     http://invisible.net/
     Last transformation: 03-Feb-1999, 02:04:17

     Cannonical version of this document is at:
     http://info.internet.isi.edu/in-notes/rfc/files/rfc2173.txt

     Implementors should verify all content with
     cannonical version.  Failure to do so may result in
     protocol failures.
-->

<rfc number="2173"
     category="info">
<front>
<title abbrev="MAPOS">A MAPOS version 1 Extension - Node Switch Protocol</title>
<author initials="K." surname="Murakami" fullname="Ken Murakami">
<organization>NTT Software Laboratories</organization>
<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo 180</street>
<country>Japan</country>
</postal>
<email>murakami@ntt-20.ecl.net</email>
</address>
</author>
<author initials="M." surname="Maruyama" fullname="Mitsuru Maruyama">
<organization>NTT Software Laboratories</organization>
<address>
<postal>
<street>3-9-11</street>
<street>Midori-cho</street>
<street>Musashino-shi</street>
<street>Tokyo 180</street>
<country>Japan</country>
</postal>
<email>mitsuru@ntt-20.ecl.net</email>
</address>
</author>
<date month="June" year="1997"/>
<area>Internet</area>
<keyword>encapsulate</keyword>
<keyword>synchronous optical network</keyword>
<abstract>
<t>
   This document describes a MAPOS extension, Node Switch Protocol, for
   automatic node address assignment. MAPOS is a multiple access
   protocol for transmission of network-protocol datagrams, encapsulated
   in High-Level Data Link Control (HDLC) frames, over SONET/SDH. NSP
   automates the HDLC address configuration of each node. Using NSP, a
   node retrieves its HDLC address from the switch to which it is
   connected.
</t>
</abstract>
</front>
<middle>
<!-- RFC original section: (1.) -->
<section title="Introduction">
<t>
   MAPOS<xref target="_XREF_1"/>, Multiple Access Protocol over SONET(Synchronous Optical
   Network)/SDH(Synchronous Digital Hierarchy)<xref target="_XREF_2"/><xref target="_XREF_3"/><xref target="_XREF_4"/><xref target="_XREF_5"/>, is a
   protocol for transmission of HDLC frames over SONET/SDH. A SONET
   switch provides multiple access capability to each node. In MAPOS,
   each node has a unique HDLC address within a switch. The address is
   equivalent to the port number of the switch to which the node is
   connected.  This document describes an extension to MAPOS, Node
   Switch Protocol, which enable automatic HDLC address assignment.
   First, it explains the addressing of MAPOS. Then, it describes the
   NSP protocol for automatic HDLC node address assignment.
</t>
</section>
<!-- RFC original section: (2.) -->
<section title="Node Address Format">
<t>
   This section describes MAPOS Version 1 address format in single and
   multiple switch environment.
</t>
<!-- RFC original section: (2.1) -->
<section title="Address Format">
<t>
   In MAPOS network, each end node has a unique HDLC address. As shown
   in Figure 1, the address length is 8 bits. The LSB is always 1 which
   indicates the end of the field.  When a SONET switch receives an HDLC
   frame, it forwards the frame based on the address in the frame
   header.
</t>
<t>
   In unicast, MSB is 0 and the rest of the bits are the port number to
   which a node is connected. Since the LSB is always 1, the minimum and
   maximum addresses are 0x01 and 0x7F, respectively.  Address 0x01 is
   reserved and is assigned to the control processor in a SONET switch.
</t>
<t>
   In broadcast, MSB is 1 and the rest of the bits are all 1s. In
   multicast, MSB is 1 and the rest of the bits, except for the LSB,
   indicate the group address.
</t>
<figure><artwork>
           +-------------+-+
           | | | | | | | | |
           | |port number|1|
           +-+-----------+-+
            ^             ^
            |             |
            |             +------- EA bit (always 1)
            |
            1 : broadcast, multicast
            0 : unicast

                              Figure 1 Address format
</artwork></figure>
</section>
<!-- RFC original section: (2.2) -->
<section title="Address in multi-switch environment">
<t>
   In a multi-switch environment, variable-length subnet addressing is
   used. Each switch has a switch number that is unique within the
   system. Subnetted node addresses consist of the switch number and the
   port number to which a node is connected. The address format is &quot;0
   &lt;switch number&gt; &lt;node number&gt; 1&quot; for a unicast address, &quot;all 1&quot; for
   the broadcast address, and &quot;1 &lt;group address&gt; 1&quot; for a multicast
   address.
</t>
<t>
   The address 0x01 is reserved and is assigned to the control processor
   in the &quot;local&quot; switch. That is, it indicates the switch itself to
   which the node is connected. The addresses of the form &quot;0 &lt;switch
   number&gt; &lt;all 0&gt; 1&quot; are reserved, and indicates the control processor
   of the switch designated by the switch number.
</t>
<t>
   In Figure 2, the switch numbers are two bits long. Node N1 is
   connected to port 0x3 of switch S1 numbered 0x1 (01 in binary). Thus,
   the node address is 0 + 01 + 00011, that is, 00100011(0x23). Node N3
   has an address 01001001(0x49), since the switch number of S2 is 0x2
   (10 in binary) and the port number is 0x09. Note that all the port
   numbers are odd because the LSBs are always 1.
</t>
<figure><artwork>
                           +------+
                           | node |
                           |  N1  |
                           +------+
                               | 00100011(0x23)
                               |
                               |0x3             |0x3
               +------+    +---+----+       +---+----+     +------+
               | node +----+ SONET  +-------+ SONET  +-----+ node |
               |  N2  | 0x5| Switch |0x9 0x5| Switch |0x9  |  N3  |
               +------+    |   S1   |       |   S2   |     +------+
           00100101(0x25)  |  0x1   |       |  0x2   |   01001001(0x49)
                           +---+----+       +---+----+
                               |0x7             |0x7

          Figure 2  Addressing in Multiple Switch Environment
</artwork></figure>
</section>
</section>
<!-- RFC original section: (4) -->
<section title="NSP(Node-Switch Protocol)">
<t>
   This section describes the NSP protocol used for automatic node
   address assignment.
</t>
<!-- RFC original section: (4.1) -->
<section title="NSP protocol">
<t>
   NSP is introduced to provide an automatic node address assignment
   function in MAPOS version 1. It reduces the administrative overhead
   of node address configuration for each node and prevents troubles
   such as address inconsistency and collision. When a node is connected
   to a switch and receives SONET signal correctly, the node sends an
   address request packet to the control processor in the local switch.
   The destination address of this packet is 00000001(0x01). When the
   control processor receives the packet, it replies with an address
   assignment packet. The destination is the assigned node address. If
   the node does not receive the address assignment packet within 5
   seconds, it retransmits the address request packet. The
   retransmission continues until the node successfully receives the
   address assignment packet.
</t>
<t>
   Whenever a node detects a transmission error such as carrier loss or
   out-of-synchronization, it SHOULD send an address request packet to
   the control processor and verify its current address. In addition, a
   node MUST verify its address by sending address request packets every
   30 seconds. The switch regards them as keep-alive packets and
   utilizes them to detect the node&apos;s status. If it has not received a
   request packet for more than 90 seconds, it assumes that the node
   went down.  In addition, it also assumes the node went down when a
   switch detects a SONET signal failure.
</t>
</section>
<!-- RFC original section: (4.2) -->
<section title="Packet Format">
<t>
   The HDLC protocol field of a NSP frame contains 0xFE03 (hexadecimal)
   as defined by the &quot;MAPOS Version 1 Assigned Numbers&quot; <xref target="_XREF_6"/>. The
   information field contains the NSP packet as shown in Figure 3.
</t>
<figure><artwork>
           +-----------+------------+
           I  command  I  address   I
           +-----------+------------+
           I&lt;- 32bit -&gt;I&lt;- 32 bit -&gt;I

                      Figure 3  NSP packet format
</artwork></figure>
<t>
   The command field is 32 bits long and has the following values (in
   decimal);
</t>
<figure><artwork>
           1       address request
           2       address assignment
           3       reject(error)
</artwork></figure>
<t>
   The length of the address field is 32bits. In address request
   packets, the NSP address field SHOULD be filled with zeroes, although
   the switch ignores it. In address assignment packets, the assigned
   address is placed in the least significant byte of the field. The
   rest of the field is padded with zeroes. When the switch can not
   assign the address for some reason, the switch replies with a reject
   command (the values is 3). The value of the address field is
   undefined.
</t>
</section>
<!-- RFC original section: (4.3) -->
<section title="Consideration for special cases">
<t>
   There are two special cases to consider. One is a point-to-point
   connection without a switch. The other is loop-back, that is, direct
   connection between the input and the output of the same port.
</t>
<!-- RFC original section: (4.3.1) -->
<section title="point-to-point">
<t>
   In the case of a point-to-point connection shown in Figure 4, a node
   sends an address request packet to the other node. The destination
   address is 00000001(0x01), that is usually a control processor in a
   switch. When a node receives the address request, it detects the
   point-to-point connection by examining both the destination address
   and the command contained.  Then, it MUST reply with an address
   assignment packet. The assigned address MUST be 00000011(0x03). Since
   both nodes send an address request to each other, both of them get
   address 00000011(0x03). Since any address can be used in point-to-
   point environment, there is no problem even if both of the nodes have
   the same address.
</t>
<figure><artwork>
                   ---- address request ----&gt; 0x01
                      0x03 &lt;---- address assignment ----
           +------+                                +------+
           | node +--------------------------------+ node |
           +------+                                +------+
                      0x01 &lt;---- address request ----
                   ---- address assignment ----&gt; 0x03

                   Figure 4 Point-to-point connection
</artwork></figure>
</section>
<!-- RFC original section: (4.3.2) -->
<section title="loop-back">
<t>
   Another special case is loop-back where the output port of a node is
   simply connected to its input port as shown in Figure 5. In this
   case, the same mechanism as that for point-to-point can be applied
   without modification.  A node sends an address request packet
   destined to 00000001(0x01). The node then receives the same packet.
   Since the destination is 00000001(0x01), it replies with an address
   assignment packet, containing the assigned address 00000011(0x03), to
   the address 0000 0011(0x03).  Thus, the node obtains the address
   00000011(0x03).
</t>
<figure><artwork>
                     ---- address request ----&gt; 0x01
           +------+  --- address assignment --&gt; 0x03
           |      +--------------&gt;-----------------+
           | node +                                |
           |      +--------------&lt;-----------------+
           +------+

                    Figure 5 Loop-back Configuration
</artwork></figure>
</section>
</section>
</section>
<!-- RFC original section: (5.) -->
<section title="Security Considerations">
<t>
   Security issues are not discussed in this memo.
</t>
</section>
<section title="Acknowledgements">
<t>
   The authors would like to acknowledge the contributions and
   thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
   Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
</t>
</section>
</middle>
<back>
<!-- BEGIN INCLUDE REFERENCES ** DO NOT REMOVE -->
<references>
<reference anchor="_XREF_1">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama, &quot;MAPOS - Multiple Access Protocol over SONET/SDH, Version 1,&quot; RFC-2171</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
</reference>
<reference anchor="_XREF_2">
<front>
<title abbrev="CCITT Recommendation G.707: Synchronous Digital">CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit Rates (1990</title>
<author>
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="_XREF_3">
<front>
<title abbrev="CCITT Recommendation G.708: Network Node Interface">CCITT Recommendation G.708: Network Node Interface for Synchronous Digital Hierarchy (1990</title>
<author>
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="_XREF_4">
<front>
<title abbrev="CCITT Recommendation G.709: Synchronous Multiplexing">CCITT Recommendation G.709: Synchronous Multiplexing Structure (1990</title>
<author>
<organization/>
</author>
<date month="" year=""/>
</front>
</reference>
<reference anchor="_XREF_5">
<front>
<title abbrev="American National Standard for Telecommunications">American National Standard for Telecommunications - Digital Hierarchy - Optical Interface Rates and Formats Specification, ANSI T1.105</title>
<author>
<organization/>
</author>
<date month="" year="1991"/>
</front>
</reference>
<reference anchor="_XREF_6">
<front>
<title abbrev="Maruyama">Maruyama, M. and K. Murakami, &quot;MAPOS Version 1 Assigned Numbers,&quot; RFC-2172</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
</reference>
</references>
<!-- END INCLUDE REFERENCES ** DO NOT REMOVE -->
</back>
</rfc>
