<?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/rfc2175.txt

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

<rfc number="2175"
     category="info">
<front>
<title abbrev="MAPOS 16">MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing</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>MAPOS</keyword>
<keyword>encapsulate</keyword>
<keyword>synchronous data hierarchy</keyword>
<keyword>synchronous optical network</keyword>
</front>
<middle>
<section title="Abstract">
<t>
   This document describes the protocol MAPOS 16, Multiple Access
   Protocol over SONET/SDH with 16 Bit Addressing, for transmitting
   network-protocol datagrams over SONET/SDH.  The primary difference
   with MAPOS version 1 is that it has 16 bit address field that offers
   significant wide address space. It first describes the major
   differences between MAPOS and MAPOS 16 briefly. Then, it explains the
   header format and its 16 bit address format.
</t>
</section>
<!-- RFC original section: (1.) -->
<section title="Introduction">
<t>
   MAPOS is a multiple access protocol for transmission of High-level
   Datalink Control (HDLC) frames over the Synchronous Optical Network /
   Synchronous Digital Hierarchy(SONET/SDH)<xref target="_XREF_1"/><xref target="_XREF_2"/><xref target="_XREF_3"/><xref target="_XREF_4"/>. It provides
   multiple access capability to SONET/SDH, an inherently point-to-point
   link.
</t>
<t>
   MAPOS version 1<xref target="_XREF_5"/> focuses on the frame format compatibility with the
   conventional PPP<xref target="_XREF_6"/>, resulting with its narrow 8 bit address field.
   In contrast to MAPOS version 1, MAPOS 16 has a 16 bit address space.
   In this document, header format and its 16 bit format are described.
   It also explains that 16 bit addressing has minimal influence on the
   conventional MAPOS protocol family such as Node-Switch Protocol<xref target="_XREF_7"/>
   and Switch-Switch Protocol<xref target="_XREF_8"/>.
</t>
</section>
<!-- RFC original section: (2.) -->
<section title="MAPOS 16 Frame Format">
<t>
   Like MAPOS version 1, MAPOS 16 framing is based on the HDLC-like
   framing used in PPP-over-SONET/SDH, described in RFC-1662<xref target="_XREF_6"/>.
   However, the address field is extended to 16 bits, and the control
   field in the MAPOS version 1 is omitted for maintain the 32bit
   alignment of the header.
</t>
<t>
   Figure 2 shows the MAPOS 16 frame format.  Logical Link Control
   (LLC), and Sublayer/Sub-Network Access Protocol (SNAP) are not used.
   It does not include the bytes for transparency.  The fields are
   transmitted from left to right.
</t>
<figure><artwork>
           +----------+---------------------+----------+
           |          |                     |          |
           |   Flag   |       Address       | Protocol |
           | 01111110 |        16bits       |  16 bits |
           +----------+---------------------+----------+
              +-------------+------------+----------+-----------
              |             |            |          | Inter-frame
              | Information |    FCS     |   Flag   | fill or next
              |             | 16/32 bits | 01111110 | address
              +-------------+------------+----------+------------
</artwork></figure>
<t>
                        Figure 2.  Frame format
</t>
<t>
     Flag Sequence
<list>
<t>
     Flag sequence is used for frame synchronization.  Each frame begins
     and ends with a flag sequence 01111110 (0x7E).  If a frame
     immediately follows another, one flag sequence may be treated as
     the end of the preceding frame and the beginning of the immediately
     following frame.  When the line is idle, the flag sequence is to be
     transmitted continuously on the line.
</t></list>
</t>
<t>
     Address
<list>
<t>
     The address field contains the destination HDLC address.  A frame
     is forwarded by a switch based on this field.  It is 16 bits wide.
     The LSB of the first byte indicates the continuation of this field,
     and must always be 0. The LSB of the second byte indicates the end
     of this field, and must always be 1.  The MSB of the first byte is
     used to indicate if the frame is a unicast or multicast frame.  The
     MSB of 0 means unicast, with the remaining thirteen bits indicating
     the destination node address including two E/A bits. MSB of 1 means
     multicast, with the remaining thirteen bits indicating the group
     address.  The address 0xFEFF means that the frame is a broadcast
     frame. The address (0x0001) is reserved to identify the control
     processor inside a switch.  Frames with an invalid address should
     be silently discarded.
</t></list>
</t>
<figure><artwork>
             +-------------+-+-------------+-+
             | | | | | | | | | | | | | | | | |
             | | node addr |0|  node addr  |1|
             +-+-----------+-+-------------+-+
              ^             ^               ^
              |             |               |
              |             |               +------- EA bit (always 1)
              |             +------- EA bit (always 0)
              1 : broadcast, multicast
              0 : unicast

                        Figure 3 Address format
</artwork></figure>
<t>
     Protocol
<list>
<t>
     The protocol field indicates the protocol to which the datagram
     encapsulated in the information field belongs.  It conforms to the
     ISO 3309 extension mechanism, and the value for this field may be
     obtained from the most recent ``Assigned Numbers&apos;&apos; <xref target="_XREF_9"/> and ``MAPOS
     Version 1 Assigned Numbers&apos;&apos; <xref target="_XREF_10"/>.
</t></list>
</t>
<t>
     Information
<list>
<t>
     The information field contains the datagram for the protocol
     specified in the protocol field.  The length of this field may
     vary, but shall not exceed 65,280 (64K - 256) octets.
</t></list>
</t>
<t>
     Frame Check Sequence (FCS)
<list>
<t>
     By default, the frame check sequence (FCS) field is 16-bits long.
     Optionally, 32 bit FCS may be used instead.  The FCS is calculated
     over all bits of the address, protocol, and information fields
     prior to escape conversions.  The least significant octet of the
     result is transmitted first as it contains the coefficient of the
     highest term.
     Inter-frame fill
</t>
<t>
     A sending station must continuously transmit the flag sequence as
     inter-frame fill after the FCS field.  The inter-frame flag
     sequences must be silently discarded by the receiving station.
     When an under-run occurs during DMA in the sending station, it must
     abort the frame transfer and continuously send the flag sequence to
     indicate the error.
</t></list>
</t>
<!-- RFC original section: (3.2) -->
<section title="Octet-Synchronous Framing">
<t>
   MAPOS 16 uses the same octet stuffing procedure<xref target="_XREF_6"/> as MAPOS version
   1<xref target="_XREF_5"/>. Since SONET/SDH provides transparency, Async-Control-
   Character-Map (ACCM) is not used.  HDLC frames are mapped into the
   SONET/SDH payload as follows.
</t>
<t>
   Each HDLC frame is separated from another frame by one or more flag
   sequence, 01111110 (0x7E).  An escape sequence is defined to escape
   the flag sequence and itself.  Prior to sending the frame, but after
   the FCS computation, every occurrence of 01111110 (0x7E) other than
   the flags is to be converted to the sequence 01111101 01011110 (0x7D
   0x5E), and the sequence 01111101 (0x7D) is to be converted to the
   sequence 01111101 01011101 (0x7D 0x5D).  Upon receiving a frame, this
   conversion must be reversed prior to FCS computation.
</t>
</section>
</section>
<!-- RFC original section: (4.) -->
<section title="Influence on MAPOS ARP, UNARP, NSP, and SSP">
<t>
   Since all of the MAPOS protocol family, ARP<xref target="_XREF_11"/>, UNARP<xref target="_XREF_11"/>, NSP<xref target="_XREF_7"/>,
   and SSP<xref target="_XREF_8"/>, use 32-bit address field for 8-bit MAPOS address, the
   16-bit addressing has no influence on them.  Each protocol only have
   to place a 16 bit address in the least significant place in their 32
   bit address fields as follows;
<list>
<t>
   (1) MAPOS ARP and UNARP
<list>
<t>
    16-bit addresses are placed in the least significant places of the
    32-bit sender and target HDLC addresses.
</t></list>
</t>
<t>
   (2) NSP
<list>
<t>
    In address assignment packet, a 16-bit address is placed in the
    least significant bytes of the 32-bit address field. The rest of the
    field is padded with zeros.
</t></list>
</t>
<t>
   (3) SSP
<list>
<t>
    In route entry of an SSP packet, the 16-bit MAPOS address is placed
    in the least significant bytes of the 32-bit address field.
</t></list>
</t></list>
</t>
</section>
<!-- RFC original section: (5.) -->
<section title="Mapping IP Multicast Address to MAPOS 16 Address">
<t>
   When transmitting IP multicast<xref target="_XREF_11"/>, the thirteen bits of the HDLC
   address must contain the lowest-order thirteen bits of the IP
   multicast group address.  Exceptions arise when these thirteen bits
   are either all zeros or all ones, in which case the address 1111 1110
   1111 1101 should be used.
</t>
</section>
<!-- RFC original section: (6.) -->
<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="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_2">
<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_3">
<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_4">
<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_5">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama,&quot; MAPOS - Multiple Access Protocol over SONET/SDH version 1&quot;</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
<seriesInfo>RFC2171</seriesInfo>
</reference>
<reference anchor="_XREF_6">
<front>
<title>PPP in HDLC-like Framing,&quot;</title>
<author initials="W." surname="Simpson" fullname="W. Simpson">
<organization/>
</author>
<date month="July" year="1994"/>
</front>
<seriesInfo>RFC1662</seriesInfo>
</reference>
<reference anchor="_XREF_7">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama, &quot;A MAPOS version 1 Extension -Node Switch Protocol,&quot;</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
<seriesInfo>RFC2173</seriesInfo>
</reference>
<reference anchor="_XREF_8">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama, &quot;A MAPOS version 1 Extension -Switch Switch Protocol,&quot;</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
<seriesInfo>RFC2174</seriesInfo>
</reference>
<reference anchor="_XREF_9">
<front>
<title abbrev="Reynolds">Reynolds, J. and J. Postel, &quot;ASSIGNED NUMBERS,&quot;</title>
<author>
<organization/>
</author>
<date month="October" year="1994"/>
</front>
<seriesInfo>RFC1700</seriesInfo>
</reference>
<reference anchor="_XREF_10">
<front>
<title abbrev="Maruyama">Maruyama, M. and K. Murakami, &quot;MAPOS Version 1 Assigned Numbers,&quot;</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
<seriesInfo>RFC2172</seriesInfo>
</reference>
<reference anchor="_XREF_11">
<front>
<title abbrev="Murakami">Murakami, K. and M. Maruyama, &quot;IPv4 over MAPOS Version 1,&quot;</title>
<author>
<organization/>
</author>
<date month="June" year="1997"/>
</front>
<seriesInfo>RFC2176</seriesInfo>
</reference>
</references>
<!-- END INCLUDE REFERENCES ** DO NOT REMOVE -->
</back>
</rfc>
