HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 11:26:42 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 16 Aug 1999 08:50:00 GMT ETag: "3dd9a4-2ca1-37b7d0b8" Accept-Ranges: bytes Content-Length: 11425 Connection: close Content-Type: text/plain Network Working Group K. Murakami INTERNET-DRAFT August 1999 MAPOS 8/16 Protocol Required Extensions (draft-shimizu-mapos-proreq-extensions-00.txt) 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 . 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]