rfc2171.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

     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 8 bits wide.
     The LSB indicates the end of this field, and must always be 1.  The
     MSB is used to indicate if the frame is a unicast or a multicast
     frame.  The MSB of 0 means unicast, with the remaining six bits
     indicating the destination node address. MSB of 1 means multicast,
     with the remaining six bits indicating the group address.  The
     address 11111111 (0xFF) means that the frame is a broadcast frame.
     The address 00000001 (0x01) is reserved to identify the control
     processor inside a switch.  Frames with an invalid address should
     be silently discarded.






Murakami & Maruyama          Informational                      [Page 5]

RFC 2171                         MAPOS                         June 1997


             +-------------+-+
             | | | | | | | | |
             | | node addr |1|
             +-+-----------+-+
              ^             ^
              |             |
              |             +------- EA bit (always 1)
              |
              1 : broadcast, multicast
              0 : unicast

                        Figure 3 Address format

     Control

     The control field contains single octet 00000011 (0x03) which, in
     HDLC nomenclature, means that the frame is an Unnumbered
     Information (UI) with the Poll/Final (P/F) bit set to zero.  Frames
     with any other control field values should be silently discarded.

     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" [8] and "MAPOS
     Version 1 Assigned Numbers" [9].

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



Murakami & Maruyama          Informational                      [Page 6]

RFC 2171                         MAPOS                         June 1997


     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 uses an octet stuffing procedure because it treats SONET/SDH as
   a byte-oriented synchronous link.  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. Further Reading

   To fully utilize MAPOS protocol, it is useful to reference other
   documents[5][6][9][10] in conjunction with this document.

5. 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, "A MAPOS version 1 Extension -
        Node Switch Protocol," RFC2173, June, 1997.





Murakami & Maruyama          Informational                      [Page 7]

RFC 2171                         MAPOS                         June 1997


   [6]  Murakami, K. and M. Maruyama, "IPv4 over MAPOS Version 1,"
        RFC2176, June, 1997.

   [7]  Simpson, W., editor, "PPP in HDLC-like Framing," RFC1662, July
        1994.

   [8]  IANA, "IANA-Assignments,"
        http://www.iana.org/iana/assignments.html

   [9]  Maruyama, M. and K. Murakami, "MAPOS Version 1 Assigned
        Numbers," RFC2172, June 1997.

   [10] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
        Switch Switch Protocol," RFC2174, 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: [e-mail]

             Mitsuru Maruyama
             NTT Software Laboratories
             3-9-11, Midori-cho
             Musashino-shi
             Tokyo-180, Japan
             E-mail: [e-mail]















Murakami & Maruyama          Informational                      [Page 8]

RFC 2171                         MAPOS                         June 1997


APPENDIX A.  Differences among SONET, SDH, and their Implementations

   This section briefly describes the major differences among SONET
   which is an ANSI standard, SDH, an ITU-T standard, and their
   implementations.

     AU pointer (H1, H2, H3)

     The AU pointer consists of bytes H1, H2, and H3. The bits 5 and 6
     of the H1 byte are called "SS bits," and are used to indicate the
     offset into the payload where the beginning of a SPE is located.
     (Note that "SPE" is a SONET term -- SDH calls it "VC.")  In the
     case of OC-3c, SONET sets the SS bits of the second and the third
     H1 bytes to 0, whereas SDH sets them to 10 for AU-4, and 01 for
     AU-31.  Although the SS bits may be ignored at the receiving
     station, some transmission systems discards SONET/SDH frames with
     SS bits that it doesn't expect -- the sending station should be
     aware of this, and include a configuration option to handle it.

     Z1 and Z2

     The Z bytes are reserved in SONET/SDH.  Some transmission systems,
     however, use them in a proprietary manner.  SONET uses Z1 for Line
     Error Monitoring.  NTT, a carrier in Japan, utilized Z1 for
     Automatic Protection Switching (APS.)

     DCC Bytes

     The D bytes are called the Data Communication channel (DCC), and
     are defined for maintenance and operations.  However, some carriers
     and vendors use them in a proprietary manner.  For example, NTT's
     STM-1 UNI uses the D4, D5, and D6 bytes to transfer section and
     path maintenance information.


















Murakami & Maruyama          Informational                      [Page 9]