home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2175.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  11.4 KB  |  340 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        K. Murakami
  8. Request for Comments: 2175                                   M. Maruyama
  9. Category: Informational                                 NTT Laboratories
  10.                                                                June 1997
  11.  
  12.  
  13.                MAPOS 16 - Multiple Access Protocol over
  14.                     SONET/SDH with 16 Bit Addressing
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Authors' note
  23.  
  24.    This memo documents MAPOS 16, a multiple access protocol for
  25.    transmission of network-protocol datagrams, encapsulated in HDLC
  26.    frames with 16 bit addressing, over SONET/SDH.  The primary
  27.    difference with MAPOS version 1 is that it has 16 bit address field
  28.    that offers significant wide address space. This document is NOT the
  29.    product of an IETF working group nor is it a standards track
  30.    document.  It has not necessarily benefited from the widespread and
  31.    in depth community review that standards track documents receive.
  32.  
  33. Abstract
  34.  
  35.    This document describes the protocol MAPOS 16, Multiple Access
  36.    Protocol over SONET/SDH with 16 Bit Addressing, for transmitting
  37.    network-protocol datagrams over SONET/SDH.  The primary difference
  38.    with MAPOS version 1 is that it has 16 bit address field that offers
  39.    significant wide address space. It first describes the major
  40.    differences between MAPOS and MAPOS 16 briefly. Then, it explains the
  41.    header format and its 16 bit address format.
  42.  
  43. 1. Introduction
  44.  
  45.    MAPOS is a multiple access protocol for transmission of High-level
  46.    Datalink Control (HDLC) frames over the Synchronous Optical Network /
  47.    Synchronous Digital Hierarchy(SONET/SDH)[1][2][3][4]. It provides
  48.    multiple access capability to SONET/SDH, an inherently point-to-point
  49.    link.
  50.  
  51.    MAPOS version 1[5] focuses on the frame format compatibility with the
  52.    conventional PPP[6], resulting with its narrow 8 bit address field.
  53.    In contrast to MAPOS version 1, MAPOS 16 has a 16 bit address space.
  54.  
  55.  
  56.  
  57.  
  58. Murakami & Maruyama          Informational                      [Page 1]
  59.  
  60. RFC 2175                        MAPOS 16                       June 1997
  61.  
  62.  
  63.    In this document, header format and its 16 bit format are described.
  64.    It also explains that 16 bit addressing has minimal influence on the
  65.    conventional MAPOS protocol family such as Node-Switch Protocol[7]
  66.    and Switch-Switch Protocol[8].
  67.  
  68. 2. MAPOS 16 Frame Format
  69.  
  70.    Like MAPOS version 1, MAPOS 16 framing is based on the HDLC-like
  71.    framing used in PPP-over-SONET/SDH, described in RFC-1662[6].
  72.    However, the address field is extended to 16 bits, and the control
  73.    field in the MAPOS version 1 is omitted for maintain the 32bit
  74.    alignment of the header.
  75.  
  76.    Figure 2 shows the MAPOS 16 frame format.  Logical Link Control
  77.    (LLC), and Sublayer/Sub-Network Access Protocol (SNAP) are not used.
  78.    It does not include the bytes for transparency.  The fields are
  79.    transmitted from left to right.
  80.  
  81.  
  82.            +----------+---------------------+----------+
  83.            |          |                     |          |
  84.            |   Flag   |       Address       | Protocol |
  85.            | 01111110 |        16bits       |  16 bits |
  86.            +----------+---------------------+----------+
  87.               +-------------+------------+----------+-----------
  88.               |             |            |          | Inter-frame
  89.               | Information |    FCS     |   Flag   | fill or next
  90.               |             | 16/32 bits | 01111110 | address
  91.               +-------------+------------+----------+------------
  92.  
  93.                         Figure 2.  Frame format
  94.  
  95.      Flag Sequence
  96.  
  97.      Flag sequence is used for frame synchronization.  Each frame begins
  98.      and ends with a flag sequence 01111110 (0x7E).  If a frame
  99.      immediately follows another, one flag sequence may be treated as
  100.      the end of the preceding frame and the beginning of the immediately
  101.      following frame.  When the line is idle, the flag sequence is to be
  102.      transmitted continuously on the line.
  103.  
  104.      Address
  105.  
  106.      The address field contains the destination HDLC address.  A frame
  107.      is forwarded by a switch based on this field.  It is 16 bits wide.
  108.      The LSB of the first byte indicates the continuation of this field,
  109.      and must always be 0. The LSB of the second byte indicates the end
  110.      of this field, and must always be 1.  The MSB of the first byte is
  111.  
  112.  
  113.  
  114. Murakami & Maruyama          Informational                      [Page 2]
  115.  
  116. RFC 2175                        MAPOS 16                       June 1997
  117.  
  118.  
  119.      used to indicate if the frame is a unicast or multicast frame.  The
  120.      MSB of 0 means unicast, with the remaining thirteen bits indicating
  121.      the destination node address including two E/A bits. MSB of 1 means
  122.      multicast, with the remaining thirteen bits indicating the group
  123.      address.  The address 0xFEFF means that the frame is a broadcast
  124.      frame. The address (0x0001) is reserved to identify the control
  125.      processor inside a switch.  Frames with an invalid address should
  126.      be silently discarded.
  127.  
  128.              +-------------+-+-------------+-+
  129.              | | | | | | | | | | | | | | | | |
  130.              | | node addr |0|  node addr  |1|
  131.              +-+-----------+-+-------------+-+
  132.               ^             ^               ^
  133.               |             |               |
  134.               |             |               +------- EA bit (always 1)
  135.               |             +------- EA bit (always 0)
  136.               1 : broadcast, multicast
  137.               0 : unicast
  138.  
  139.                         Figure 3 Address format
  140.  
  141.  
  142.  
  143.      Protocol
  144.  
  145.      The protocol field indicates the protocol to which the datagram
  146.      encapsulated in the information field belongs.  It conforms to the
  147.      ISO 3309 extension mechanism, and the value for this field may be
  148.      obtained from the most recent ``Assigned Numbers'' [9] and ``MAPOS
  149.      Version 1 Assigned Numbers'' [10].
  150.  
  151.      Information
  152.  
  153.      The information field contains the datagram for the protocol
  154.      specified in the protocol field.  The length of this field may
  155.      vary, but shall not exceed 65,280 (64K - 256) octets.
  156.  
  157.      Frame Check Sequence (FCS)
  158.  
  159.      By default, the frame check sequence (FCS) field is 16-bits long.
  160.      Optionally, 32 bit FCS may be used instead.  The FCS is calculated
  161.      over all bits of the address, protocol, and information fields
  162.      prior to escape conversions.  The least significant octet of the
  163.      result is transmitted first as it contains the coefficient of the
  164.      highest term.
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Murakami & Maruyama          Informational                      [Page 3]
  171.  
  172. RFC 2175                        MAPOS 16                       June 1997
  173.  
  174.  
  175.      Inter-frame fill
  176.  
  177.      A sending station must continuously transmit the flag sequence as
  178.      inter-frame fill after the FCS field.  The inter-frame flag
  179.      sequences must be silently discarded by the receiving station.
  180.      When an under-run occurs during DMA in the sending station, it must
  181.      abort the frame transfer and continuously send the flag sequence to
  182.      indicate the error.
  183.  
  184. 3.2 Octet-Synchronous Framing
  185.  
  186.    MAPOS 16 uses the same octet stuffing procedure[6] as MAPOS version
  187.    1[5]. Since SONET/SDH provides transparency, Async-Control-
  188.    Character-Map (ACCM) is not used.  HDLC frames are mapped into the
  189.    SONET/SDH payload as follows.
  190.  
  191.    Each HDLC frame is separated from another frame by one or more flag
  192.    sequence, 01111110 (0x7E).  An escape sequence is defined to escape
  193.    the flag sequence and itself.  Prior to sending the frame, but after
  194.    the FCS computation, every occurrence of 01111110 (0x7E) other than
  195.    the flags is to be converted to the sequence 01111101 01011110 (0x7D
  196.    0x5E), and the sequence 01111101 (0x7D) is to be converted to the
  197.    sequence 01111101 01011101 (0x7D 0x5D).  Upon receiving a frame, this
  198.    conversion must be reversed prior to FCS computation.
  199.  
  200. 4. Influence on MAPOS ARP, UNARP, NSP, and SSP
  201.  
  202.    Since all of the MAPOS protocol family, ARP[11], UNARP[11], NSP[7],
  203.    and SSP[8], use 32-bit address field for 8-bit MAPOS address, the
  204.    16-bit addressing has no influence on them.  Each protocol only have
  205.    to place a 16 bit address in the least significant place in their 32
  206.    bit address fields as follows;
  207.  
  208.    (1) MAPOS ARP and UNARP
  209.     16-bit addresses are placed in the least significant places of the
  210.     32-bit sender and target HDLC addresses.
  211.  
  212.    (2) NSP
  213.     In address assignment packet, a 16-bit address is placed in the
  214.     least significant bytes of the 32-bit address field. The rest of the
  215.     field is padded with zeros.
  216.  
  217.    (3) SSP
  218.     In route entry of an SSP packet, the 16-bit MAPOS address is placed
  219.     in the least significant bytes of the 32-bit address field.
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Murakami & Maruyama          Informational                      [Page 4]
  227.  
  228. RFC 2175                        MAPOS 16                       June 1997
  229.  
  230.  
  231. 5. Mapping IP Multicast Address to MAPOS 16 Address
  232.  
  233.    When transmitting IP multicast[11], the thirteen bits of the HDLC
  234.    address must contain the lowest-order thirteen bits of the IP
  235.    multicast group address.  Exceptions arise when these thirteen bits
  236.    are either all zeros or all ones, in which case the address 1111 1110
  237.    1111 1101 should be used.
  238.  
  239. 6. Security Considerations
  240.  
  241.    Security issues are not discussed in this memo.
  242.  
  243. References
  244.  
  245.    [1]  CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
  246.         Rates (1990).
  247.  
  248.    [2]  CCITT Recommendation G.708: Network Node Interface for
  249.         Synchronous Digital Hierarchy (1990).
  250.  
  251.    [3]  CCITT Recommendation G.709: Synchronous Multiplexing Structure
  252.         (1990).
  253.  
  254.    [4]  American National Standard for Telecommunications - Digital
  255.         Hierarchy - Optical Interface Rates and Formats Specification,
  256.         ANSI T1.105-1991.
  257.  
  258.    [5]  Murakami, K. and M. Maruyama, " MAPOS - Multiple Access Protocol
  259.         over SONET/SDH version 1", RFC2171, June, 1997.
  260.  
  261.    [6]  Simpson, W., editor, "PPP in HDLC-like Framing," RFC1662, July
  262.         1994.
  263.  
  264.    [7]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
  265.         Node Switch Protocol," RFC2173, June, 1997.
  266.  
  267.    [8]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
  268.         Switch Switch Protocol," RFC2174, June, 1997.
  269.  
  270.    [9]  Reynolds, J. and J. Postel, "ASSIGNED NUMBERS," RFC1700, Oct.
  271.         1994.
  272.  
  273.    [10] Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
  274.         Numbers," RFC2172, June, 1997.
  275.  
  276.    [11] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
  277.         RFC2176, June, 1997.
  278.  
  279.  
  280.  
  281.  
  282. Murakami & Maruyama          Informational                      [Page 5]
  283.  
  284. RFC 2175                        MAPOS 16                       June 1997
  285.  
  286.  
  287. Acknowledgements
  288.  
  289.    The authors would like to acknowledge the contributions and
  290.    thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki
  291.    Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima.
  292.  
  293. Author's Address
  294.  
  295.              Ken Murakami
  296.              NTT Software Laboratories
  297.              3-9-11, Midori-cho
  298.              Musashino-shi
  299.              Tokyo-180, Japan
  300.              E-mail: murakami@ntt-20.ecl.net
  301.  
  302.              Mitsuru Maruyama
  303.              NTT Software Laboratories
  304.              3-9-11, Midori-cho
  305.              Musashino-shi
  306.              Tokyo-180, Japan
  307.              E-mail: mitsuru@ntt-20.ecl.net
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Murakami & Maruyama          Informational                      [Page 6]
  339.  
  340.