Network Working Group K. Murakami
INTERNET-DRAFT August 1999
MAPOS 8/16 Protocol Required Extensions
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Please send comments to the
author <murakami@ntt-20.ecl.net>.
Abstract
This document describes required extensions to the Multiple Access
Protocol over SONET/SDH/DWDM(MAPOS) protocol suite described in
RFC2171-2176. The following extensions are discussed; the use of
self-synchronous scrambler, strong recommendation for the use of
CRC32, the use of abort sequence, and an algorithm to automate
protocol selection among MAPOS 8, MAPOS 16, and PPP.
1. Introduction
This document describes required extensions for Multiple Access
Protocol over SONET/SDH/DWDM(MAPOS) protocol suite described in
RFC2171-2176 [1] [2] [3] [4] [5] [6]. The use of self-synchronous
Murakami [Page 1]
INTERNET-DRAFT August 1999
scrambler, strong recommendation for the use of CRC32, the use of
abort sequence, and an algorithm to automate protocol selection among
MAPOS 8, MAPOS 16, and PPP are the subjects of this document. Note
that these extensions are addenda for MAPOS protocol suite and do not
obsolete existing protocol definitions.
2. Self-synchronous Scrambler
At the initial design of MAPOS, it was recognized that the use of
non-multiplexed SONET/SDH[7][8] payload for IP may result in
operational problems for SONET/SDH networks such as degrading
performance and link failures. Although some work arounds were
investigated, no specific solution was included in MAPOS protocol
suite since such proprietary solution may cause interoperability
problems.
Fortunately, ANSI T1X1[9], IETF[10], and ITU-T showed a solution to
the issue, that is, the use of self-synchronous scrambler designed
for ATM over SONET. The scrambler is so called X^43 + 1 and must be
included in all MAPOS implementations. All outbound data is placed on
SONET/SDH payload after it has been scrambled with the self-
synchronous scrambler. The scrambler runs continuously and is not
reset for each SONET/SDH frame. Refer to RFC2615[10] for the
implementation details.
3. Strong Recommendation for the Use of CRC32
MAPOS 8 and MAPOS 16 RFCs[1][3] provides no guideline for the use of
CRC16 and CRC32. CRC32 is strongly recommended and should be used by
default, because CRC16 becomes unreliable with frame size longer than
4Kbyte and because the use of self-synchronous scrambler weaken the
CRC due to multiplication of bit errors. For interoperability with
conventional MAPOS implementations, CRC16 must be implemented as well
as CRC32.
4. Abort Sequence
MAPOS RFCs [1][3] did not define the abort sequence clearly. When an
under-run occurs during DMA at the sending station or the sending
station cannot continue transferring a frame for some reason, it must
abort the frame transfer and transmit a Control Escape octet followed
immediately by a closing Flag Sequence. At the receiving end, the
frame is ignored, and not counted as a FCS error.
Murakami [Page 2]
INTERNET-DRAFT August 1999
5. Automatic Protocol Selection
This section describes the use of path signal label for automatic
protocol selection.
5.1 Path Signal Label C2
MAPOS gears may support MAPOS 8, MAPOS 16, and PPP. In addition,
these protocols have options that may be enabled and disabled such as
CRC16/32 and self-synchronous scrambler. To reduce the installation
complexity, automatic protocol selection algorithm is added. It uses
path signal label (C2) to indicate a link layer protocols and its
options. Table 1 shows the values. Note that these C2 values are
experimental.
0x80 MAPOS 8 with CRC16 and no self-synchronous scrambler
0x81 MAPOS 16 with CRC16 and no self-synchronous scrambler
0x88 MAPOS 8 with CRC16 and self-synchronous scrambler
0x89 MAPOS 16 with CRC16 and self-synchronous scrambler
0x8C MAPOS 8 with CRC32 and self-synchronous scrambler
0x8D MAPOS 16 with CRC32 and self-synchronous scrambler
0xCF PPP with CRC16 and no self-synchronous scrambler
0x22 PPP with CRC32 and self-synchronous scrambler
0x8E MAPOS Reserved
0x8F MAPOS Reserved
0x13 ATM
Table 1 C2 Values
5.2 Protocol Selection Process
MAPOS switch specifies a link layer protocol and its options by
sending the corresponding C2 value. An access node connected to the
switch checks the C2 values and selects the appropriate link protocol
and the specified options. A node must have an option to ignore C2
that uses a locally configured link protocol. It is useful when a
SONET/SDH gear does not transfer C2 byte transparently. When an
undefined value is received, the node must report it to the operator
and stop forwarding.
Initially, an access node must send 0x8D in C2. 0x8D indicates MAPOS
16 with CRC32 and self-synchronous scrambler. When it receives a C2
value from the other end such as a MAPOS switch, it must change the
C2 value to match that of the peer. A MAPOS switch starts forwarding
after it receives the same C2 value from the access node.
5.3 Special Case: P-to-P Configuration
Murakami [Page 3]
INTERNET-DRAFT August 1999
In a point-to-point MAPOS configuration, the MAPOS end node exchanges
0x8D as their C2 value. Thus, both ends accepts 0x8D and starts
forwarding using MAPOS 16 with CRC32 and self-synchronous scrambler.
A sending node must have an option to change the initial C2 values.
In this case, the other end accepts the value and changes its C2
value from 0x8D to the received value. Thus, they can interoperate.
5.4 Inter-switch Connection
Unlike end nodes, switch never dynamically change its sending C2
value. A MAPOS switch must stop forwarding while it recognizes link
protocol inconsistency by specifying received C2 value from the other
end.
6. Summary
This document described required extensions for MAPOS protocol suite
described in RFC2171-2176, namely the use of self-synchronous
scrambler, strong recommendation for the use of CRC32, the use of
abort sequence, and an algorithm to automate protocol selection among
MAPOS 8, MAPOS 16, and PPP.
7. Security Considerations
Security considerations are not discussed in this memo.
8. Expiration
This Internet Draft expires within 6 months from the date of
submission.
9. References
[1] Murakami, K., and Maruyama, M., "MAPOS - Multiple Access
Protocol over SONET/SDH Version 1", RFC2171, June 1997.
[2] Murakami, K. and Maruyama, M., "A MAPOS version 1 Extension -
Switch-Switch Protocol", RFC2174, June 1997.
[3] Murakami, K. and Maruyama, M., "MAPOS 16 - Multiple Access
Protocol over SONET/SDH with 16 Bit Addressing", RFC2175, June
1997.
Murakami [Page 4]
INTERNET-DRAFT August 1999
[4] Murakami, K. and Maruyama, M., "A MAPOS version 1 Extension -
Node Switch Protocol", RFC2173, June 1997.
[5] Murakami, K. and Maruyama, M., "IPv4 over MAPOS Version 1",
RFC2176, June 1997.
[6] Shimizu, S., Sato, S., and Murakami, K. MAPOS "Automatic
Switch-address Assignment Protocol (ASAP) Option" Inter-draft,
July 1999.
[7] American National Standards Institute, "Synchronous Optical
Network (SONET) - Basic Description including Multiplex
Structure, Rates and Formats," ANSI T1.105-1995.
[8] ITU Recommendation G.707, "Network Node Interface For The
Synchronous Digital Hierarchy", 1996.
[9] American National Standards Institute, "Synchronous Optical
Network (SONET)--Payload Mappings," T1.105.02-1998.
[10] Malis, A. "PPP over SONET/SDH", RFC2615, June 1999
10. Acknowledgements
The author would like to acknowledge the contribution and thoughtful
suggestions of Juha Heinanen, Takahiro Sajima and Tetsuo Kawano.
11. Author's
Address:
Ken Murakami
NTT Network Innovation laboratories,
3-9-11 Midori-cho Musashino-shi Tokyo 180-8585 Japan
Phone: +81 422 59 3323
Fax: +81 422 59 3765
Email: murakami@ntt-20.ecl.net
12. Full Copyright Statement
"Copyright (C) The Internet Society (1999). 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
Murakami [Page 5]
INTERNET-DRAFT August 1999
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 assigns.
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.
Murakami [Page 6]