MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing
MAPOS with a 16-bit address field, so a shared SONET/SDH network can hold far more nodes.
Murakami, K. and M. Maruyama, "MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing", RFC 2175, DOI 10.17487/RFC2175, June 1997, <https://www.rfc-editor.org/info/rfc2175>.
@misc{rfc2175,
series = {Request for Comments},
number = 2175,
howpublished = {RFC 2175},
publisher = {RFC Editor},
doi = {10.17487/RFC2175},
url = {https://www.rfc-editor.org/info/rfc2175},
author = {K. Murakami and M. Maruyama},
title = {{MAPOS 16 - Multiple Access Protocol over SONET/SDH with 16 Bit Addressing}},
pagetotal = 6,
year = 1997,
month = jun,
} RFC text
Contents
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.
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
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.
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.
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.
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
ISO Plain Language
On this page
§1MAPOS and the Move to 16 Bits
MAPOS is a multiple access protocol for the transmission of High-level Data Link Control frames over SONET/SDH. It provides multiple access capability on SONET/SDH, which is an inherently point-to-point link.
MAPOS version 1 focuses on frame format compatibility with conventional PPP, and that results in its narrow 8-bit address field. MAPOS 16 has a 16-bit address space instead, and the authors say this offers a significantly wide address space. The primary difference between the two is that one change.
The authors also say plainly what kind of document this is. It is not the product of an IETF working group and not a standards track document, so it has not necessarily benefited from the widespread and in-depth community review that standards track documents receive. The memo documents MAPOS 16 for transmitting network protocol datagrams encapsulated in HDLC frames with 16-bit addressing over SONET/SDH, describes the header format and the 16-bit address format, and explains that 16-bit addressing has minimal influence on the conventional MAPOS protocol family such as the Node-Switch Protocol and the Switch-Switch Protocol.
MAPOS lets many computers share one fibre line instead of just two. The new version simply gives each of them a longer address.
§2The MAPOS 16 Frame
Like MAPOS version 1, MAPOS 16 framing is based on the HDLC-like framing used in PPP-over-SONET/SDH, described in RFC 1662. The address field is extended to 16 bits, and the control field present in MAPOS version 1 is omitted to maintain the 32-bit alignment of the header. Logical Link Control and SNAP are not used. The fields are transmitted from left to right.
The flag is used for frame synchronisation. Each frame begins and ends with the flag sequence 01111110, which is 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 following one, and when the line is idle the flag sequence is transmitted continuously.
The address field contains the destination HDLC address, and a frame is forwarded by a switch based on this field. The protocol field indicates the protocol the datagram in the information field belongs to; it conforms to the ISO 3309 extension mechanism, and its value may be obtained from the most recent Assigned Numbers and MAPOS Version 1 Assigned Numbers. The information field contains that datagram, and its length may vary but shall not exceed 65,280 octets, which is 64K minus 256. The frame check sequence is 16 bits long by default, and 32 bits may be used instead. It is calculated over all bits of the address, protocol and information fields prior to escape conversions, and the least significant octet of the result is transmitted first.
A sending station must continuously transmit the flag sequence as inter-frame fill after the FCS field, and the receiving station must silently discard those flags. 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.
MAPOS 16 uses the same octet stuffing procedure as MAPOS version 1. Since SONET/SDH provides transparency, the Async-Control-Character-Map is not used. Each HDLC frame is separated from another by one or more flag sequences, and an escape sequence is defined to escape the flag sequence and itself. Before sending the frame, but after the FCS computation, every occurrence of 01111110 other than the flags is converted to 01111101 01011110, and the sequence 01111101 is converted to 01111101 01011101. On receiving a frame, the conversion is reversed before the FCS is computed.
Each message is wrapped like a parcel: a start marker, an address, a note saying what is inside, the contents, a check number, and an end marker. Data that happens to look like the start marker is disguised, and the receiver removes the disguise.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FLAG | Flag | 1 byte | 0x7E | Frame synchronisation, 01111110. |
ADDRESS | Address | 2 bytes | Destination HDLC address, used by a switch to forward the frame. | |
PROTOCOL | Protocol | 2 bytes | Protocol of the datagram in the information field. |
§3The 16-Bit Address Field
- BroadcastThe address 0xFEFF means the frame is for everyone.
- Control processorThe address 0x0001 is reserved for the control processor inside a switch.
- Invalid addressesFrames with an invalid address should be silently discarded.
- IP multicastThe thirteen bits hold the lowest-order thirteen bits of the IP multicast group address.
- All zeros or all onesIn that case the address 1111 1110 1111 1101 is used instead.
The least significant bit of the first byte of the address field indicates the continuation of the field and must always be 0, and the least significant bit of the second byte indicates the end of the field and must always be 1. These are the two EA bits. The most significant bit of the first byte says whether the frame is unicast or multicast: a value of 0 means unicast, with the remaining thirteen bits giving the destination node address including the two EA bits, and a value of 1 means multicast, with the remaining thirteen bits giving 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.
Section 5 covers IP multicast. When transmitting IP multicast, the thirteen bits of the HDLC address must contain the lowest-order thirteen bits of the IP multicast group address. An exception arises when those thirteen bits are either all zeros or all ones, in which case the address 1111 1110 1111 1101 should be used instead.
The address has a first bit that says whether the message is for one house or for a whole group, and the remaining bits are the house or group number. Two addresses are reserved, one for broadcast and one for the switch's own control processor.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
CAST | Cast bit | 1 bits | 0 is unicast, 1 is multicast or broadcast. | |
NODE-HI | Node address | 6 bits | First part of the 13-bit node or group address. | |
EA0 | EA bit | 1 bits | 0 | Always 0; the field continues. |
NODE-LO | Node address | 7 bits | Second part of the 13-bit node or group address. | |
EA1 | EA bit | 1 bits | 1 | Always 1; end of the field. |
§4Effect on the MAPOS Protocol Family
All of the MAPOS protocol family, ARP, UNARP, NSP and SSP, use a 32-bit address field for the 8-bit MAPOS address, so the 16-bit addressing has no influence on them. Each protocol only has to place a 16-bit address in the least significant place in its 32-bit address field.
For MAPOS ARP and UNARP, the 16-bit addresses are placed in the least significant places of the 32-bit sender and target HDLC addresses. For NSP, in an address assignment packet a 16-bit address is placed in the least significant bytes of the 32-bit address field and the rest of the field is padded with zeros. For SSP, in a route entry of an SSP packet the 16-bit MAPOS address is placed in the least significant bytes of the 32-bit address field.
The other MAPOS protocols already had room for a longer number, so the new address simply slides into the end of the field they already use.
§6Security Considerations
The memo says only that security issues are not discussed in it. Anyone deploying MAPOS 16 would need to look elsewhere for guidance, since this RFC gives none.
The memo does not say anything about keeping the line safe from snoopers.