Internet DRAFT - draft-wang-ise-vlan-based-traffic-forwarding
draft-wang-ise-vlan-based-traffic-forwarding
ISE Working Group Y. Wang
Internet-Draft A. Wang
Intended status: Standards Track China Telecom
Expires: 2 September 2024 B. Khasanov
Yandex LLC
F. Qin
China Mobile
H. Chen
Futurewei
C. Zhu
ZTE Corporation
1 March 2024
Procedures and Extension for VLAN-based Traffic Forwarding
draft-wang-ise-vlan-based-traffic-forwarding-00
Abstract
This document defines the data plane operations around VLAN switching
and describes a standard method for implementing VLAN tags, and thus
the desired tag manipulation can be achieved.
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 2 September 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Wang, et al. Expires 2 September 2024 [Page 1]
Internet-Draft pce March 2024
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Scenarios and Requirements . . . . . . . . . . . . . . . . . 3
5. VLAN-based Flow Labeling Behavior . . . . . . . . . . . . . . 4
5.1. VLAN Functional Categorization . . . . . . . . . . . . . 4
5.2. VLAN-Forwarding routing table . . . . . . . . . . . . . . 4
5.3. VLAN-Crossing routing table . . . . . . . . . . . . . . . 5
6. VLAN-based traffic forwarding Procedures . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
In a typical Layer 2 network, all devices connected to a switch are
part of the same broadcast domain. 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 standardized VLAN-based flow labeling behavior can
be achieved.
2. 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 [RFC2119] .
Wang, et al. Expires 2 September 2024 [Page 2]
Internet-Draft pce March 2024
3. Terminology
The following terms are defined in this draft:
* VSP: VLAN switching path
* VFR table: VLAN-Forwarding routing table
* VCR table: VLAN-Crossing routing table
* VTF: VLAN-based traffic forwarding
4. 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.
Wang, et al. Expires 2 September 2024 [Page 3]
Internet-Draft pce March 2024
5. VLAN-based Flow Labeling Behavior
5.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.
5.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.
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
Wang, et al. Expires 2 September 2024 [Page 4]
Internet-Draft pce March 2024
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.
5.3. VLAN-Crossing routing table
Accordingly, the egress devices and transit devices needs 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 |
| ... |
+----------------------------------------------------------------------+
6. 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.
Wang, et al. Expires 2 September 2024 [Page 5]
Internet-Draft pce March 2024
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 |
| ... |
+-----------------------------------------------------------------------+
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.
Wang, et al. Expires 2 September 2024 [Page 6]
Internet-Draft pce March 2024
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.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Authors' Addresses
Yue Wang
China Telecom
Beiqijia Town, Changping District
Beijing
Beijing, 102209
China
Email: wangy73@chinatelecom.cn
Wang, et al. Expires 2 September 2024 [Page 7]
Internet-Draft pce 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 2 September 2024 [Page 8]
