doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc3422.txt b/doc/rfc/rfc3422.txt
new file mode 100644
index 0000000..6c2fd1a
--- /dev/null
+++ b/doc/rfc/rfc3422.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                         O. Okamoto
+Request for Comments: 3422                                   M. Maruyama
+Category: Informational                                 NTT Laboratories
+                                                               T. Sajima
+                                                        Sun Microsystems
+                                                           November 2002
+
+
+       Forwarding Media Access Control (MAC) Frames over Multiple
+  Access Protocol over Synchronous Optical Network/Synchronous Digital
+                           Hierarchy (MAPOS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+IESG Note
+
+   This memo documents a way of tunneling Ethernet frames over MAPOS
+   networks.  This document is NOT the product of an IETF working group
+   nor is it a standards track document.  It has not necessarily
+   benefited from the widespread and in-depth community review that
+   standards track documents receive.
+
+Abstract
+
+   This memo describes a method for forwarding media access control
+   (MAC) frames over Multiple Access Protocol over Synchronous Optical
+   Network/Synchronous Digital Hierarchy (MAPOS), thus providing a way
+   to unify MAPOS network environment and MAC-based Local Area Network
+   (LAN) environment.
+
+1. Network Model
+
+   In the Network model assumed in this memo, MAC-based LAN traffic is
+   forwarded by a MAPOS switched network.  This model allows distant
+   LANs to be interconnected to form a single LAN segment.  Transparent
+   LAN Service (TLS) is provided by encapsulating MAC frames in MAPOS
+   frames and by mapping MAC addresses to MAPOS addresses.
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 1]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+   This network model is shown in figure 1. "MAPOS network" is composed
+   of MAPOS switches, SONET/SDH leased lines and optical fiber cables.
+   A LAN is connected to a MAPOS network by a Network Adapter (NA) which
+   has a MAPOS interface and an ethernet interface.  A unique MAPOS
+   address is assigned to each NA by NSP (Node-Switch Protocol) [2].
+
+                                +-----------+
+      MAC-based LAN N1 +---+    |   MAPOS   |    +---+ MAC-based LAN N2
+        ---------------|   |----|  network  |----|   |---------------
+         |             +---+    |           |    +---+             |
+      +-----+         Network   |    N0     |   Network         +-----+
+      |     |         adapter   +-----------+   adapter         |     |
+      +-----+            B1                       B2            +-----+
+      Host H1                                                   Host H2
+
+            Figure 1. VPN network service model with LANs N1 and N2
+
+   Host H1 in LAN N1 and host H2 in LAN N2 are connected to distinct
+   MAC-based LANs.  Transparent LAN service is provided by MAPOS network
+   N0 exchanging MAC frames between Host H1 and Host H2.
+
+   Using this mechanism, a single VLAN segment can be setup from
+   multiple LANs that may be geographically located far away from each
+   other.
+
+   The use of a switched technology is recommended for building a MAC-
+   based LAN.  In some cases, however, this becomes a requirement.  A
+   likely example is the situation where a MAC-based LAN having two
+   network adapters, both attached to the same MAPOS network (for
+   redundancy).  If the LAN is built using shared (non-switched)
+   technology, then this loop configuration is bound to be stormed by
+   incessant broadcast traffic.  This can only be circumvented by using
+   switched technology with support for broadcast spanning tree [7].
+
+2. Forwarding a MAC Frame
+
+   This section describes the MAC frame forwarding mechanism in the
+   MAPOS network.
+
+2.1. Outline
+
+   In figure 2, LANs N1 and N2 communicates via MAPOS network N0.  NAs
+   B1 and B2 are gateways into Network N0, and they each have a MAPOS
+   interface and an ethernet interface.
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 2]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+                                +------------+
+                                |MAPOS header|
+      +-----------+             +------------+             +-----------+
+      | MAC header| encapsulate | MAC  header| decapsulate | MAC header|
+      +-----------+ ----------> +------------+ ----------> +-----------+
+      |information|             | information|             |information|
+      +-----------+             +------------+             +-----------+
+        MAC frame             Bridged MAPOS frame             MAC frame
+
+                                +------------+
+        LAN N1         +---+    |    MAPOS   |    +---+         LAN N2
+        ---------------|   |----|   network  |----|   |---------------
+         |             +---+    |            |    +---+             |
+      +-----+            B1     |      N0    |      B2           +-----+
+      |     |                   +------------+                   |     |
+      +-----+                                                    +-----+
+      Host H1                                                    Host H2
+
+          Figure 2. Forwarding a MAC frame from H1 to H2 over the VPN
+
+   The process of forwarding a MAC frame transparently from host H1 to
+   host H2 is also shown in figure 2.  NA B1 encapsulates a MAC frame
+   from host H1, and forwards it to MAPOS network N0.  NA B2
+   decapsulates the MAPOS frame, then forwards the MAC frame to host H2.
+
+2.2. MAPOS encapsulation format
+
+   To transmit a MAC frame into MAPOS network, the NA encapsulates the
+   frame as shown in the following figures.  This frame format is based
+   on Bridged LAN Traffic for PPP [4]; only the fields with semantics
+   specific to this document are described below.  The fields are
+   transmitted from left to right.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 3]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+      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    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Address and Control      |      0xFE     |      0x31     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        (reserved)             |     Source MAPOS Address      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|0|Z|0| Pads  |   MAC Type    |    Destination MAC Address    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Destination MAC Address                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source MAC Address                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Source MAC Address        |          Length/Type          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    LLC data ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   LAN FCS (optional)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |               potential line protocol pad                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Frame FCS (16/32bits)                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Figure 3. 802.3 Frame format (IEEE 802 Un-tagged Frame)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 4]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+      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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Address and Control      |      0xFE     |      0x31     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         (reserved)            |     Source MAPOS Address      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|0|Z|0| Pads  |    MAC Type   |   Pad Byte    | Frame Control |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Destination MAC Address                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Destination MAC Address   |  Source MAC Address           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source MAC Address                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    LLC data ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   LAN FCS (optional)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              optional Data Link Layer padding                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Frame FCS (16/32bits)                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Figure 4. 802.4/802.5/FDDI Frame format (IEEE 802 Un-tagged Frame)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 5]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+      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    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Address and Control      |      0xFE     |      0x31     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        (reserved)             |     Source MAPOS Address      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|0|Z|0| Pads  |   MAC Type    |    Destination MAC address    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Destination MAC Address                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source MAC Address                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Source MAC Address       |     0x81      |      0x00     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Pri  |C| VLAN ID               |      Length/Type              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    LLC data ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   LAN FCS (optional)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                 potential line protocol pad                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Frame FCS (16/32bits)                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+             Figure 5. 802.3 Frame format (IEEE 802 Tagged Frame)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 6]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+      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   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      Address and Control      |      0xFE     |      0x31     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        (reserved)             |     Source MAPOS Address      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |F|0|Z|0| Pads  |    MAC Type   |   Pad Byte    | Frame Control |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Destination MAC Address                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Destination MAC Address   |  Source MAC Address           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Source MAC Address                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   SNAP-encoded TPID                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   SNAP-encoded TPID                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |Pri  |C| VLAN ID               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    LLC data ...
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   LAN FCS (optional)                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              optional Data Link Layer padding                 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Frame FCS (16/32bits)                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+        Figure 6. 802.4/802.5/FDDI Frame format (IEEE 802 Tagged Frame)
+
+   Address and Control
+
+      These fields contain the destination HDLC address as defined by
+      MAPOS Version 1 [1] and MAPOS 16 [3].
+
+   Protocol Field
+
+      0xFE31 for bridged LAN traffic for MAPOS.  NA should only accept
+      NSP (0xFE03) and bridged MAPOS frames (0xFE31) frames; others
+      should be silently discarded.
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 7]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+   Source MAPOS address
+
+      Contains the MAPOS address of the sending NA.  For MAPOS version 1
+      [1] the 8-bit HDLC address is placed in the least significant
+      place of the 16-bit field and the upper eight bits must be zero.
+
+3. Determination of the Destination MAPOS Address
+
+   The destination MAPOS address for a MAC frame to be bridged is
+   determined by searching the address table composed of entries of the
+   form
+
+   {destination MAC address, destination MAPOS address}
+
+   during the encapsulation phase.
+
+   For example, in figure 2, when a MAC frame to be sent to host H2 is
+   encapsulated, the destination MAPOS address corresponding to NA B2 is
+   used.
+
+   Determination of the destination MAPOS address for forwarding a MAC
+   unicast frame is described in 3.1. The way for forwarding a MAC
+   broadcast or multicast frame is described in 3.2.  Methods for
+   populating the address table are explained in 3.3.
+
+3.1. Destination MAPOS address for forwarding a MAC unicast frame
+
+   In NA, entries of the form
+
+   {destination MAC address, destination MAPOS address}
+
+   are held in its address table.  When a MAC frame is received by the
+   ethernet interface, the address table is searched using the
+   destination MAC address as the key.  If a matching entry is found,
+   the corresponding MAPOS address is used as the destination MAPOS
+   address.  If no matching entry exists, MAC broadcast forwarding (3.2)
+   is used.
+
+3.2. Forwarding a MAC broadcast or multicast frame
+
+   All MAC broadcast or multicast frames must be duplicated for
+   transmission (via MAPOS unicast) to each of the peer network adapters
+   in the same VLAN as the sending network adapter.
+
+   Consider an example shown in figure 7 where six LANs N1 through N6
+   are connected to the MAPOS network via network adapters B1 through
+   B6.
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 8]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+                                +------------+
+        LAN N1         +---+    |            |    +---+         LAN N2
+        ---------------|   |----|            |----|   |---------------
+         |             +---+    |            |    +---+             |
+      +-----+         Network   |            |   Network         +-----+
+      |     |         adapter   |            |   adapter         |     |
+      +-----+            B1     |            |      B2           +-----+
+      Host H1                   |            |                   Host H2
+                                |            |
+                                |            |
+                                |            |
+        LAN N3         +---+    |    MAPOS   |    +---+         LAN N4
+        ---------------|   |----|   network  |----|   |---------------
+         |             +---+    |            |    +---+             |
+      +-----+         Network   |      N0    |   Network         +-----+
+      |     |         Adapter   |            |   adapter         |     |
+      +-----+            B3     |            |     B4            +-----+
+      Host H3                   |            |                   Host H4
+                                |            |
+                                |            |
+                                |            |
+        LAN N5         +---+    |            |    +---+         LAN N6
+        ---------------|   |----|            |----|   |---------------
+         |             +---+    |            |    +---+             |
+      +-----+         Network   |            |   Network         +-----+
+      |     |         adapter   +------------+   adapter         |     |
+      +-----+            B5                        B6            +-----+
+      Host H5                                                    Host H6
+
+             Figure 7. Six networks connected to the MAPOS network
+
+   If a VLAN is configured with LANs N1, N2, and N3, a MAC broadcast or
+   multicast frame originating from LAN N1 must not be forwarded to LAN
+   N4, N5, or N6 but only to LANs N1, N2, and N3.  It is duplicated
+   twice for encapsulation and delivery to B2 and B3 via MAPOS unicast.
+
+   A set of network adapters that belongs to the same VLAN defines the
+   broadcast scope of the VLAN.  Before a VLAN is put to use, each NA in
+   the VLAN must be configured with the MAPOS addresses of its peer NAs.
+   A NA should silently discard bridged MAPOS frames with a MAPOS source
+   address that is not among the peers that the NA knows about.
+
+   The use of MAPOS multicast for forwarding MAC broadcast frames is
+   under further study.
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                      [Page 9]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+3.3. Methods for configuring the address table
+
+   This section describes two methods for setting up an address table:
+   static and dynamic.  NA must implement the static method described in
+   3.3.1.  The dynamic method (3.3.2) is optional, but an implementation
+   must provide an option to disable this feature.
+
+3.3.1. Static setup of address table
+
+   The address table can be set up statically.  Before using a VLAN,
+   address table entries for each NA in the VLAN must be populated
+   manually.
+
+   These entries are considered permanent until they are manually
+   removed, and must not be "aged" or overwritten by the dynamic
+   procedure described in 3.3.2.
+
+3.3.2. Dynamic setup of address table
+
+   The address table can also be set up dynamically.  A NA discovers
+   entries for its address table from incoming encapsulated MAPOS
+   frames.
+
+   The NA adds the pair
+
+   {source MAC address, source MAPOS address}
+
+   to its address table when it receives an encapsulated MAPOS frame.
+
+   Entries discovered this way are subject to aging timer (should be
+   configurable with the default of 300 seconds).  Once the timer for an
+   entry expires, the entry is removed from the address table.  The
+   timer is reset each time an encapsulated MAPOS frame with the same
+   source MAC address is received.
+
+   There must be at most one entry for a source MAC address.  If a
+   discovered MAPOS address for a MAC address differs from the
+   previously discovered address, the new one takes precedence and the
+   address table entry must be overwritten.  Under no circumstance may a
+   discovered entry overwrite a statically created entry (3.3.1).
+
+   Discovery process using ARP [6] packets between host H1 (the MAC
+   address is h1) in LAN N1 and host H2 (the MAC address is h2) in LAN
+   N2 is shown below.
+
+   The MAPOS addresses of NAs B1, B2, B3 are b1, b2, b3 respectively.
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 10]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+                              +-----------+
+        LAN N1       +---+    |           |
+        -------------|   |----|           |
+         |           +---+    |           |
+      +-----+       Network   |           |
+      |     |       adapter   |   MAPOS   |    +---+         LAN N2
+      +-----+          B1     |  network  |----|   |------------
+      Host H1                 |           |    +---+          |
+   (ARP request)              |    N0     |   Network      +-----+
+                              |           |   adapter      |     |
+                              |           |      B2        +-----+
+        LAN N3       +---+    |           |                Host H2
+        -------------|   |----|           |              (ARP reply)
+         |           +---+    |           |
+      +-----+       Network   +-----------+
+      |     |       adapter
+      +-----+          B3
+      Host H3
+
+         Figure 8. Three networks connected to the MAPOS network
+
+
+   (1)  Host H1 transmits an ARP request frame.  An ARP request frame is
+        a MAC broadcast Frame.
+
+   (2)  At NA B1, ARP request frame is received and is encapsulated.
+        Because the VPN is composed of LANs N1, N2, and N3, the NA B1
+        must send a MAPOS frame that has destination MAPOS address b2
+        and another MAPOS frame that has destination MAPOS address b3.
+        MAPOS address b1 is stored in the source MAPOS address field of
+        each frame.
+
+   (3)  The bridged MAPOS frame arrives at NAs B2 and B3 from the MAPOS
+        network.
+
+   (4)  NAs B2 and B3 receive the bridged MAPOS frame, and the pair
+
+        {h1, b1}
+
+        is added to their address tables.
+
+   (5)  In NA B2, the received MAPOS frame is decapsulated, and the MAC
+        frame is forwarded to LAN N2.  Similarly, in NA B3, the received
+        MAPOS frame is decapsulated, and the MAC frame is forwarded to
+        LAN N3.
+
+   (6)  At host H2, which exists in LAN N2, an ARP reply frame is
+        transmitted to host H1.
+
+
+
+Okamoto, et. al.             Informational                     [Page 11]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+   (7)  Via the ethernet interface on NA B2, the ARP reply frame is
+        received, and MAPOS encapsulation is done.
+
+        Because the entry
+
+        {h1, b1}
+
+        is registered in the address table, b1 is determined to be the
+        destination MAPOS address.  The bridged frame is forwarded to
+        the MAPOS network.
+
+   (8)  MAPOS network delivers the bridged MAPOS frame to NA B1.
+
+   (9)  NA B1 decapsulates the bridged MAPOS frame, and forwards the MAC
+        frame to LAN N1.  At the same time, the entry {h2 , b2} is
+        registered into NA B1 address table.
+
+   (10) Host H1 receives the ARP reply frame.
+
+4. Connecting a MAPOS Host to the VLAN
+
+   In order for a native MAPOS host to connect to a VLAN, it must have
+   its own unique MAC address and implement all the features of a
+   network adapter appropriate for the MAC framing that it wishes to
+   use.
+
+5. Security Considerations
+
+   This section discusses some of the security factors that need to be
+   considered when planning a transparent LAN service described in
+   section 1, "Network Model."
+
+5.1 Management boundaries
+
+   In a large network, different parts of the network are managed by
+   different organizations, and it is essential to clearly define the
+   boundaries of management responsibilities.
+
+   A probable scenario is that a common carrier provides transparent LAN
+   service to a variety of customers.  Each customer is a distinct
+   organization, expecting virtual private network service.  In such a
+   case, the common carrier should take management responsibility for
+   the MAPOS network, optical cables to customer sites, and the network
+   adapters that reside in customer premises.
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 12]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+                                     +----+
+     MAPOS Net +-------- ... --------+ NA +---- MAC-based LAN
+                                     +----+
+        Common Carrier Responsibility --->|<-- Customer Responsibility
+
+   In essence, the customer is allowed to do no more than connecting the
+   cable from their MAC-based LAN to the network adapters.  Common
+   carrier should be very careful to monitor and protect their assets,
+   including SONET/SDH connections and network adapters.  In particular,
+   network adapters serve as the primary line of defense against attacks
+   and should be closely guarded.
+
+5.2 Risks
+
+   Privacy of every customer connected to the carrier's MAPOS network
+   may be compromised.
+
+5.3 Attack against network adapters
+
+   A network adapter should be a dedicated device.  This makes the
+   device simple and easier to harden against break-in attempts.  In the
+   worst case, the device may crash causing network outage that only
+   affects the customer that the failed network adapter serves.  At this
+   point, the privacy of other customers is still safe.
+
+   A more meaningful attack would be to replace a network adapter with
+   some other intelligent agent that knows how network adapters work.
+   This is possible because network adapters are customer premise
+   equipment.  Using such a device, an attacker can infiltrate the
+   networks of other customers.  Filtering based on source MAPOS address
+   in bridging traffic is ineffective because this field is filled-in by
+   network adapters -- MAPOS networks do not forward source addresses.
+
+5.4 Filtering at network adapters and MAPOS switches
+
+   Network adapters should have the following frame filtering functions.
+
+   -  Each NA in a VLAN is configured with the MAPOS addresses of its
+      peer NAs that belongs to the same VLAN.  A NA should only accept
+      bridged MAPOS frames with a source MAPOS address of one of its
+      VLAN peers.
+
+   -  A NA should never import discovered address table entries with a
+      MAPOS address that is not the address of one of its VLAN peers.
+
+   -  If a NA detects that the amount of broadcast traffic from a host
+      on MAC-base LAN exceeds a predefined threshold, the NA should stop
+      forwarding traffic from that host.
+
+
+
+Okamoto, et. al.             Informational                     [Page 13]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+   By default, frame filtering by MAPOS switches is optional.  It is
+   desirable for a MAPOS switch to implement the following filtering
+   features.
+
+   -  A line interface of a MAPOS switch is made aware of the MAPOS
+      addresses in the VLAN to which the interface participates.  The
+      interface discards all incoming bridged traffic (from the NA) that
+      is destined to addresses outside of the VLAN's set.
+
+   -  MAPOS switch assigns a MAPOS address to a NA using NSP.  The
+      switch discards all incoming bridged traffic (from the NA) with
+      the source MAPOS address different from the one that is assigned
+      by NSP.
+
+5.5 Additional protection measures
+
+   A common carrier can implement additional protective measures such as
+   the following.
+
+   -  SONET/SDH connection is closely monitored.  Once a network adapter
+      is detected to have gone down, subsequent attempts at
+      re-connecting to the MAPOS network are refused until manually
+      re-enabled.
+
+   -  Above method is effective against real attacks, but it also
+      hinders timely recovery from accidents such as power outages.  A
+      reasonable trade-off solution is to implement an authentication
+      mechanism between the MAPOS network and network adapters.  Much
+      like Challenge Handshake Authentication Protocol (CHAP) [8] used
+      in PPP connection.  Something similar may be implemented by
+      defining additional message types to NSP.
+
+6. References
+
+   [1] Murakami, K. and M. Maruyama, "MAPOS - Multiple Access Protocol
+       over SONET/SDH, Version 1", RFC 2171, June 1997.
+
+   [2] Murakami, K. and M. Maruyama, "A MAPOS version 1 Extension -
+       Node-Switch Protocol", RFC 2173, June 1997.
+
+   [3] Murakami, K. and M. Maruyama, "MAPOS16 - Multiple Access Protocol
+       over SONET/SDH with 16 Bit Addressing", RFC 2175, June 1997.
+
+   [4] Higashiyama, M. and F.Baker, "PPP Bridging Control Protocol
+       (BCP)", RFC 2878, July 2000.
+
+   [5] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is Replaced by an
+       On-line Database", RFC 3232, January 2002.
+
+
+
+Okamoto, et. al.             Informational                     [Page 14]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+   [6] Plummer, D.C., "Ethernet Address Resolution Protocol: Or
+       converting network protocol addresses to 48.bit Ethernet address
+       for transmission on Ethernet hardware", STD 37, RFC 826, November
+       1982.
+
+   [7] IEEE 802.1D-1993, "Media Access Control (MAC) Bridges," ISO/IEC
+       15802-3:1993 ANSI/IEEE Std 802.1D, 1993 edition, July 1993.
+
+   [8] Simpson, W., "PPP Challenge Handshake Authentication Protocols",
+       RFC 1994, August 1996.
+
+7. Acknowledgements
+
+   The authors would like to acknowledge the contributions and
+   thoughtful suggestions of Naohisa Takahashi, Tetsuo Kawano and
+   Tsuyoshi Ogura.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 15]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+Appendix - Validation of the MAC Frame Forwarding Mechanism
+
+   This appendix describes the configuration and procedure used to
+   validate the soundness of the mechanism described in this document.
+   The key points are:
+
+   -   MAC frames are correctly forwarded by MAPOS network, and
+
+   -   Even if a network contains loops, broadcast packets do not storm
+       the network.  MAC-based networks must use broadcast spanning tree
+       technology in order for this to work.
+
+   (1) Verification of MAC frame forwarding on MAPOS network
+
+       Hosts H1 and H2, Ethernet switches S1 and S2, network adapters B1
+       and B2, and a MAPOS switch are connected as shown below.  An
+       ethernet protocol analyzer is placed between S1 and B1 for
+       traffic monitoring.
+
+       In the diagrams that follow, the hosts are x86 PC running FreeBSD
+       4.4-RELEASE, ethernet switches are Extreme Summit5i, network
+       adapters are OKI Electric MA-1, and the MAPOS switch is CSR
+       CoreSwitch80.
+
+                               +--------------+
+                        +------+ MAPOS SWITCH + ------+
+                        |      +--------------+       |
+                    +---+---+                     +---+---+
+                    | NA B1 |                     | NA B2 |
+                    +---+---+                     +---+---+
+        +----------+    |                             |
+        | Protocol |____|                             |
+        | Analyzer |    |                             |
+        +----------+    |                             |
+                        | (P1)                   (P1) |
+        +------+   +----+----+                   +----+----+   +------+
+        | Host |___| EtherSW |                   | EtherSW |___| Host |
+        |  H1  |   |    S1   |                   |    S2   |   |  H2  |
+        +------+   +---------+                   +---------+   +------+
+
+       Correct forwarding of unicast MAC frames (ping) are observed
+       between H1 and H2 through path (P1).
+
+   (2) Verification of spanning tree operation
+
+       - Enable spanning tree on S1 and S2.
+
+       - Connect S1 and S2 via path (P2) for redundancy.
+
+
+
+Okamoto, et. al.             Informational                     [Page 16]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+                               +--------------+
+                        +------+ MAPOS SWITCH + ------+
+                        |      +--------------+       |
+                    +---+---+                     +---+---+
+                    | NA B1 |                     | NA B2 |
+                    +---+---+                     +---+---+
+        +----------+    |                             |
+        | Protocol |____|                             |
+        | Analyzer |    |                             |
+        +----------+    |                             |
+                        | (P1)                   (P1) |
+        +------+   +----+----+                   +----+----+   +------+
+        | Host |___| EtherSW |                   | EtherSW |___| Host |
+        |  H1  |   |    S1   |                   |    S2   |   |  H2  |
+        +------+   +----+----+                   +----+----+   +------+
+                    (P2)|                             |(P2)
+                        +-----------------------------+
+
+       It is observed that broadcast packets are correctly exchanged
+       between S1 and S2, and that broadcast forwarding loop does not
+       exist.
+
+   (3) Verification of spanning tree fail over
+
+       - H1 and H2 communication takes place through path (P1).
+         Spanning tree is configured such that Path (P2) is blocked.
+
+       It is observed that severing the link at any point along path
+       (P1) makes the spanning tree configure itself to use path (P2).
+
+       It is also observed that restoring path (P1) makes the spanning
+       tree configures itself to use path (P1).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 17]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+Authors' Addresses
+
+   Osamu Okamoto
+   NTT Network Service System Laboratories
+   3-9-11, Midori-cho Musashino-shi
+   Tokyo 180-8585, Japan
+
+   EMail: okamoto.osamu@lab.ntt.co.jp
+
+
+   Mitsuru Maruyama
+   NTT Network Innovation Laboratories
+   3-9-11, Midori-cho Musashino-shi
+   Tokyo 180-8585, Japan
+
+   EMail: mitsuru@core.ecl.net
+
+
+   Takahiro Sajima
+   Sun Microsystems, K.K.
+   4-10-1, Yoga Setagaya-ku
+   Tokyo 158-8633, Japan
+
+   EMail: tjs@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 18]
+
+RFC 3422            Forwarding MAC Frames over MAPOS       November 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Okamoto, et. al.             Informational                     [Page 19]
+