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]