| Internet-Draft | Abbreviated Title | January 2024 |
| Huang & Tan | Expires 8 July 2024 | [Page] |
The computing intensive parts of the customer premise equipment have been decoupled and migrated to the cloud, therefore the thin CPE remaining at customer premise needs to access its “avatar” virtual CPE in the cloud which could be deployed in multiple edge computing sites. This draft will illustrate a use case of L2 traffic steering in terms of dynamic computing and networking resource status, together with requirements for CATS as well as solution consideration with regard to particularly the difference from the L3 routing framework.¶
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 8 July 2024.¶
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. 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.¶
A “thin” CPE could make the management and maintenance easy and render it as a cost effective device, which would send and receive service requests as well as service data traffic through the L2 access network, while the computing intensive and subscriber-related functions reside at the virtual CPE in the cloud, such as IPoE/PPPoE. What is crucially different from the traditional CPE deployment is the IP address would be allocated for the virtual CPE rather than the thin CPE in the customer premise. Therefore, the data exchange between the thin CPE and the virtual CPE would only be based upon L2 network, and the L3 routing would occur at virtual CPE as well as the networking entities outside of the L2 access network. Neverthelss, the access gateway where the computing awareness traffic steering occurs could be a L3 node capable of being aware of computing and always resides at the routing network edge although it acts as an L2 node when it comes to forwarding the service requests from the thin CPE. Therefore CATS framework would be suggested to address the requirements from this L2 scenario as discussed in some drafts in the working group such as [I-D.ldbc-cats-framework] which illustrates a cats refrence framework.¶
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].¶
As far as the thin and virtual CPE disaggregated deployment is concerned, the subscriber behind the thin CPE would have to firstly access to the virtual CPE in the cloud, and a 3 tuple of QinQ(SVLAN+CVLAN)/source MAC/destination MAC access policy needs to be configured at the access gateway. So the service request or traffic could be forwarded to the specific virtual CPE. Nonetheless, the virtual CPE could be deployed in multiple cloud sites in terms of both scalability and elasticity. The pre-configured and statically specified cloud site where the virtual CPE resides could accommodate the virtual CPE instance dynamics within the particular cloud site, while the access gateway would not be able to efficiently and dynamically steer the virtual CPE service requests to multiple cloud sites, because the access gateway as well as the according L2 access network could not be aware of any service resource status of the virtual CPE in the cloud. The cloud site as well as the virtual CPE instance selection thus could not be made under the scenario of multiple cloud site deployment.¶
Apart from the service traffic steering between physical CPE and virtual CPE in the cloud site, the same problems will arise under the use cases where the devices at the local site such as residence, campus etc. have been disaggreaged as physical part residing at the local site and the computing intensive part migrated into the cloud site. The networking between the two parts would thus be a layer 2 network without IP address involved. When it comes to computing aware service traffic steering in the layer 2 network, the existing solutions with QinQ and MAC addresses would be unnecessarily compicated.¶
Req 1 Service identification in Layer 2 SHOULD be specified for computing awareness traffic steering.¶
Req 2 Computing awareness based information should be notified through a centralized computing awareness controller or distributed protocols.¶
When it comes to computing awareness traffic steering in L2 network particularly with regard to data plane, there are limited options to be exploited and leveraged. Therefore, a compute awareness controller should be employed to manage the awareness of both networking and computing status of the cloud sites where the virtual CPE service resides. On top of compute awareness, the CA controller could also be responsible for scheduling of the traffic steering policies and delivering to the access gateway.¶
+----------+
| CA |<**********************+*<*****+
|Controller| A *
+----*-----+ * *
* * *
* * *
* +##############>+----+ +-*---+ *
* # +---->| PE1|--->|vCPE1| *
* # | +----+ +-----+ *
+----V-V-+ | Cloud site 1*
+-------+ +--------+ | Access |-------+ *
| pCPE |--->| switch |--->| | *
+-------+ +--------+ | Gateway|-------+ *
+------A-+ | *
# | +----+ +-----+ *
# +----->| PE2|--->|vCPE2|**+
+###############>+----+ +-----+
Cloud site 2
Computing awareness flow <******> <#######>
service traffic flow <------>
Service identification plays a key part in the end-to-end computing awareness traffic steering process. In particular, there needs to be a scheme in data plane to explicitly indicate the said service which is supposed to be deployed in multiple cloud sites. When it comes to the control plane, the service identification could be indexed to the service related computing and networking information and facilitate the service traffic steering in the data plane by mapping the said information as well as the service identification of the data plane.¶
However, there’s no room for service identification extension in the current L2 protocol system, so the source and destination MAC addresses and QinQ (SVlan + CVlan) should be reused as the service identification with newly specified semantics of indication of the virtual CPE service. Nevertheless, the virtual CPE service is both location and Vlan independent, so the service identification of the virtual CPE could correspond to multiple QinQ and MAC addresses.¶
As illustrated in figure 1, the pCPE in the customer premise sends service requests to the access switch which could be OLT/DSLAM where QinQ would be allocated and encapsulated in the data packets. When the service requests arrive at the access gateway which would always be BRAS/BNG, a specific virtual CPE instance has to be selected. Upon the computing aware traffic steering policy from the CA controller which has made the selection according to the computing status of the multiple cloud sites with vCPE deployment as well as the networking status if necessary, the access gateway maps the QinQ or MAC address in the data packet with the traffic steering policies, and forwards the service request to the selected edge PE as well as the virtual CPE instance through tunnel technologies such as SRv6 and VxLAN.¶
Specifically, when the compute awareness controller selects vCPE 2 in the cloud site 2 as illustrated in figure 1, the access gateway would actually in the first step establish an SRv6 or VxLAN tunnel with the corresponding edge PE which would extract the payload with the service request and forward it to the virtual CPE instance.¶
As is illustrated in figure 1, the computing awareness flow could also be delivered between edge PE and the access gateway directly through the existing protocols to be extended for computing awareness. The access gateway would be responsible for both the computing and networking policy as well as its execution for the service request traffic flows.¶
Service identification in CATS framework is specified to indicate a computing service which would be shared by multiple instances deployed among multiple cloud sites, rather than to indicate a specific service session or traffic flow. Therefore, the access gateway could not identify the traffic flow to make sure all of the traffic packets would be forwarded to the same and selected service instance by service identification alone, particularly QinQ under the vCPE traffic steering scenario at which the subscriber session state would be maintained upon the completion of the access control process. The data packets from the same traffic flow being forwarded to different vCPE instances according to the computing status dynamics would render the service in disarray.¶
The virtual CPE service affinity should be guaranteed at the access gateway by establishing a mapping table including source MAC address, QinQ and the selected edge PE identification upon the traffic steering policy instantiation with regard to the first data packet from the physical CPE, and the subsequent data packets of the specific traffic flow would be forwarded through this service affinity table.¶
To be added upon contributions, comments and suggestions.¶
This memo includes no request to IANA.¶
No additional encapsulation would be introduced into the L2 data plane and the extended service identification function of the existing MAC address as well as QinQ would only exposed to the CA controller which is supposed to be within the same manageable and controllable network domain of the L2 networking nodes. Therefore, there’s no additional security exposure with regard to this use case and the solution.¶