summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3422.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3422.txt')
-rw-r--r--doc/rfc/rfc3422.txt1067
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]
+