Problem statements and requirements of L2 CATS
draft-huang-cats-ps-and-requirements-of-l2-cats-02
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Daniel Huang , Bin Tan | ||
| Last updated | 2024-01-05 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-huang-cats-ps-and-requirements-of-l2-cats-02
CATS D.H. Huang
Internet-Draft B.T. Tan
Intended status: Standards Track ZTE Corporation
Expires: 8 July 2024 5 January 2024
Problem statements and requirements of L2 CATS
draft-huang-cats-ps-and-requirements-of-l2-cats-02
Abstract
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.
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 8 July 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.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
Huang & Tan Expires 8 July 2024 [Page 1]
Internet-Draft Abbreviated Title January 2024
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Service access problem statements and gap analysis of L2
CATS . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Requirements of L2 CATS . . . . . . . . . . . . . . . . . . . 3
4. L2 computing awareness traffic steering solution
consideration . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Service identification . . . . . . . . . . . . . . . . . 4
4.2. Computing awareness of L2 forwarding network . . . . . . 5
4.3. Service affinity . . . . . . . . . . . . . . . . . . . . 5
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. 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 [I-D.ldbc-cats-framework] which illustrates a
cats refrence framework.
Huang & Tan Expires 8 July 2024 [Page 2]
Internet-Draft Abbreviated Title January 2024
1.1. 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 [RFC2119].
2. 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 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.
3. Requirements of L2 CATS
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.
Huang & Tan Expires 8 July 2024 [Page 3]
Internet-Draft Abbreviated Title January 2024
4. 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.
+----------+
| 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 <------>
Figure 1
4.1. 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.
Huang & Tan Expires 8 July 2024 [Page 4]
Internet-Draft Abbreviated Title January 2024
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.
4.2. 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.
4.3. 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
Huang & Tan Expires 8 July 2024 [Page 5]
Internet-Draft Abbreviated Title January 2024
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.
5. Acknowledgements
To be added upon contributions, comments and suggestions.
6. IANA Considerations
This memo includes no request to IANA.
7. 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.
8. Informative References
[I-D.ldbc-cats-framework]
Li, Y., "A Framework for Computing-Aware Traffic Steering
(CATS)", June 2023, <https://datatracker.ietf.org/doc/
draft-ldbc-cats-framework/>.
[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
Daniel Huang
ZTE Corporation
Nanjing
Phone: +86 13770311052
Huang & Tan Expires 8 July 2024 [Page 6]
Internet-Draft Abbreviated Title January 2024
Email: huang.guangping@zte.com.cn
Bin Tan
ZTE Corporation
Nanjing
Phone: +86 13918622159
Email: tan.bin@zte.com.cn
Huang & Tan Expires 8 July 2024 [Page 7]