Status of this Memo

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1997). All Rights Reserved.

Table of Contents

1.  Abstract
2.  Introduction
3.  MAPOS 16 Frame Format
3.1  Octet-Synchronous Framing
4.  Influence on MAPOS ARP, UNARP, NSP, and SSP
5.  Mapping IP Multicast Address to MAPOS 16 Address
6.  Security Considerations
7.  Acknowledgements
§  References
§  Authors' Addresses
§  Full Copyright Statement

1. 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.

2. 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].

3. 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.1 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.

7. 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.

References

Authors' Addresses

Full Copyright Statement

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgment

Funding for the RFC Editor function is currently provided by the Internet Society.