idnits 2.17.1 draft-maruyama-mapos-sonet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 72 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9871 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 1700 (ref. '8') (Obsoleted by RFC 3232) Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT EXPIRES: OCTOBER 1997 INTERNET-DRAFT 2 Network Working Group K. Murakami 3 INTERNET-DRAFT M. Maruyama 4 Category: Informational NTT Laboratories 5 April 1997 7 MAPOS - Multiple Access Protocol over SONET/SDH Version 1 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet- 20 Drafts as reference material or to cite them other than as ``work 21 in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the Internet- 25 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 26 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 27 Coast), or ftp.isi.edu (US West Coast). 29 Note: 31 This memo documents a multiple access protocol for transmission of 32 network-protocol datagrams, encapsulated in High-Level Data Link 33 Control (HDLC) frames, over SONET/SDH. This document is NOT the 34 product of an IETF working group nor is it a standards track 35 document. It has not necessarily benefited from the widespread and 36 in depth community review that standards track documents receive. 38 Abstract 40 This document describes the protocol MAPOS, Multiple Access Protocol 41 over SONET/SDH, for transmitting network-protocol datagrams over 42 SONET/SDH. It focuses on the core protocol -- other documents listed 43 in the bibliography may be referenced in conjunction with this 44 document to provide support and services for protocols at higher 45 layers. 47 1. Introduction 49 1.1 SONET/SDH 51 The Synchronous Optical Network/Synchronous Digital Hierarchy 52 (SONET/SDH) [1][2][3][4] family of ITU-T standard protocols are 53 designed to provide common, simple, and flexible interface for 54 broadband optical fiber transmission systems. It enables direct 55 octet-synchronous multiplexing of lower rate tributaries. 56 SONET/SDH-compliant transmission systems are widely deployed by 57 telephone carriers world wide. 59 This document defines the MAPOS protocol -- a method for transmitting 60 HDLC frames over SONET/SDH. The protocol provides multiple access 61 capability to SONET/SDH, an inherently point-to-point link. This 62 enables construction of seamless networking environment using 63 SONET/SDH as transmission media for both LAN and WAN. 65 1.2 Possible Configurations 67 The MAPOS protocol provides multiple access, broadcast / multicast- 68 capable switched LAN environment using SONET/SDH lines as 69 transmission media. Possible configurations of MAPOS system are 70 shown in the following diagrams. In (a), two end nodes are connected 71 to each other. Figure (b) shows a star-topology "SONET-LAN" where 72 multiple end nodes are connected to an HDLC frame switch. The frame 73 switch forwards packets between nodes and provides multiple access 74 capability. In (c), multiple frame switches are linked together, 75 creating a switching cluster. 77 +------+ +------+ 78 | Node +--------------------------------+ Node | 79 +------+ +------+ 81 (a) Point-to-Point configuration 83 +------+ +---------------+ 84 | Node +--------------------------------+ | 85 +------+ | | 86 | | 87 +------+ | | 88 | Node +--------------------------------+ | 89 +------+ | | 90 | Frame Switch | 91 +------+ | | 92 | Node +--------------------------------+ | 93 +------+ | | 94 | | 95 +------+ | | 96 | Node +--------------------------------+ | 97 +------+ +---------------+ 99 (b) Point-to-Multipoint configuration 101 +--------+ +--------+ 102 | Frame +----------------------+ Frame | 103 | Switch +--------+ +--------+ Switch | 104 +--+-----+ +-+----+-+ +--------+ 105 | | Frame | +--------+ 106 +--+-----+ | Switch | +--------+ | Frame | 107 | Frame | +-----+--+ | Frame +------+ Switch | 108 | Switch | +---------+ Switch | ++-------+ 109 +-------++ +--------+ | 110 |________________________________________| 112 (c) Switching cluster configuration 114 Figure 1. Possible configurations 116 Each port on a switch has an unique identifier within the switch. A 117 node connected to a switch port must inherit the address of the port. 118 That is, the node address is equal to the port identifier and is 119 unique within the switch. 121 In a switch cluster, a node address is subnetted. The high-order 122 bits, the part where the corresponding bits in the "subnet mask" are 123 1, indicate the switch address. The remaining low-order bits 124 indicate the unique node address within the switch. The two fields 125 form an unique address for a given node. 127 In either case, the address may be configured manually into a node 128 interface, or automatically by the address assignment mechanism 129 described in [5]. 131 Note that any two components may be connected either directly, or via 132 a long-haul SONET/SDH leased line. 134 1.3 Packet Transmission 136 The protocol is connection-less -- when a node wish to communicate 137 with some other node, it simply fills-in the destination address of 138 an HDLC frame, places it in one or more SONET/SDH payloads, and sends 139 it over a SONET/SDH link. 141 The switch forwards the frame to its destination based on the 142 destination address. In a switch cluster, the frame may be forwarded 143 by multiple switches and is eventually delivered to the specified 144 node. Broadcast and multicast are also supported. Frames with an 145 invalid destination address are silently discarded. 147 Like ethernet, the multiple access capability is provided by a switch 148 or a switch cluster. Since MAPOS is a link layer protocol, it is 149 independent of the upper layer protocols. That is, it can support any 150 network layer protocols such as IP. MAPOS IPv4 support is described 151 in [6]. 153 2. Physical Layer 155 This protocol treats the underlying end-to-end SONET/SDH transmission 156 link as if it was a plain, transparent channel. It sends HDLC frames 157 in SONET/SDH payloads, and expects them to arrive at the other end 158 unaltered. 160 Each node and switch should terminate SONET/SDH overhead such as 161 section overhead, line overhead, and path overhead according to the 162 specification of SONET/SDH. Unfortunately, SONET and SDH overhead 163 interpretations are not identical. In addition, some SONET/SDH 164 implementations utilize some overhead bytes in proprietary manner. 166 The detail of the interpretation is beyond the scope of this 167 document. Appendix A describes some of the most significant 168 differences among SONET, SDH, and their implementations that often 169 causes interoperability problems. Implementors of SONET/SDH 170 interfaces are strongly encouraged to be aware of such differences, 171 and provide workaround options in their products. 173 3. Data Link Layer 175 3.1 HDLC Frame Format 177 MAPOS uses the same HDLC-like framing as used in PPP-over-SONET, 178 described in RFC-1662[7]. Figure 2 shows the frame format. Logical 179 Link Control (LLC), and Sublayer/Sub-Network Access Protocol (SNAP) 180 are not used. It does not include the bytes for transparency. The 181 fields are transmitted from left to right. 183 +----------+----------+----------+----------+ 184 | | | | | 185 | Flag | Address | Control | Protocol | 186 | 01111110 | 8bits | 00000011 | 16 bits | 187 +----------+----------+----------+----------+ 188 +-------------+------------+-----------+----------- 189 | | | | Inter-frame 190 | Information | FCS | Flag | fill or next 191 | | 16/32 bits | 011111110 | address 192 +-------------+------------+-----------+------------ 194 Figure 2. Frame format 196 Flag Sequence 198 Flag sequence is used for frame synchronization. Each frame begins 199 and end with a flag sequence 01111110 (0x7E). If a frame 200 immediately follows another, one flag sequence may be treated as 201 the end of the preceding frame and the beginning of the immediately 202 following frame. When the line is idle, the flag sequence is to be 203 transmitted continuously on the line. 205 Address 207 The address field contains the destination HDLC address. A frame 208 is forwarded by a switch based on this field. It is 8 bits wide. 209 The LSB indicates the end of this field, and must always be 1. The 210 MSB is used to indicate if the frame is a unicast or multicast 211 frame. The MSB of 0 means unicast, with the remaining six bits 212 indicating the destination node address. MSB of 1 means multicast, 213 with the remaining six bits indicating the group address. The 214 address 11111111 (0xFF) means that the frame is a broadcast frame. 215 The address 00000001 (0x01) is reserved and used to identify a 216 control processor inside a switch. Frames with an invalid address 217 should be silently discarded. 219 +-------------+-+ 220 | | | | | | | | | 221 | | node addr |1| 222 +-+-----------+-+ 223 ^ ^ 224 | | 225 | +------- EA bit (always 1) 226 | 227 1 : broadcast, multicast 228 0 : unicast 230 Figure 3 Address format 232 Control 234 The control field contains single octet 00000011 (0x03) which, in 235 HDLC nomenclature, means that the frame is an Unnumbered 236 Information (UI) with the Poll/Final (P/F) bit set to zero. Frames 237 with any other control field values should be silently discarded. 239 Protocol 241 The protocol field indicates the protocol to which the datagram 242 encapsulated in the information field belongs. It conforms to the 243 ISO 3309 extension mechanism, and the value for this field may be 244 obtained from the most recent ``Assigned Numbers'' [8] and ``MAPOS 245 Version 1 Assigned Numbers'' [9]. 247 Information 248 The information field contains the datagram for the protocol 249 specified in the protocol field. The length of this field may 250 vary, but shall not exceed 65,280 (64K - 256) octets. 252 Frame Check Sequence (FCS) 254 By default, the frame check sequence (FCS) field is 16-bits long. 255 Optionally, 32 bit FCS may be used instead. The FCS is calculated 256 over all bits of the address, control, protocol, and information 257 fields prior to escape conversions. The least significant octet of 258 the result is transmitted first as it contains the coefficient of 259 the highest term. 261 Inter-frame fill 263 A sending station must continuously transmit the flag sequence as 264 inter-frame fill after the FCS field. The inter-frame flag 265 sequences must be silently discarded by the receiving station. 266 When an under-run occurs during DMA in the sending station, it must 267 abort the frame transfer and continuously send the flag sequence to 268 indicate the error. 270 3.2 Octet-Synchronous Framing 272 MAPOS uses an octet stuffing procedure because it treats SONET/SDH as 273 a byte-oriented synchronous link. Since SONET/SDH provides 274 transparency, Async-Control-Character-Map (ACCM) is not used. HDLC 275 frames are mapped into the SONET/SDH payload as follows. 277 Each HDLC frame is separated from another frame by one or more flag 278 sequence, 01111110 (0x7E). An escape sequence is defined to escape 279 the flag sequence and itself. Prior to sending the frame, but after 280 the FCS computation, every occurrence of 01111110 (0x7E) other than 281 the flags is to be converted to the sequence 01111101 01011110 (0x7D 282 0x5E), and the sequence 01111101 (0x7D) is to be converted to the 283 sequence 011111101 01011101 (0x7D 0x5D). Upon receiving a frame, 284 this conversion must be reversed prior to FCS computation. 286 4. Further Reading 288 To fully utilize MAPOS protocol, it is useful to reference other 289 documents[5][6][9][10] in conjunction with this document. 291 5. Security Considerations 293 Security issues are not discussed in this memo. 295 References 297 [1] CCITT Recommendation G.707: Synchronous Digital Hierarchy Bit 298 Rates (1990). 300 [2] CCITT Recommendation G.708: Network Node Interface for Synchronous 301 Digital Hierarchy (1990). 303 [3] CCITT Recommendation G.709: Synchronous Multiplexing Structure 304 (1990). 306 [4] American National Standard for Telecommunications - Digital 307 Hierarchy - Optical Interface Rates and Formats Specification, 308 ANSI T1.105-1991. 310 [5] K. Murakami and M. Maruyama, "A MAPOS version 1 Extension - 311 Node Switch Protocol," April, 1997. 313 [6] K. Murakami and M. Maruyama, "IPv4 over MAPOS Version 1," 314 April, 1997. 316 [7] W. Simpson, editor, "PPP in HDLC-like Framing," RFC1662, July 317 1994. 319 [8] J. Reynolds and J. Postel, "ASSIGNED NUMBERS," RFC1700, Oct. 1994. 321 [9] M. Maruyama and K. Murakami, "MAPOS Version 1 Assigned Numbers," 322 April 1997. 324 [10] K. Murakami and M. Maruyama, "A MAPOS version 1 Extension - 325 Switch Switch Protocol," April, 1997. 327 Acknowledgements 329 The authors would like to acknowledge the contributions and 330 thoughtful suggestions of John P. Mullaney, Clark Bremer, Masayuki 331 Kobayashi, Paul Francis, Toshiaki Yoshida, and Takahiro Sajima. 333 Author's Address 335 Ken Murakami 336 NTT Software Laboratories 337 3-9-11, Midori-cho 338 Musashino-shi 339 Tokyo-180, Japan 340 E-mail: murakami@ntt-20.ecl.net 342 Mitsuru Maruyama 343 NTT Software Laboratories 344 3-9-11, Midori-cho 345 Musashino-shi 346 Tokyo-180, Japan 347 E-mail: mitsuru@ntt-20.ecl.net 349 APPENDIX A. Differences among SONET, SDH, and their Implementations 351 This section briefly describes the major differences among SONET 352 which is an ANSI standard, SDH, an ITU-T standard, and their 353 implementations. 355 AU pointer (H1, H2, H3) 357 The AU pointer consists of bytes H1, H2, and H3. The bits 5 and 6 358 of the H1 byte are called ``SS bits,'' and are used to indicate the 359 offset into the payload where the beginning of a SPE is located. 360 (Note that ``SPE'' is a SONET term -- SDH calls it ``VC.'') In the 361 case of OC-3c, SONET sets the SS bits of the second and the third 362 H1 bytes to 0, whereas SDH sets them to 10 for AU-4, and 01 for 363 AU-31. Although the SS bits may be ignored at the receiving 364 station, some transmission systems discards SONET/SDH frames with 365 SS bits that it doesn't expect -- the sending station should be 366 aware of this, and include a configuration option to handle it. 368 Z1 and Z2 370 The Z bytes are reserved in SONET/SDH. Some transmission systems, 371 however, use them in a proprietary manner. SONET uses Z1 for Line 372 Error Monitoring. NTT, a carrier in Japan, utilized Z1 for 373 Automatic Protection Switching (APS.) 375 DCC Bytes 377 The D bytes are called the Data Communication channel (DCC), and 378 are defined for maintenance and operations. However, some carriers 379 and vendors use them in a proprietary manner. For example, NTT's 380 STM-1 UNI uses the D4, D5, and D6 bytes to transfer section and 381 path maintenance information.