rfc1220.txt

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

Point-to-Point Protocol Extensions Working Group                [Page 6]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


5.4.  LAN Identification

   In some applications, it is useful to tag traffic by the user
   community it is a part of, and guarantee that it will be only emitted
   onto a LAN which is of the same community.  The user community is
   defined by a LAN ID.  Systems which choose to not implement this
   feature must assume that any frame received having a LAN ID is from a
   different community than theirs, and discard it.











































Point-to-Point Protocol Extensions Working Group                [Page 7]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


Figure 1: Tinygram Compression Pseudo-Code

PPP Transmitter:

if (ZeroPadCompressionEnabled &&
    BridgedProtocolHeaderFormat == IEEE8023 &&
    PacketLength == Minimum8023PacketLength) {
 /*
  * Remove any continuous run of zero octets preceding,
  * but not including, the LAN FCS, but not extending
  * into the MAC header.
  */
    Set (ZeroCompressionFlag);            /* Signal receiver */
    if (is_Set (LAN_FCS_Present)) {
        FCS = TrailingOctets (PDU, 4);    /* Store FCS */
        RemoveTrailingOctets (PDU, 4);    /* Remove FCS */
        while (PacketLength > 14 &&       /* Stop at MAC header */
               TrailingOctet (PDU) == 0)  /*  or last non-zero octet */
            RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
        Appendbuf (PDU, 4, FCS);          /* Restore FCS */
    }
    else {
        while (PacketLength > 14 &&       /* Stop at MAC header */
               TrailingOctet (PDU) == 0)  /*  or last zero octet */
            RemoveTrailingOctets (PDU, 1);/* Remove zero octet */
    }
}

PPP Receiver:

if (ZeroCompressionFlag) {                /* Flag set in header? */
 /* Restoring packet to minimum 802.3 length */
    Clear (ZeroCompressionFlag);
    if (is_Set (LAN_FCS_Present)) {
        FCS = TrailingOctets (PDU, 4);   /* Store FCS */
        RemoveTrailingOctets (PDU, 4);   /* Remove FCS */
        Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
        Appendbuf (PDU, 4, FCS);         /* Restore FCS */
    }
    else {
        Appendbuf (PDU, 60 - PacketLength, zeroes);/* Add zeroes */
    }
}








Point-to-Point Protocol Extensions Working Group                [Page 8]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


6.  Protocol Data Unit Formats

6.1.  Common LAN Traffic

   Figure 2: 802.3 Frame format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0xFF     |      0x03     |      0x00     |      0x31     +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   LAN ID low word (optional)  |      Destination MAC Address  +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination MAC Address                 +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source MAC Address                      +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Source MAC Address        |      Length/Type              +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LLC data                                        +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   LAN FCS (optional)                          +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                potential line protocol pad                    +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           HDLC CRC            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For Bridging LAN traffic, the format of the frame on the line is as
   shown in Figures 2 or 3.  This conforms to RFC 1171 section 3.1
   "Frame Format".  It also allows for RFC 1172 [2] negotiation of
   Protocol Field Compression and Address and Control Field Compression.
   It is recommended that devices which use controllers that require
   even memory addresses negotiate to NOT USE Protocol Field Compression
   on other than low speed links.










Point-to-Point Protocol Extensions Working Group                [Page 9]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


   Figure 3: 802.4/802.5/FDDI Frame format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0xFF     |      0x03     |      0x00     |      0x31     +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |F|I|Z|0| Count |    MAC Type   |  LAN ID high word (optional)  +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   LAN ID low word (optional)  |   Pad Byte    | Frame Control +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Destination MAC Address                 +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Destination MAC Address   |  Source MAC Address           +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Source MAC Address                      +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               LLC data                                        +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       FCS (optional)                          +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              optional Data Link Layer padding                 +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           HDLC CRC            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


The fields of this message are as follows:

Address Field and Control Field:
     As defined by RFC 1171

Protocol Field:
     0x0031

Flags:
     bits 0-3: length of the line protocol pad field.
     bit 4:  Reserved, Set to Zero
     bit 5:  Set if IEEE 802.3 Pad must be zero filled to minimum size
     bit 6:  Set if the LAN ID Field is present
     bit 7:  Set if the LAN FCS Field is present

     The "number of trailing "pad" octets is a deference to the fact
     that any point-to-point frame may have padding at the end.  This



Point-to-Point Protocol Extensions Working Group               [Page 10]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


     number tells the receiving system how many octets to strip off the
     end.

MAC Type:
     0: Reserved
     1: IEEE 802.3/Ethernet
     2: IEEE 802.4
     3: IEEE 802.5
     4: FDDI
     other:  Assigned by the Internet Assigned Numbers Authority

LAN ID:
     This optional 32 bit field identifies the Community of LANs which
     may be interested to receive this frame, as described in section
     5.4.  If the LAN ID flag is not set, then this field is not
     present, and the PDU is four octets shorter.

Frame Control:
     On 802.4, 802.5, and FDDI LANs, there are a few octets preceding
     the Destination MAC Address, one of which is protected by the FCS.
     Since the MAC Type field defines the bit ordering, these are sent
     in MAC order.  A pad octet is present to avoid odd machine address
     boundary problems.

Destination MAC Address:
     As defined by the IEEE.  Since the MAC Type field defines the bit
     ordering, this is sent in MAC order.

Source MAC Address:
     As defined by the IEEE.  Since the MAC Type field defines the bit
     ordering, this is sent in MAC order.

LLC data:
     This is the remainder of the MAC frame.  This is that portion of
     the frame which is (or would be were it present) protected by the
     LAN FCS; for example, the 802.5 Access Control field, and Status
     Trailer are not meaningful to transmit to another ring, and are
     omitted.

LAN Frame Checksum:
     If present, this is the LAN FCS which was calculated by (or which
     appears to have been calculated by) the originating station.  If
     the FCS Present flag is not set, then this field is not present,
     and the PDU is four octets shorter.

Optional Data Link Layer Padding
     RFC 1171 specifies that an arbitrary pad can be added after the
     data intended for transmission.  The "Count" portion of the flag



Point-to-Point Protocol Extensions Working Group               [Page 11]

RFC 1220            Bridging Point-to-Point Protocol          April 1991


     field contains the length of this pad, which may not exceed 15
     octets.

CRC-CCITT
     Mentioned primarily for clarity.  The CRC used on the PPP link is
     separate from and unrelated to the LAN FCS.

6.2.  IEEE 802.1 Bridge

   This is the BPDU as defined by IEEE 802.1(d), without any MAC or
   802.2 LLC header (these being functionally equivalent to the Address,
   Control, and Protocol Fields).  The LAN Pad and Frame Checksum fields
   are likewise superfluous and absent. The Address and Control Fields
   are optional, subject to the Address and Control Field Compression
   negotiation.

   Figure 4: Bridge "Hello" PDU

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+
   |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0xFF     |      0x03     |      0x02     |      0x01     +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              BPDU data                                        +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              ...                              +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           HDLC CRC            |   HDLC FLAG   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The fields of this message are as follows:

   Address Field and Control Field:
        As defined by RFC 1171

   Protocol Field:
        0x0201

   MAC Frame:
        802.1(d) BPDU








Point-to-Point Protocol Extensions Working Group               [Page 12]