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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [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, . [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, . [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, . 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]