Dataplane Operations for VLAN Switching
draft-wang-vlan-based-traffic-forwarding-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yue Wang , Aijun Wang , Boris Khasanov , Fengwei Qin , Huaimo Chen , Chun Zhu | ||
| Last updated | 2024-04-11 (Latest revision 2024-03-19) | ||
| RFC stream | (None) | ||
| Intended RFC status | Informational | ||
| Formats | |||
| 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-wang-vlan-based-traffic-forwarding-01
ISE Y. Wang
Internet-Draft A. Wang
Intended status: Informational China Telecom
Expires: 20 September 2024 B. Khasanov
Yandex LLC
F. Qin
China Mobile
H. Chen
Futurewei
C. Zhu
ZTE Corporation
19 March 2024
Dataplane Operations for VLAN Switching
draft-wang-vlan-based-traffic-forwarding-01
Abstract
This document describes the data plane operations around VLAN
switching using VLAN tag rewriting. It further describes the
forwarding tables for VLAN that are utilised to achieve VLAN
forwarding.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on 20 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wang, et al. Expires 20 September 2024 [Page 1]
Internet-Draft VLAN-Switching March 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scenarios and Requirements . . . . . . . . . . . . . . . . . 3
4. VLAN-based Flow Labeling Behavior . . . . . . . . . . . . . . 4
4.1. VLAN Functional Categorization . . . . . . . . . . . . . 4
4.2. VLAN-Forwarding routing table . . . . . . . . . . . . . . 4
4.3. VLAN-Crossing routing table . . . . . . . . . . . . . . . 5
5. VLAN-based traffic forwarding Procedures . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In a typical Layer 2 network, all devices connected to a switch are
part of the same broadcast domain. As specified in IEEE 802.1Q
standard [802.1Q] VLANs allow the creation of multiple virtual
broadcast domains within a single physical network, thus enable
network administrators to divide a physical network into distinct
logical broadcast domains. VLANs help maintain segregation of
traffic from distinct networks as it travels across shared links and
devices within a topology and is crucial for reducing broadcast
network traffic and enhancing the security of network segments.
Through VLAN tag rewriting, the service traffic can be segmented to
facilitate easier control of traffic forwarding. The definition and
usage of the term VLAN Tagging varies greatly depending on what
hardware vendor is used. This document describes the data plane
operations around VLAN switching and through the VLAN-Forwarding
routing (VFR) table and the VLAN-Crossing routing (VCR) table defined
in the document a mechanism for VLAN-based flow labeling behavior can
be achieved.
2. Terminology
The following terms are defined in this draft:
* VSP: VLAN switching path
* VFR table: VLAN-Forwarding routing table
Wang, et al. Expires 20 September 2024 [Page 2]
Internet-Draft VLAN-Switching March 2024
* VCR table: VLAN-Crossing routing table
* VTF: VLAN-based traffic forwarding
3. Scenarios and Requirements
In order for 802.1Q compatible hardware to identify what VLAN a data
packet belongs to, an 802.1Q Header is added to the Ethernet frame
which specifies the VLAN tag. VLAN-enabled ports are typically
classified as either tagged or untagged, also known as "trunk" or
"access" ports, respectively. Tagged or trunked ports are designed
to handle traffic for multiple VLANs, while untagged or access ports
accept traffic for a single VLAN. In practice, trunk ports often
connect switches, facilitating communication between different VLANs,
while access ports link directly to end devices, allowing them to
communicate within a specific VLAN. The desired scenarios and
requirement for VLAN switching is as follows：
* Segregation of Network Management Traffic: Clearly separate
network management traffic from end-user or server traffic to
ensure dedicated processing and priority.
* Isolation of sensitive Infrastructure and services: isolate
sensitive infrastructure, services, and hosts (such as enterprise
users) from less secure parts (such as guest users) to ensure
access to critical resources and enhance security measures.
* Quality of Service (QoS) Implementation for Specific Services:
provide priority assurance or support Quality of Service (QoS) for
specific services:
* Multi-Tenant Network Services in ISP, Datacenter, or Office
Building: enable the logical separation of client networks using
the same infrastructure, facilitating the provision of varying
service quality levels for different clients in an ISP, data
center, or office building.
* Logical Grouping of Hosts Irrespective of Physical Location: to
logically group hosts, allowing them to share network resources
regardless of physical location.
The large-scale deployment of Ethernet interface makes it possible to
simplify the end-to-end data forwarding process by using the
information contained in the layer 2 frame structure. The mechanism
for VLAN-based flow labeling behavior in this draft can provide end-
to-end service assurance for specific customers and applications, and
realize deterministic transmission of key services in IP scenarios.
It makes full use of the VLAN information in layer 2 and implements
Wang, et al. Expires 20 September 2024 [Page 3]
Internet-Draft VLAN-Switching March 2024
full-scenario traffic access based on VLAN. By using a completely
new VLAN space to bypass the already used MPLS label, the mechanism
avoids the possibility of conflict with other existing protocols and
eliminates the need to consider the label overlap of the already used
MPLS services in the MPLS-Native IP Mixed environment. The mechanism
simplifies the end-to-end path calculation and forwarding process of
messages and thus avoiding pre-reservation of resources on each
network devices and achieving the overall QoS guarantee effect. It
can meet the path forwarding requirements of multi-service traffic
and ensure the priority and service quality of key businesses, So as
to realize flexible networking and multi-dimensional SLA path
planning.
4. VLAN-based Flow Labeling Behavior
4.1. VLAN Functional Categorization
According to IEEE 802.1Q, VLAN-enabled ports are generally
categorized in one of two ways: tagged or untagged. During the VLAN
switching process, the usage of VLAN can be further refined into
three categories:
VLAN of ingress interface: A VLAN originally tagged by the devices
which is used for VLAN-based flow labeling behavior. The Ingress
VLAN refers to the initial VLAN tagging performed by devices when
they send traffic into the network. It helps identify and manage the
flow of traffic as it enters the network.
VLAN of transit interface: A VLAN transporting transit traffic, in
other words, the traffic tagged with transit VLAN does not have the
final source or destination. The Transit VLAN facilitates the
movement of traffic between different segments of the network,
ensuring efficient routing to reach its ultimate destination.
VLAN of egress interface: A VLAN through which traffic exits a
network, and the devices within the network may remove the VLAN tag
before sending the traffic to its final destination. The Egress VLAN
handles traffic leaving the network from end-user devices. Devices
within this VLAN perform necessary operations, such as VLAN tag
removal or other processing, to ensure that outgoing traffic is
appropriately formatted for the next segment of its journey in the
network.
4.2. VLAN-Forwarding routing table
Based on the three categories of VLANs above, the ingress devices
needs to maintain a VFR table defined below which is used to match
the packet based on the source and destination IP.
Wang, et al. Expires 20 September 2024 [Page 4]
Internet-Draft VLAN-Switching March 2024
Table 1: VLAN-Forwarding routing table
+-----------------------------------------------------------------------+
| Src IP Address | Dst IP Address | Interface | VLAN |
+-----------------------------------------------------------------------+
| Source IP_A | Destination IP_A | INF X | VLAN_X |
| Source IP_B | Destination IP_B | INF Y | VLAN_Y |
| ... |
+-----------------------------------------------------------------------+
The source and destination IP address is used to identify the end to
end TE path in VLAN-based traffic forwarding network. The VLAN
indicates a VLAN forwarding path which is used to mark the traffic
that needs to be protected. Through the VLAN in the VFR table, a
VLAN forwarding path will be set up on its logical subinterface in
order to transfer the packet to the specific hop.
4.3. VLAN-Crossing routing table
Accordingly, the egress devices and transit devices need to maintain
a VCR table. The VLAN IDs of inbound and outbound form a key-value
pair which indicates a new VSP. The interface addresses indicate the
inbound and out bound sub-interface addresses that carries the
specific service traffic which needs to be guaranteed. The in-VLAN
is used to identify the traffic that needs to be protected while the
out-VLAN indicates the ID of the VLAN forwarding path that the device
will set up on its logical subinterface in order to transfer the
packet labled with this VLAN ID to the specific hop. To the transit
device, the value must not be 0 to indicate it is not the last hop of
the VLAN-based traffic forwarding path. To the egress device, the
value must be 0 to indicate it is the last hop of the VLAN-based
traffic forwarding path. Through the mapping of the in-VLAN and the
out-VLAN in the table, the data packet will be transferred to the
specific interface and be switched on the out VLAN for the transit
devices or 0 for the egress devices.
Table 2: VLAN-Crossing routing table
+----------------------------------------------------------------------+
| In-Interface | In-VLAN | Out-Interface | Out-VLAN |
+----------------------------------------------------------------------+
| INF1 | VLAN_X1_X2 | INF2 | VLAN_X2_X3 |
| INF3 | VLAN_Y1_Y2 | INF4 | VLAN_Y2_Y3 |
| INF5 | VLAN_Z1_Z2 | INF6 | 0 |
| ... |
+----------------------------------------------------------------------+
Wang, et al. Expires 20 September 2024 [Page 5]
Internet-Draft VLAN-Switching March 2024
5. VLAN-based traffic forwarding Procedures
In order to implement VLAN switching, the routers and switches must
support VLANs. Based on the business requirements, the packet to be
guaranteed will be labeled with corresponding VLAN tag. The tag may
be added or removed by a host, a router, or a switch which is out of
the scope of this document. The labeled packet will be further sent
to the router's specific subinterface identified by the VLAN tag and
then be forwarded.
ingress node transit node egress node
original +--+ +--+ +--+
packet---------->+R1+-------------+R2+-------------+R3+------>
+--+ +--+ +--+
+-------+ +----------+ +----------+ +--------+
|S&D MAC| | S&D MAC | | S&D MAC | | S&D MAC|
|S&D IP | | VLAN X1 | |VLAN X1_X2| | S&D IP |
| DATA | | S&D IP | | S&D IP | | DATA |
+-------+ | DATA | | DATA | +--------+
+----------+ +----------+
Figure 1: Data Packet Encapsulation Process
Figure1 shows the data packet encapsulation process of VLAN switching
operations. As a ingress node, R1 maintains a VFR table shown in the
table 3 below. Similarly, as a transit node and an egress node, R2
and R3 maintain a VCR routing table shown in the table 4&5 below
separately. Based on these tables, the specific VLAN will be set up
on their sub-interfaces. When the ingress node R1 receives a packet,
based on the source and destination IP, the packet that needs to be
guaranteed will hit the first entry in the routing table and then be
labeled with corresponding VLAN tag VLAN_X1.
Table 3: VLAN-Forwarding routing table to R1
+-----------------------------------------------------------------------+
| Src IP Address | Dst IP Address | Interface | VLAN |
+-----------------------------------------------------------------------+
| Source IP_A | Destination IP_A | INF X | VLAN_X1 |
| Source IP_B | Destination IP_B | INF Y | VLAN_Y1 |
| ... |
+-----------------------------------------------------------------------+
Wang, et al. Expires 20 September 2024 [Page 6]
Internet-Draft VLAN-Switching March 2024
After that, The labeled packet will be further forwarded to the
specific subinterface specified by VLAN. When the data packet tagged
with VLAN_X1 which is done by R1 is delivered to R2, it will look up
the VCR table via tagged VLAN. If the VLAN is consistent, the in-
VLAN as VLAN_X1 will be replaced with a out-VLAN as VLAN_X1X2 by the
current transit node R2. The packet labeled with new VLAN will be
further delivered to the next hop.
Table 4: VLAN-Crossing routing table to R2
+----------------------------------------------------------------------+
| In-Interface | In-VLAN | Out-Interface | Out-VLAN |
+----------------------------------------------------------------------+
| INF1 | VLAN_X1 | INF2 | VLAN_X1_X2 |
| INF3 | VLAN_Y1 | INF4 | VLAN_Y1_Y2 |
| INF5 | VLAN_Z1 | INF6 | 0 |
| ... |
+----------------------------------------------------------------------+
R3, as the egress node, its out-VLAN in the VCR table should be 0
which indicates it’s the final hop in the whole transit process.
Therefore, the egress node will strip the in-VLAN and the packet will
be transited directly.
Table 4: VLAN-Crossing routing table to R3
+----------------------------------------------------------------------+
| In-Interface | In-VLAN | Out-Interface | Out-VLAN |
+----------------------------------------------------------------------+
| INF1 | VLAN_X1_X2 | INF2 | 0 |
| INF3 | VLAN_Y1_Y2 | INF4 | VLAN_Y2_Y3 |
| INF5 | VLAN_Z1_Z2 | INF6 | VLAN_Z2_Z3 |
| ... |
+----------------------------------------------------------------------+
Based on the VFR table and VCR table, the original packet will be
transmitted along the path of the VSP through the exchange of VLAN
labels. Via calculating and deploying the optimal VSP by the central
controller, the overall QoS assurance effect is achieved, and there
is no more need to reserve resources for physical links in advance.
6. Security Considerations
The VLAN tag may be added or removed by a host, a router, or a switch
and be further distributed through CLI, YANG or control plane
protocol like PCEP, so the security mechanism of Vlan switching
mechanism mainly relies on the generation and forwarding process of
Vlan tags by these devices. The consideration should be given to the
security features discussed in [RFC4254] for CLI, [RFC6020] for YANG
and [RFC5440], [RFC8231],[RFC8281] and [RFC9050] for PCEP.
Wang, et al. Expires 20 September 2024 [Page 7]
Internet-Draft VLAN-Switching March 2024
, Security considerations for the Vlan switching mechanism
7. Normative References
[RFC4254] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Connection Protocol", RFC 4254, DOI 10.17487/RFC4254,
January 2006, <https://www.rfc-editor.org/info/rfc4254>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for PCE-Initiated LSP Setup in a Stateful PCE
Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
<https://www.rfc-editor.org/info/rfc8281>.
[RFC9050] Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "Path
Computation Element Communication Protocol (PCEP)
Procedures and Extensions for Using the PCE as a Central
Controller (PCECC) of LSPs", RFC 9050,
DOI 10.17487/RFC9050, July 2021,
<https://www.rfc-editor.org/info/rfc9050>.
Authors' Addresses
Yue Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangy73@chinatelecom.cn
Wang, et al. Expires 20 September 2024 [Page 8]
Internet-Draft VLAN-Switching March 2024
Aijun Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangaj3@chinatelecom.cn
Boris Khasanov
Yandex LLC
Ulitsa Lva Tolstogo 16
Moscow
Email: bhassanov@yandex-team.ru
Fengwei Qin
China Mobile
32 Xuanwumenxi Ave.
Beijing
100032
China
Email: qinfengwei@chinamobile.com
Huaimo Chen
Futurewei
Boston,
United States of America
Email: Huaimo.chen@futurewei.com
Chun Zhu
ZTE Corporation
50 Software Avenue, Yuhua District
Nanjing
Jiangsu, 210012
China
Email: zhu.chun1@zte.com.cn
Wang, et al. Expires 20 September 2024 [Page 9]