doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2175.txt b/doc/rfc/rfc2175.txt
new file mode 100644
index 0000000..28b9876
--- /dev/null
+++ b/doc/rfc/rfc2175.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        K. Murakami
+Request for Comments: 2175                                   M. Maruyama
+Category: Informational                                 NTT Laboratories
+                                                               June 1997
+
+
+               MAPOS 16 - Multiple Access Protocol over
+                    SONET/SDH with 16 Bit Addressing
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Authors' note
+
+   This memo documents MAPOS 16, a multiple access protocol for
+   transmission of network-protocol datagrams, encapsulated in HDLC
+   frames with 16 bit addressing, over SONET/SDH.  The primary
+   difference with MAPOS version 1 is that it has 16 bit address field
+   that offers significant wide address space. This document is NOT the
+   product of an IETF working group nor is it a standards track
+   document.  It has not necessarily benefited from the widespread and
+   in depth community review that standards track documents receive.
+
+Abstract
+
+   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.
+
+1. Introduction
+
+   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)[1][2][3][4]. It provides
+   multiple access capability to SONET/SDH, an inherently point-to-point
+   link.
+
+   MAPOS version 1[5] focuses on the frame format compatibility with the
+   conventional PPP[6], resulting with its narrow 8 bit address field.
+   In contrast to MAPOS version 1, MAPOS 16 has a 16 bit address space.
+
+
+
+
+Murakami & Maruyama          Informational                      [Page 1]
+
+RFC 2175                        MAPOS 16                       June 1997
+
+
+   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[7]
+   and Switch-Switch Protocol[8].
+
+2. MAPOS 16 Frame Format
+
+   Like MAPOS version 1, MAPOS 16 framing is based on the HDLC-like
+   framing used in PPP-over-SONET/SDH, described in RFC-1662[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.
+
+   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.
+
+
+           +----------+---------------------+----------+
+           |          |                     |          |
+           |   Flag   |       Address       | Protocol |
+           | 01111110 |        16bits       |  16 bits |
+           +----------+---------------------+----------+
+              +-------------+------------+----------+-----------
+              |             |            |          | Inter-frame
+              | Information |    FCS     |   Flag   | fill or next
+              |             | 16/32 bits | 01111110 | address
+              +-------------+------------+----------+------------
+
+                        Figure 2.  Frame format
+
+     Flag Sequence
+
+     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.
+
+     Address
+
+     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
+
+
+
+Murakami & Maruyama          Informational                      [Page 2]
+
+RFC 2175                        MAPOS 16                       June 1997
+
+
+     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.
+
+             +-------------+-+-------------+-+
+             | | | | | | | | | | | | | | | | |
+             | | node addr |0|  node addr  |1|
+             +-+-----------+-+-------------+-+
+              ^             ^               ^
+              |             |               |
+              |             |               +------- EA bit (always 1)
+              |             +------- EA bit (always 0)
+              1 : broadcast, multicast
+              0 : unicast
+
+                        Figure 3 Address format
+
+
+
+     Protocol
+
+     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'' [9] and ``MAPOS
+     Version 1 Assigned Numbers'' [10].
+
+     Information
+
+     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.
+
+     Frame Check Sequence (FCS)
+
+     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.
+
+
+
+
+
+Murakami & Maruyama          Informational                      [Page 3]
+
+RFC 2175                        MAPOS 16                       June 1997
+
+
+     Inter-frame fill
+
+     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.
+
+3.2 Octet-Synchronous Framing
+
+   MAPOS 16 uses the same octet stuffing procedure[6] as MAPOS version
+   1[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.
+
+   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.
+
+4. Influence on MAPOS ARP, UNARP, NSP, and SSP
+
+   Since all of the MAPOS protocol family, ARP[11], UNARP[11], NSP[7],
+   and SSP[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;
+
+   (1) MAPOS ARP and UNARP
+    16-bit addresses are placed in the least significant places of the
+    32-bit sender and target HDLC addresses.
+
+   (2) NSP
+    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.
+
+   (3) SSP
+    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.
+
+
+
+
+
+
+Murakami & Maruyama          Informational                      [Page 4]
+
+RFC 2175                        MAPOS 16                       June 1997
+
+
+5. Mapping IP Multicast Address to MAPOS 16 Address
+
+   When transmitting IP multicast[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.
+
+6. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+References
+
+   [1]  CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit
+        Rates (1990).
+
+   [2]  CCITT Recommendation G.708: Network Node Interface for
+        Synchronous Digital Hierarchy (1990).
+
+   [3]  CCITT Recommendation G.709: Synchronous Multiplexing Structure
+        (1990).
+
+   [4]  American National Standard for Telecommunications - Digital
+        Hierarchy - Optical Interface Rates and Formats Specification,
+        ANSI T1.105-1991.
+
+   [5]  Murakami, K. and M. Maruyama, " MAPOS - Multiple Access Protocol
+        over SONET/SDH version 1", RFC2171, June, 1997.
+
+   [6]  Simpson, W., editor, "PPP in HDLC-like Framing," RFC1662, July
+        1994.
+
+   [7]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
+        Node Switch Protocol," RFC2173, June, 1997.
+
+   [8]  Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
+        Switch Switch Protocol," RFC2174, June, 1997.
+
+   [9]  Reynolds, J. and J. Postel, "ASSIGNED NUMBERS," RFC1700, Oct.
+        1994.
+
+   [10] Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
+        Numbers," RFC2172, June, 1997.
+
+   [11] Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
+        RFC2176, June, 1997.
+
+
+
+
+Murakami & Maruyama          Informational                      [Page 5]
+
+RFC 2175                        MAPOS 16                       June 1997
+
+
+Acknowledgements
+
+   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.
+
+Author's Address
+
+             Ken Murakami
+             NTT Software Laboratories
+             3-9-11, Midori-cho
+             Musashino-shi
+             Tokyo-180, Japan
+             E-mail: murakami@ntt-20.ecl.net
+
+             Mitsuru Maruyama
+             NTT Software Laboratories
+             3-9-11, Midori-cho
+             Musashino-shi
+             Tokyo-180, Japan
+             E-mail: mitsuru@ntt-20.ecl.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Murakami & Maruyama          Informational                      [Page 6]
+