RFC 2175

RFC 2175: MAPOS 16 💖

Okay bestie, welcome to RFC 2175! 🦋 It's MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing, and it's giving big address-space energy ✨

Title block facts: This is RFC 2175 from the Network Working Group 🌸. It was written by K. Murakami and M. Maruyama of NTT Laboratories and it's dated June 1997. The category is Informational 💅. The header doesn't list anything it obsoletes or updates, so there's no drama there 🙈

---

Status of this Memo ✨

This memo gives information to the Internet community 💜. It does NOT specify an Internet standard of any kind. Distribution of this memo is unlimited 🎀

Authors' note 🫶

So this doc describes MAPOS 16, a multiple access protocol for sending network-protocol datagrams inside HDLC frames with 16 bit addressing, over SONET/SDH 🧚 The main glow-up from MAPOS version 1 is the 16 bit address field, which gives way more address space. Real talk: this document is NOT from an IETF working group and it's NOT a standards track document. It also hasn't necessarily gone through the wide, deep community review that standards track docs get 🥺

Abstract 🌈

This doc describes MAPOS 16, the Multiple Access Protocol over SONET/SDH with 16 Bit Addressing, for sending network-protocol datagrams over SONET/SDH. The big difference from MAPOS version 1 is that it has a 16 bit address field, which means a massively bigger address space 🔥 It starts with a quick rundown of how MAPOS and MAPOS 16 differ, and then it explains the header format and the 16 bit address format 💅

1. Introduction 🌸

MAPOS is a multiple access protocol for sending High-level Datalink Control (HDLC) frames over the Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH)[1][2][3][4]. The iconic part is that it gives multiple access to SONET/SDH, which is an inherently point-to-point link 👑

MAPOS version 1[5] focuses on keeping the frame format compatible with the conventional PPP[6], and that's why it ends up with a narrow 8 bit address field 🙈 MAPOS 16 is the glow-up, with a 16 bit address space ✨

In this doc, the header format and the 16 bit format are described. It also explains that 16 bit addressing has minimal influence on the conventional MAPOS protocol family, like the Node-Switch Protocol[7] and the 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]. The difference is that the address field gets extended to 16 bits, and the control field from MAPOS version 1 is dropped to keep 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) aren't used 💅 The frame also doesn't include the bytes for transparency. Fields are sent 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 🎀

The flag sequence is for frame synchronization 🌸 Each frame begins and ends with a flag sequence, 01111110 (0x7E). If one frame comes right after another, a single flag sequence can count as both the end of the previous frame and the start of the next one. When the line is idle, the flag sequence is supposed to be sent continuously on the line 🫶

Address 🦋

The address field has the destination HDLC address, and a switch forwards the frame based on this field. It's 16 bits wide 💜 The LSB of the first byte tells you the field continues, and it MUST always be 0. The LSB of the second byte marks the end of the field, and it MUST always be 1 😭 The MSB of the first byte tells you whether the frame is unicast or multicast 👑 An MSB of 0 means unicast, and the other thirteen bits give the destination node address, including two E/A bits. An MSB of 1 means multicast, and those thirteen bits give the group address 🌈 The address 0xFEFF means 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 says which protocol the datagram in the information field belongs to 🧚 It follows 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 has the datagram for the protocol named in the protocol field. Its length MAY vary, but it 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, a 32 bit FCS MAY be used instead 🎀 The FCS is calculated over all bits of the address, protocol, and information fields before escape conversions. The least significant octet of the result goes out first, because it holds the coefficient of the highest term 🦋

Inter-frame fill 🫶

A sending station MUST continuously transmit the flag sequence as inter-frame fill after the FCS field 💜 The receiving station MUST silently discard the inter-frame flag sequences. If an under-run happens during DMA in the sending station, it MUST abort the frame transfer and keep sending the flag sequence to signal 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, the Async-Control-Character-Map (ACCM) isn't used 🌸 HDLC frames get mapped into the SONET/SDH payload like this 👑

Each HDLC frame is separated from the next one by one or more flag sequences, 01111110 (0x7E). There's an escape sequence to escape the flag sequence and the escape character itself 🦋 Before sending, but after the FCS computation, every 01111110 (0x7E) that isn't a flag gets converted to 01111101 01011110 (0x7D 0x5E), and every 01111101 (0x7D) gets converted to 01111101 01011101 (0x7D 0x5D). When a frame comes in, that conversion MUST be reversed before the FCS computation 🙈

4. Influence on MAPOS ARP, UNARP, NSP, and SSP 🌈

All of the MAPOS protocol family (ARP[11], UNARP[11], NSP[7], and SSP[8]) uses a 32-bit address field for the 8-bit MAPOS address, so the 16-bit addressing has no influence on them ✨ Each protocol just has to put the 16 bit address in the least significant place of its 32 bit address field, like this 💖

(1) MAPOS ARP and UNARP: The 16-bit addresses go in the least significant places of the 32-bit sender and target HDLC addresses 🦋

(2) NSP: In an address assignment packet, the 16-bit address goes in the least significant bytes of the 32-bit address field. The rest of the field gets padded with zeros 🧚

(3) SSP: In a route entry of an SSP packet, the 16-bit MAPOS address goes in the least significant bytes of the 32-bit address field 🎀

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 🌸 The exception is when those thirteen bits are all zeros or all ones. In that case, the address 1111 1110 1111 1101 SHOULD be used instead 🫶

6. Security Considerations 🔥

Security issues are not discussed in this memo. 💀 Please don't think this doc has covered security. If you need it, it's not in here 😭

---

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.

Acknowledgements 🫶

The authors want to give a shoutout to John P. Mullaney, Clark Bremer, Masayuki Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima for their contributions and thoughtful suggestions 💖🌸

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