Layer 2 Gateway (L2GW)
draft-xia-nvo3-l2gw-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Liang Xia , Lucy Yong , Hao Weiguo | ||
| Last updated | 2014-06-29 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xia-nvo3-l2gw-01
Network working group L. Xia
Internet Draft L. Yong
Category: Standard Track Weiguo Hao
Huawei
Expires: December 2014 June 30, 2014
Layer 2 Gateway (L2GW)
draft-xia-nvo3-l2gw-01
Abstract
Layer 2 Gateway (L2GW) is used for interconnecting layer 2 overlay
network [NVO3FRWK] and layer 2 bridge networks [IEEE802.1Q] to form
one layer 2 virtual network. This draft describes data plane
interconnection and control plane interworking at L2GW.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xia, et al. [Page 1]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://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.
Table of Contents
1. Introduction ................................................ 3
1.1. Conventions used in this document .......................3
1.2. Terminology ............................................ 3
2. L2GW Reference Model ........................................ 3
3. General L2GW Operation Procedures ........................... 5
3.1. MAC Synchronization .................................... 5
3.2. ARP Handling ........................................... 5
3.3. Dual L2GWs ............................................. 6
4. L2CP Review and Applicability to L2 Overlay Network ..........6
4.1. STP/RSTP/MSTP .......................................... 9
4.2. PAUSE .................................................. 9
4.3. LACP/LAMP .............................................. 9
4.4. Link OAM .............................................. 10
4.5. Port Authentication ................................... 11
4.6. E-LMI ................................................. 11
4.7. LLDP .................................................. 11
4.8. PTP Peer Delay ........................................ 11
4.9. ESMC .................................................. 12
4.10. GARP/MRP Block........................................ 12
5. L2CP Process in L2GW........................................ 12
5.1. L2CP Frames Filtered (Peered or Discarded) in L2GW .... 13
5.2. L2CP Frames Passed through L2GW ....................... 13
6. Other Interworking Cases ................................... 14
7. Security Considerations .................................... 14
8. IANA Considerations ........................................ 14
9. References ................................................. 14
9.1. Normative References .................................. 14
9.2. Informative References ................................ 15
Xia, et al. [Page 2]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
1. Introduction
Cloud computing and network virtualization is evolving to the
direction of virtualized networks in overlay, which aims in fast and
easy to create tenant networks, support tenant system mobility, and
bring the manageability of all virtualized resources in DC.
Layer 2 (L2) overlay network in NVO3 means an L2 overlay network
interconnecting tenant systems, where any pair of Network
Virtualization Edges (NVE) are connected by IP tunnels. As a result,
it forms a full mesh topology of overlay network, i.e. only one hop
between any pair of NVEs. L2 bridge network in this draft is the
network specified in IEEE 802.1Q [IEEE 802.1Q] which are widely
deployed in DCs. L2 overlay network is used to refer the L2 network
specified in NVO3.
During DC network migration, it's very common that L2 overlay
network may be mix used with L2 bridge network in a DC, and the
communication between them is required. In another use case, using
L2 bridge network to connect non-virtualized devices in DC are
mature and well deployed method in DC; these non-virtualized devices
are necessary for some applications such as BIG data and are
required to communicate with virtualized resources.
To interconnect two networks that are implemented with different
technologies, gateway functions are needed on the device(s)/system(s)
sitting between. This device is referred as to Layer 2 Gateway (L2GW)
in this draft. The device is able to support many such
interconnections. The draft describes the L2GW in supporting both
the data plane and control plane interconnections.
1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
1.2. Terminology
This document uses the terms defined in NVO3 framework [NVO3FRWK]
and architecture [NVO3ARCH] documents.
2. L2GW Reference Model
The following diagram shows a reference model where L2GW provides an
interconnection between L2 overlay network and L2 bridge network.
Xia, et al. [Page 3]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
This is the case that using two different technologies implement one
L2 network.
......... .........
+---+ ... .... . +------+
TSs-+NVE| +---------+ +-+Server|
+---+ L2 Overlay | | L2 Bridge . +------+
. Network | L2GW | Network .
. | | . +------+
..+---+ +---------+ +-+Server|
TSs-+NVE| ... .... ... +------+
+---+......... ........
Figure 1: L2GW Reference Model
L2GW can reside at access providing direct connection to physical
servers, or reside at core or edge where the servers attach to L2
bridge switches (access). To connect with an L2 overlay, an L2GW
device physically connects to the underlying network where the
overlay is on and support NVE termination function.
To provide node failure resilience, the reference model can further
express as of Figure 2, where two L2GWs interconnect two networks.
......... .........
+---+ ... .... . +------+
TSs-+NVE| +---------+ +-+Server|
+---+ L2 Overlay | L2GW | L2 Bridge . +------+
. Network +---------+ Network .
. . +------+
..+---+ +---------+ +-+Server|
TSs-+NVE| ...| L2GW |.... ... +------+
+---+......... +---------+ ........
Figure 2: Redundant L2GW Model
Note that this draft assumes that L2GW device embeds L2 NVE and
IEEE802.1Q functions. An L2GW may support multiple L2 virtual
networks interconnections between L2 bridge network and overlays on
a DC infrastructure.
Xia, et al. [Page 4]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
3. General L2GW Operation Procedures
3.1. MAC Synchronization
L2GW interconnects L2 bridge network and NVO3 network. The MAC
addresses in two networks should be synchronized for the same
virtual network. If NVE-NVA architecture is used, when an L2GW
learns the MAC addresses from the bridge network, the L2GW should
notify NVA the MAC addresses, the NVA maintains the mapping of these
MAC addresses and L2GW, and inform NVEs the mappings. Through this
mechanism, unknown unicast traffic from the NVES to L2GW can be
avoided. L2GW maintains an outgoing forwarding table per virtual
network for learned MAC addresses from the bridge network.
Similarly, if NVA maintains the mappings between a tenant system's
MAC address and NVE in an L2 virtual network, NVA should inform the
mappings to L2GWs. L2GW maintains the mapping of L2 overlay network
ID and virtual network ID in the bridge network. These mappings may
be manually configured or automated via orchestration system. L2GW
maintains an incoming forwarding table per overlay network.
Upon receiving a packet from the overlay network, L2GW decapsulates
the packet, performs the table lookup, and may insert the VLAN ID on
the packet prior forwarding to the bridge network. If it does not
find the destination MAC entry in the table, it may drop the packet
or forward it as unknown packet depending on the policy.
Upon receiving a unknown frame from L2 bridge network, L2GW convert
it into known frame and then encapsulate the frame prior to
forwarding to the remote NVE. Note that: the outer VLAN ID on the
packet should be removed before the encapsulation.
Note that two networks MUST have no MAC address overlapping because
two networks, in fact, forms a single L2 virtual network.
3.2. ARP Handling
To avoid ARP flooding in the overlay network, L2GW maintains/caches
ARP table and/or relies on NVA to maintain the ARP table. L2GW
snoops ARP requests from the bridge network and sends ARP response
back.
If NVO3 supports ARP flooding, L2GW just floods ARP messages from
one network to another.
Xia, et al. [Page 5]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
3.3. Dual L2GWs
Two L2GWs may be used for network interconnection to support node
failure resilience. Two L2GWs may further operate in active/standby
or active-active mode. In active/standby mode, only one L2GW appear
running and passing the traffic from one network to another. In
active/active mode, both L2GW passes traffic from one network to
another.
In active/standby mode, to protect node failure, some protocol may
be necessary between L2GWs to facilitate status exchange. The active
standby role may be configured or automatically selected based on an
algorithm or policy. L2GW should inform NVA about its role, i.e.
active or standby, NVA should ensure that active L2GW IP address is
used in the mapping of (inner) MAC/ (outer) IP.
In active/active mode, NVA/NVEs have two paths to the bridge network
and vise versa. The NVEs in an overlay can choose one based on the
policy. Both networks MUST ensure to avoid following problems:
o Packet looping through a pair of L2GWs, i.e. coming from a
network at one L2GW, and send it back to the network through
another L2GW;
o Duplicated multi-destination traffic: Frame duplication may occur
when a multi-destination packet that arrives to both L2GWs. If
both L2GW forwards the packet to another network, the packet is
duplicated.
o In active/active mode, to avoid MAC flip-flop on remote NVEs, the
remote NVEs should support multiple tunnels, i.e., one inner MAC
maps to several outer NVE IP addresses. If the remote NVEs don't
support the mapping of an inner to multiple outers in case of
dual L2GW scenario. It is the constraint on remote NVEs.
4. L2CP Review and Applicability to L2 Overlay Network
This Section mainly discusses which L2CP (Layer 2 Control Protocol)
should be supported by L2 overlay network and which should not,
Section 5 specifies how L2GW should deal with L2CP frames.
L2CP protocols defined in IEEE 802.1 are listed in Table 1:
Xia, et al. [Page 6]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
+------------------+----------+----------+---------------------+
|MAC DA |Assignment| Protocol | L2CP Action |
| | | Type +----------+----------+
| | | |VLAN-based|PORT-based|
| | | | L2 | L2 |
| | | | services | services |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-00 |Nearest |STP/RSTP/M|Filter |Pass |
| |Customer |STP, | | |
| |Bridge |LACP/LAMP | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-01 |IEEE MAC |PAUSE |Filter |Filter |
| |Specific | | | |
| |Control | | | |
| |Protocols | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-02 |IEEE 802 |LACP/LAMP,|Filter |Filter |
| |Slow |Link OAM, | | |
| |Protocols |ESMC | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-03 |Nearest |Port |Filter |Filter |
| |non-TPRM |Authentica| | |
| |Bridge |tion, | | |
| | |LACP/LAMP | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-04 |IEEE MAC | |Filter |Filter |
| |Specific | | | |
| |Control | | | |
| |Protocols | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-05 |Reserved | |Filter |Filter |
| |for Future| | | |
|01-80-C2-00-00-06 |Standardiz| | | |
| |ation | | | |
|01-80-C2-00-00-09 | | | | |
| | | | | |
|01-80-C2-00-00-0A | | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-07 |MEF ELMI |E-LMI |Filter |Filter |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-08 |Provide | |Filter |Filter |
| |Bridge | | | |
| |Group | | | |
Xia, et al. [Page 7]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-0B |Reserved | |Filter |Pass |
| |for Future| | | |
|01-80-C2-00-00-0C |Standardiz| | | |
| |ation | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-0D |Provider | |Filter |Pass |
| |Bridge | | | |
| |MVRP | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-0E |Nearest |LLDP, PTP |Filter |Filter |
| |Bridge, |Peer Delay| | |
| |Individual| | | |
| |LAN Scope | | | |
+------------------+----------+----------+----------+----------+
|01-80-C2-00-00-20 | |GARP/MRP |Pass |Pass |
| | |Block | | |
| through | | | | |
| | | | | |
|01-80-C2-00-00-2F | | | | |
+------------------+----------+----------+----------+----------+
Table 1 L2CP protocols specification
Note:
Different L2CP protocols can use the same MAC DA in above block of
32 addresses, but be differentiated by protocol identifier. MAC DA
determines the intended recipient device for the frame;
Filter represent the L2CP action of peer or discard;
Based on whether L2 interface is VLAN-aware, L2 services can
divided into two categories: VLAN-based L2 services, PORT-based L2
services. L2CP action (peer, discard, pass) for these two L2
services is also different;
Whether the L2CP frames are peered or discarded is further
determined by the configuration of L2 interface.
Further analysis about whether a L2CP protocol is necessary and how
it is processed in NVO3 supported L2 VN, is provided in the
following sub sections.
Xia, et al. [Page 8]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
4.1. STP/RSTP/MSTP
The Spanning Tree Protocol (STP) is a L2 protocol that ensures a
loop-free topology for any bridged Ethernet local area network. The
basic function of STP is to prevent bridge loops and the broadcast
storm that results from them. Rapid spanning Tree Protocol (RSTP)
and Multiple Spanning Tree Protocol (MSTP) are all the enhanced xSTP
protocols.
L2 overlay network does not need xSTP protocols to prevent bridge
loops because it has its own mechanism for it, i.e., NVA, control
plane mechanisms, full mesh + split horizon, etc. So, the process of
xSTP frames in L2 VN is:
Be in line with L2CP protocols' specification of Table 1 from IEEE
in the L2 sub-networks attached to L2 NVEs;
xSTP frames are filtered in L2 NVEs and should not go into L2
overlay network.
4.2. PAUSE
[IEEE 802.3-2005] has specified a L2 flow control mechanism through
using the PAUSE frame. This frame uses L2CP MAC DA of 01-80-C2-00-
00-01 to be sent to the node at the other end of the link for
informing it to halt the frame transmission for a specified period
of time.
When L2 NVE is co-located in Hypervisor, PAUSE frame is not
necessary in one device. When they are separated, PAUSE frame is
only used in layer 2 network between L2 NVE and Hypervisor, there is
no need to overlay PAUSE frame between L2 NVEs. For the underlay
network of NVO3 network, L2 PAUSE mechanism is still used between
two adjacent switches for flow control.
4.3. LACP/LAMP
Link Aggregation [IEEE 802.1AXbk-2012] is a mechanism for making
multiple point-to-point links between a pair of devices appear to be
a single logical link between those devices. Link Aggregation
Control Protocol (LACP) and Link Marker Control Protocol (LAMP)
operate between exactly two peer devices for the purpose of creating,
verifying, and monitoring the logical link created by aggregating
individual links. Specific L2CP frames, known as Link Aggregation
Control Protocol Data Units (LACPDUs), are exchanged between the
Xia, et al. [Page 9]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
peer devices on each individual link in the aggregation. The
protocol identifier used by LACP is an Ethertype with a value of
0x8809 (the ''Slow Protocols'' Ethertype) and subtype values 01 (for
LACP) and 02 (for LAMP). Note that LACP is used to represent LACP
and LAMP in the following text.
LACP uses 3 different L2CP MAC DAs to determine the scope of
propagation of LACPDUs within a bridged LAN, as Table 2 follows:
+----------------+------------------+-----------------------------+
|Assignment | L2CP MAC DA |Peered or discarded by |
+----------------+------------------+-----------------------------+
|Nearest Customer| 01-80-C2-00-00-00|End Station, Customer Bridge,|
|Bridge | |Provider Edge Bridge |
+----------------+------------------+-----------------------------+
|IEEE 802 Slow | 01-80-C2-00-00-02|End Station, Customer Bridge,|
|Protocols | |Provider Edge Bridge, |
| | |Provider Bridge |
+----------------+------------------+-----------------------------+
|Nearest non-TPRM| 01-80-C2-00-00-03|Bridges except for Two Port |
|Bridge | |MAC Relay |
+----------------+------------------+-----------------------------+
Table 2 LACP specification of L2CP MAC DAs
Base on the summary of Table 2, LACPDUs with the L2CP MAC DA of 01-
80-C2-00-00-02 are peered or discarded by every node, so this kind
of LACPDUs will not be overlaid across the L2 overlay network. For
01-80-C2-00-00-00, it is possible that LACPDUs need to be overlaid
across Provider Bridge and L2 NVEs of L2 overlay network to reach
the other end Custom Bridge, L2 overlay network maybe need to
support to overlay this kind of LACP frame between L2 NVEs. How the
L2 overlay network support LACP frame of 01-80-C2-00-00-03 is TBD.
4.4. Link OAM
Lin OAM defined is defined in [IEEE 802.3ah], as mechanisms for
monitoring and troubleshooting Ethernet access links. Specifically
it defines tools for discovery, remote failure indication, remote
and local loopbacks and status and performance monitoring.
The Link OAM frames using L2CP MAC DA of 01-80-C2-00-00-02 are
peered or discarded by every node, so this kind of frame will not be
overlaid across the L2 overlay network.
Xia, et al. [Page 10]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
4.5. Port Authentication
[IEEE 802.1X] is an IEEE Standard for Port-based Network Access
Control (PNAC). It is part of the IEEE 802.1 group of networking
protocols. It provides an authentication mechanism to devices
wishing to attach to a LAN or WLAN.
Whether or not the L2 overlay network needs to overlay this L2CP
frames is TBD.
4.6. E-LMI
Ethernet Local Management Interface (E-LMI) is a protocol between
the customer edge (CE) device and the provider edge (PE) device. It
runs only on the PE-CE UNI link and notifies the CE of connectivity
status and configuration parameters of Ethernet services available
on the CE port. E-LMI interoperates with an OAM protocol, such as
Connectivity Fault Management (CFM), that runs within the provider
network to collect OAM status. CFM runs at the provider maintenance
level (UPE to UPE with inward-facing MEPs at the UNI). E-LMI relies
on the OAM Ethernet Infrastructure (EI) to interwork with CFM for
end-to-end status of Ethernet virtual connections (EVCs) across CFM
domains.
The LLDP frames using L2CP MAC DA of 01-80-C2-00-00-07 are peered or
discarded by every node except for the Two Port MAC Relay (TPMR)
bridge, so this kind of frame will not be overlaid across the L2
overlay network.
4.7. LLDP
The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link
layer protocol in the Internet Protocol Suite used by network
devices for advertising their identity, capabilities, and neighbors
on an IEEE 802 local area network, principally wired Ethernet. The
protocol is formally referred to by the IEEE as Station and Media
Access Control Connectivity Discovery specified in standards
document [IEEE 802.1AB].
The LLDP frames using L2CP MAC DA of 01-80-C2-00-00-0E are peered or
discarded by every node, so this kind of frame will not be overlaid
across the L2 overlay network.
4.8. PTP Peer Delay
PTP Peer Delay frame is specified in [IEEE 1588-2008] to carry PTP
peer time information. It uses L2CP MAC DA of 01-80-C2-00-00-0E and
Xia, et al. [Page 11]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
peered or discarded by every node, so this kind of frame will not be
overlaid across the L2 overlay network.
4.9. ESMC
Ethernet Synchronization Messaging Channel (ESMC) is specified in
[ITU-T Rec. G.8264] for conveying clock information between
Synchronous Ethernet (SyncE) bridges.
The ESMC frames using L2CP MAC DA of 01-80-C2-00-00-02 are peered or
discarded by every node, so this kind of frame will not be overlaid
across the L2 overlay network.
4.10. GARP/MRP Block
Multiple Registration Protocol (MRP), which replaced Generic
Attribute Registration Protocol (GARP), is a generic registration
framework defined by the [IEEE 802.1ak] amendment to the [IEEE
802.1Q] standard. MRP allows bridges, switches or other similar
devices to be able to register and de-register attribute values,
such as VLAN identifiers and multicast group membership across a
large LAN. MRP operates at the Data Link Layer.
The block of L2CP MAC DA from 01-80-C2-00-00-20 to 01-80-C2-00-00-2F
is used for MRP protocol. Now, only 01-80-C2-00-00-20 is for
Multiple MAC Registration Protocol (MMRP) and 01-80-C2-00-00-21 is
for Multiple VLAN Registration Protocol (MVRP), other L2CP MAC DA of
the block are all reserved for future use. Protocol use one address
of this block is passed by all the intervening bridges that does not
participate in the protocol using this address, and peered or
discarded by the bridge that participate in the protocol at last.
This forwarding rule maybe requires MRP frames to be overlaid across
the L2 overlay network.
5. L2CP Process in L2GW
For all L2CP protocols, several differences exist between L2 overlay
network and L2 bridge network on how to process them. As the
demarcation point between L2 overlay network and L2 bridge network,
L2GW keeps the same action to all L2CP frames as before at the L2
bridge network side on the one hand, but maybe processes some L2CP
frames differently at the L2 overlay network side on the other hand.
The following sub sections will describe the L2CP process in L2GW.
Xia, et al. [Page 12]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
5.1. L2CP Frames Filtered (Peered or Discarded) in L2GW
Although xSTP protocols using Nearest Customer Bridge address of 01-
80-C2-00-00-00 indicate that it can be overlaid across L2 overlay
network, they still are not necessary for L2 overlay network because
L2 overlay network has its own mechanism to prevent bridge loops. So
xSTP frames will be filtered by the L2GW and not go into the L2
overlay network.
Based on the analysis of section 3.3, LACP/LAMP frames using IEEE
802 Slow Protocols of 01-80-C2-00-00-02 are not necessary for L2
overlay network. So, LACP/LAMP frames will be filtered by the L2GW
and not go into the L2 overlay network. ESMC frames using the same
MAC DA will also be filtered by L2GW.
For Link OAM frames, if OAM functions are necessary for the whole L2
network which interconnects L2 bridge network and L2 overlay network,
L2GW needs to support the interworking of OAM as well. This means
that L2GW should peer the Link OAM frames of L2 bridge network and
perform some actions between NVEs in L2 overlay network. The
detailed operation is TBD.
Other L2CP protocols that are filtered by L2GW and do not go into L2
overlay network include PAUSE, E-LMI, LLDP, PTP Peer Delay. The
basic reason is that they all require to be processed hop by hop in
L2 network strictly, but overlay network breaks this rule.
The action of ''filter'' can be ''peer'', or ''discard''. It depends on
the specific service requirement, i.e., does L2GW need to
participate in the L2CP protocol, etc. How to determine the specific
action is TBD.
5.2. L2CP Frames Passed through L2GW
Excepting for the aforementioned L2CP protocols filtered by L2GW,
the left L2CP protocols need to be passed through L2GW. They include:
LACP/LAMP frames using IEEE 802 Slow Protocols of 01-80-C2-00-00-
00;
GARP/MRP series protocols (i.e., MMRP, MVRP) using the MAC DA
block of 01-80-C2-00-00-20 through 01-80-C2-00-00-2F.
All these kinds of L2CP frames are passed through L2GW and traverse
across the L2 overlay network and L2 bridge network to arrive the
bridges that participate in the L2CP protocols. For MRP protocols,
another necessary operation of L2GW is to use the pre-provisioned
Xia, et al. [Page 13]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
VLAN to virtual network instance (VNI) mappings in NVE locally or by
getting from NVA to map these MRP frames into corresponding VNIs.
6. Other Interworking Cases
There are other L2 bridge network technologies that use L2 Control
Plane protocols such as Provider Bridge [IEEE802.1AD] or Provider
Backbone Bridge [PBB] [IEEE802.1AH]. The use case of L2 Overlay
Network interworking with these types of bridge networks is for the
further study.
Note that VPLS [RFC4761] [RFC4762], EVPN [EVPN], Shortest Path
Bridging [IEEE SPB] and TRILL [RFC6325] are also technologies for L2
private network implementation. These technologies rely on the
control plane protocol and aim for service provider network. SDN
controller interworking with such control plane protocol will be
addressed in separate draft.
7. Security Considerations
TBD.
8. IANA Considerations
The document does not require any IANA action.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC4761] Kompella, K. and Rekhter, Y. (Editors), "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007
[RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, January 2007.
[RFC6325] Perlman, R., "RBridges: Base Protocol Specification",
July 2011.
Xia, et al. [Page 14]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
9.2. Informative References
[NVO3ARCH] Black, D, Narten, T., et al, "An Architecture for Overlay
Networks (NVO3)", draft-narten-nvo3-arch-01, work in progress
[NVO3FRWK] LASSERRE, M., Motin, T., et al, "Framework for DC Network
Virtualization", draft-ietf-nvo3-framework-07, work in progress.
[NVGRE] Sridharan, M., et al, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-virtualization-
nvgre-03, work in progress
[VXLAN] Mahalingam, M., Dutt, D., etc, "VXLAN: A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Networks",
draft-mahalingam-dutt-dcops-vxlan-05.txt, work in progress
[EVPN] Sajassi, A. and R. Aggarwal, "BGP MPLS Based Ethernet VPN",
draft-ietf-l2vpn-evpn-07, May 2014
[EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for
Ethernet VPN", RFC7209
[EVPN-MHN] Weiguo, Hao, Yizhou, Li, et al, "Multi-homed network in
EVPN", draft-hao-l2vpn-evpn-mhn-00, work in progress
[IEEE 802.1Q] "Virtual Bridged Local Area Networks", 2005
[IEEE 802.3-2005] "Part 3: Carrier sense multiple access with
collision detection (CSMA/CD) access method and physical layer
specifications"
[IEEE 802.1AXbk-2012] "IEEE Standard for Local and metropolitan area
networks--Link Aggregation Amendment 1: Protocol Addressing"
[IEEE 802.3ah] "IEEE Standard for Information technology--Local and
metropolitan area networks--Part 3: CSMA/CD Access Method and
Physical Layer Specifications Amendment: Media Access Control
Parameters, Physical Layers, and Management Parameters for
Subscriber Access Networks"
[IEEE 802.1X] "IEEE Standard for Local and metropolitan Area
Networks. Port-based Network Access Control"
[IEEE 802.1AB] "IEEE Standard for Station and Media Access Control,
Connectivity Discovery"
Xia, et al. [Page 15]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
[IEEE 1588-2008] "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Control
Systems"
[IEEE 802.1ak] "IEEE Standard for Local and metropolitan Area
Networks - Virtual Bridged Local Area Networks, Amendment 7:
Multiple Registration Protocol"
[IEEE 802.1AD], "Virtual Bridged Local Area Networks - Amendment 4:
Provider Bridges", 2005
[PBB] Clauses 25 and 26 of "IEEE Standard for Local and metropolitan
area networks - Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks", IEEE Std 802.1Q, 2013.
[IEEE802.1AH] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area
Networks, Amendment 6: Provider Backbone Bridges", 2008
[IEEE SPB] "IEEE standard for local and metropolitan area networks:
Media access control (MAC) bridges and virtual bridged local area
networks -- Amendment 20: Shortest path bridging", IEEE 802.1aq,
June 2012.
[ITU-T Rec. G.8264] "Distribution of Timing Through Packet Networks"
Authors' Addresses
Liang Xia (Frank)
Huawei Technologies
Email: frank.xialiang@huawei.com
Lucy Yong
Huawei Technologies, USA
Email: lucy.yong@huawei.com
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
Xia, et al. [Page 16]
Internet-Draft Layer 2 Gateway (L2GW) June, 2014
China
Phone: +86-25-56623144
EMail: haoweiguo@huawei.com
Xia, et al. [Page 17]