Problem statements and requirements of L2 CATS

Introduction 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 which illustrates a cats refrence framework.

Requirements Language 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 .

Service access problem statements and gap analysis of L2 CATS 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 be not made under the scenario of multiple cloud site deployment.

Requirements of L2 CATS Req 1 Service identification of Layer 2 protocols SHOULD be specified in the data plane for computing awareness traffic steering. Req 2 Computing awareness based information MAY be notified through a centralized computing awareness controller or distributed protocols.

L2 computing awareness traffic steering solution consideration 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.

+----+ +-*---+ * * # +---->| 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 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.

Computing awareness of L2 forwarding network 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 affinity 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.

Acknowledgements To be added upon contributions, comments and suggestions.

IANA Considerations This memo includes no request to IANA.

Security Considerations 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.