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, . 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]