**Session Date/Time:** 16 Mar 2026 06:00

**Adrian Farrel:** Hello. Okay, sure. Okay. Good afternoon everyone. Welcome to Shenzhen. Hope all of you have a good journey. And it's the CATS working group meeting. And we are Peng Liu and Adrian as the co-chairs. So, first is the note well for every meeting. So, you are agreed to follow the IETF process and policies. And just remind that every participant is expected to have a good behavior and to show your respect to your colleagues. And if you have any questions about the IETF contribution, please see the RFC. And if you have any problems with the behavior of others, for instance, in some harassment policy, you can contact the Ombudsteam. So, just to see your questions and any concerns. So, the audio and video are recorded in the IETF policies. And for any advice, please talk to the chairs or the ADs. So some meeting tips for the in-person participants: make sure to sign into the session via DataTracker. And I see a lot of people here but there's not enough people just in the onsite DataTracker. So, join the mic queue and participate in show of your hands. And just to remind: keep the audio and video off if not using the onsite version. And for the remote participants: make sure your audio and video are off unless you are chairing or presenting. So, please help to take the minutes. The chair just sent also the links to the chat box.

So this is the agenda for our meeting this time. We have two working group documents and also have four upcoming documents, including the OAM, security, YANG model, and the metrics-related one. And we will discuss the protocol applicability and the optical with CATS. And if there is time, we also have some individual drafts, but please just pay attention to the time and just to adjust your presentation.

**Adrian Farrel:** Zheng Han, are you in the room? Zheng Han? Yeah, thanks. Could you send me your slides again? Can you email them to me? Your presentation.

**Speaker 2:** (Inaudible Chinese)

**Adrian Farrel:** He didn't have slides? 

**Speaker 2:** Maybe not.

**Adrian Farrel:** Zheng Han? Han Zheng? Is Han Zheng here? Did you send your slides? 

**Han Zheng:** Yes. 

**Adrian Farrel:** Okay, so I'll just go ahead and... yeah. Okay.

**Peng Liu:** So here is the working group documents status. We just sent the requirements, use case and framework to the IESG. And we have one active draft about the CATS metrics (draft-ietf-cats-metric-definition), need more discussion. And so the milestones here, we just to follow one is that we will submit the CATS metric to the IESG if we get good consensus on it. Okay, sorry. Anyone has comments on the agenda? Okay, so we go to the presentation. So the first one: [2.1. CATS-Framework](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-21-cats-framework-00). Cheng.

**Cheng Li:** Hello everyone. I'm Cheng Li from Huawei. So, I'm really happy to have this opportunity to share the latest progress of our CATS framework document. Next please. Yes. So basically, as usual, like, we only have two parts in my presentation. The first one is about the change since the last IETF meeting. And the second part is about next step. Next please. No, no. Not working.

The good news is that we have passed the working group last call with strong support from everyone. So thank you so much. And right now, we have also addressed the IESG last call review comments from different areas. For example, the comments from Tommy Pauly, he provided the comment from TSVART, right? So we also thanks to Thomas for his review from GENART and also Linda from the security and RTG area. And also, we are waiting for Guienne's, you know, confirmation of his comments if we addressed it or not. And that's the only comment left that we need to confirm here. And also, we thanks to Giuseppe for his early review comments from the OPS area. And because I'm crazy, I was very busy to, you know, prepare for this IETF meeting and the social event tomorrow. So I special thanks to Matt to hold a pen of editing the drafts from like revision 19 to revision 22. Yeah, thanks to him. Next please. 

And the next step is quite easy because we have addressed nearly all the comments right now. So we only need to get a confirmation from Guienne and then we will send the document to the IESG last call. And we believe that we will pass all the... we addressed all the comments because mainly, you know, we only received some minor, you know, comments like there's no so major considerations regarding this document. So thanks to all. And hopefully we can publish this document as an RFC in the like... before next meeting, maybe. Yeah, thank you. Comments?

**Adrian Farrel:** Thank you Cheng, and thank you for arranging the social for everybody as well. Our AD is super efficient and this document is on the telechat on the 2nd of April. So, keep an eye on that but should get through okay. 

**Cheng Li:** Perfect. Thank you. So I'm happy that I saved some minutes for you. Good. Thank you.

**Peng Liu:** Okay, thank you. And next: [2.2. CATS Metrics](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-22-cats-metrics-00) (draft-ietf-cats-metric-definition). 

**Kehan Yao:** Hi everyone. I'm Kehan from China Mobile. So, I will introduce the current progress of CATS matrix definition, the third working group document. And yeah, next slide please. 

So we have like two revisions since IETF 124. And here are some major changes. First is the author and we want to give special thanks to Han Shi for his initial contribution to the formulation of the draft. And his colleague, Guanmin Zhang, has already been, you know, helped formulate the draft, help improve the draft and taking over his work. And also on the mailing list after the previous meeting, we had strong support from the working group that changed the document type into standards track so we can, you know, register our matrix into IANA. And so this time, from the past two revisions, we major added matrix registry entries for CATS level 1 and level 2 levels matrix for IANA request. 

And two notes here: so this document will not standardize level 1 matrix because of their, you know, this level is too diverse and it depends on the implementation for choosing what kinds of level 0 matrix you want to use. And second note that this document would not force the choice of normalization/aggregation functions. We just give some examples to generate level 1 and level 2 matrix, but don't force them. Next slide please. 

Yes, for the, you know, metric registries for CATS, we follow some templates from RFC 8911 and 8912. I think... here I special thanks to Greg Mirsky's comment and also Adrian's for their comments on referencing, making reference to these RFCs. These two RFCs give some guidelines and also format for registry performance matrix. For example, like packet delay variance and also like jitter or something else. But for CATS matrix, so we follow the similar matrix registry templates with the following register terms like summary: basically it includes like identifier, name, URI of the metric, and the metric definitions and method of measurement because, for example, in the matrix is actively measured or passively measured or in hybrid mode. And also like packet stream generation and traffic filtering method. And also like defining some runtime parameters and their corresponding units. And also it covers... it will cover like output with like the different types of the output and units and also their calibration method. And then some like administrative information about the controller, about the version, etc. And also the comments and remarks. So basically these six, you know, items. Next slide please. 

So to be continued: so we basically have five matrix here: one level 2 matrix and four level 1 matrix. So you can see the name here. The RFC number and section number will be finalized when we determine later on. And for the matrix definition, we here we use normalization score range from 0 to 10 to indicate the capability of each, you know... for each matrix. And the data precision here we for this five matrix we use decimal number, the unsigned integer represents them. Next slide please. 

And then for the method of measurement, we define several reference methods from collecting raw matrix. For example, you want to collect like compute matrix you might use like open source tool like Prometheus, or you want to collect network matrix using existing network protocols like Netconf, IPFIX, etc. And also we provide some aggregation logic and normalization logic examples. For example, for aggregation you can use weighted sum and sigmoid function for normalization. But we don't force them as I previously explained. And also some runtime parameters here like CATS service contact instance ID, service instance IP, and measurement window we also defined them. 

And then about metric collection roles. Here basically, as defined in the CATS framework, there are two basic components to collect matrix: the CNMA to collect network matrix, network metric agent. And the CSMA, the service metric agent is for collecting compute matrix. But here, as we discussed internally within co-authors, we have a small technical question for the audience. So, do you think CSMA also can collect communication matrix for computation of level 1 communication or composed matrix or level 2 matrix? So we don't get a consensus now so waiting for audience to provide some suggestions. And also please help review the metric collection roles for each register matrix. Thank you. And so we also define like output, you know, score semantics and calibration method. Okay, thank you. Basically all of these level 2 and level 1 matrix are provided in section 6. 

And as Pun has already mentioned in the chair slides: so for the milestone after this meeting, we want to, you know, ask for working group last call of this CATS metric definition. So, are there any important issues that are still unclear? So please mention it in this meeting and also in the list. And also if the document is mature enough, we want to go for working group last call. So, thank you all for reviewing the draft. Thank you. 

**Peng Liu:** Okay, thank you. So do you want ask the audience about this question? 

**Kehan Yao:** Ah yes, go back. Yes. This is a small question. I think it's more in details a technical question. If you have an answer here, you can, you know, comment here. But if you need some more thoughts, please, you know, we can exchange our ideas in the list. 

**Peng Liu:** Yes, anyone has any thoughts on the questions list here because the draft's now stable and hasn't had any unresolved questions. Okay, maybe no one wants to say. Okay sure. Does this question need to be solved or we can...

**Kehan Yao:** Yeah, exactly. Yeah. I mean we can, you know, ask this question in the list. About the general question. Yeah. Because people may need more, you know, they want to think it, you know, deeply and give some suggestion after this meeting. So, yeah. We don't need to, you know, make a decision here. 

**Peng Liu:** Okay sure. So I think the draft is going to be mature and hope everyone could review this and send your comments. If there's no more comments or no big issues for it, we will chat to the AD to see if we could submit to the IESG review. Yeah. Thank you. 

**Adrian Farrel:** Okay, thank you. So next: [3.1. CATS OAM Framework](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-slides-for-presentation-draft-fu-cats-oam-framework-00).

**Fu Junsong:** Hello everyone. This is Junsong from ZTE. I will present the CATS OAM on behalf of the co-authors. 

Thank you. And this document has been presented in last meeting. And thank you for the comments from Adrian and Weiling and Cheng. And we have updated the version from 4 to 5. We clarified the motivation and the problem based on the OPSWG area and for the RFC 5706bis from the Adrian's suggestion. We updated the motivation and clarified for the CATS OAM and emphasizing the function gaps. 

So, we also updated a CATS layering model. We divided four layers for CATS OAM layering model and also we updated the CATS OAM components. For example, the SI-OAM and the SVC-OAM. And we updated the CATS OAM requirements and removed the deployment consideration. 

First, for the motivation and problem for CATS OAM: why do we need a new OAM? For example, for the traditional or the existing OAM, the monitoring OAM will stop at the egress router and we need to extend it into the service instance. So, for CATS, the path must be from the network to the service instance. And if we have no information or did not monitor the service instance, if the service instance is overloaded or crashed, the traffic steering will fail. So this is the motivation for the new CATS OAM. 

So this is the relationship between the CATS existing framework, use case and the metric definition and the OAM framework. The CATS framework will provide the foundation and the basic architecture for the OAM. And use case and the requirements will provide the reason to provide the OAM. And the metric: we will define the metric and we will use the metric to monitor the... to define the metrics that we need to monitor. And so we need to define a new OAM framework to monitor and ensure the CATS end-to-end service. So we will leverage the existing IETF OAM standards as the following show. For example, the RFC 7276 and the RFC 5706bis as we just mentioned. The RFC 6291 and the other BFD-related drafts. 

And for the layering CATS OAM layering model, we defined the four-layer CATS OAM model. And two parts of them are new and the existing... the path OAM and link OAM is can use... we can use the existing technologies. So for the two new OAM components, we will define the SI-OAM and the SVC-OAM. 

And for SI-OAM, it need to provide status monitoring. For example, we need to provide the instance availability to CATS CSMA. And we also need to provide the metric monitoring. And the metric has been defined in the metric definition. 

And for SVC-OAM, it need to provide the policy verification. For example, to provide... to check the classification rules, steering rules and forwarding behavior. And for the joint performance measurement, we need to measure the end-to-end latency. And for multi-domain fault isolation, we need to correlate the four layers to pinpoint the root cause for the troubleshooting. 

So these are all the updates for the CATS OAM and the co-authors want to make sure that if the CATS OAM are the necessary work for the CATS working group. So we also appreciate further review and feedbacks in the mailing list. Thank you. So, any questions? 

**Adrian Farrel:** Huaimo, please. 

**Huaimo Chen:** Okay, thank you. Huaimo, Huawei. Yeah, actually the OAM work is very useful. Thank you for that. And we do see you mentioned the L3/L4, maybe the network layer, right? When you do the OAM, but I do have some concerns on using the acronym because the previous document metrics are having the L0, L1, L2 metric. Not the layer, but the kind of level which is specified have the rules. So, I'm wondering whether we need to change a little bit on all this kind of terms. And secondly, there would be more layers in the network for the OAM to do. So we are going to evaluate if there are some additional input from network layer 1 and 2 and then try to contribute together. Again, this is very useful. Thank you. 

**Fu Junsong:** Yeah, thank you. We will to confirm the metric definition, the draft. And there have L0, L1, L2. Maybe we will monitor one of them or all of them. So we will clarify it in the further version. Thanks. 

**Adrian Farrel:** Yeah, I think that's kind of important. So, it's really nice to see OAM being worked on. We've got to be really careful about those bits of OAM that are CATS system OAM and those bits of OAM that are for the plumbing, the network, because that second half doesn't belong to us apart from maybe asking for additional requirements for behavior. But I suspect all we need to do for the network is say OAM already exists and we build on it. And the new work that you'll be looking for is actually how do we measure what the CATS system is doing. 

**Fu Junsong:** Yeah, yeah. Thank you for your suggestion. Yeah, we mainly focus on the service instance and using the existing network OAM. 

**Adrian Farrel:** Okay, thank you. And we move to next. Thank you. Next: [3.2. CATS Security Considerations](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-32-cats-security-considerations-01). 

**Jinyu Shi:** Good afternoon everyone. I'm Jinyu Shi from China Unicom. And I'm very happy to do this presentation for security consideration for CATS. And the draft is now version 4. 

As we all know the CATS can optimize traffic forwarding by combining network and service metrics. To do this job, the CATS has several functional components. And each component has its own security issues and risks. So in this picture we can see the security risks that the components face, including CSMA security, CNMA security, C-PS security, and C-TC security, and CATS forwarder security, and underlying infrastructure security. And this draft is about the security risks that CATS functional components faced and we also give some suggestions about how to protect the functional security. 

So first, let's talk about the CATS Service Metric Agent (CSMA) security. This CSMA is responsible for collecting service capability and status. And it faces the following three potential risks. First one is man-in-the-middle attack. Attackers may forge nodes or hijack links to report false metrics, which can lead to incorrect path decision. And the next is false service instance registration. Attackers can register fake instances without strict authentication causing CSMA to collect and distribute invalid metrics. And next is DoS attack. Attackers send a large number of requests to exhaust computing resources and make it unable to collect legitimate metrics. 

So the counter measures are right here. The first one is deploy CSMA in a trusted zone. So we can place CSMA inside the service site or trusted areas of the egress forwarder, restricted direct external access via firewalls. And the second one is enforce rate limiting for request. We can set a threshold for single source collection requests to block malicious flood request and avoid DoS attack. And the next is whitelist mechanism for service instances. Only collect metrics from a whitelist instances, enforce strict identify authentication for new registrations. 

And the next component security is about CATS network metric agent security. The CNMA can collect sensitive network data. And it faces the following risks. So the first one is sniffing attack. Sensitive network data may be intercepted, enable attackers to identify weak nodes. And next is false metric injection. The vulnerabilities is reused protocols may allow injection of fake metrics destroying network perception. And the third one is protocol vulnerability exploitation. So the unpatched vulnerabilities in running protocols can be exploited to infiltrate the CATS network. 

The counter measures are as follow. So the first one is adopt security-enhanced routing protocols. We can use security protocols for secure metric collection and transmission, preventing the fake metric injection. And next is employment data desensitization. Distribute only core decision-making metrics to CPS, and masking sensitive topology details to avoid leakage. And next is regularly update NMA firmware and protocols. We can match vulnerability per IETF RFC standards and conduct quality secure scans. And the last one is encrypt transmission links. We can use the TLS 1.3 with mutual certification authentication between CNMA and CPS to prevent man-in-the-middle attack. 

The next one is C-TC. The C-TC can classify the service traffic. and it faces the two potential risks. So the first one is classification rule tampering. Attackers may tamper with the rule table to disguise malicious traffic as legitimate service traffic bypassing checks to enter the CATS network. And the next one is fake classification result forgery. Without authentication on the celebration link attackers can forge results leading to incorrect discarding or forwarding of legitimate traffic. 

So the counter measures are as follow. The first one is encrypt and incremental updates. We can store rules in AES 256 encrypt form and implement incremental updates with multi-factor authentication to prevent unauthorized modification. And next is active standby CTC cross-validation. We can deploy primary and backup CTCs on the ingress forwarder and forwarder traffic only when both updates are consistent, along single point hijack areas. So the next is log clarification operations in real time. And the last one is validation CS-ID and CSC-ID legitimacy. 

The last component security I will introduce today is CATS forwarder security. And the potential risks are as follow. The first one is encryption key leakage. The stolen keys enable decryption of overlay traffic and theft of service request. The next is fake service instance forwarding. The traffic is forwarded to unverified fake instances leading to hijacking. And the last one is flood traffic attack. Malicious requests consume bandwidth and computing resources. So the counter measures are as follow: first one is regular key rotating; and the second one is CS-CI ID and certificate binding; and the next is traffic cleaning; and the last one is overlay and underlay isolation. 

The security I just introduced is update in this version. And there are two component security we have introduced in the last version. So these two including CPS security and underlying infrastructure security has not changed in this version. And the service announce workflow and metric distribution workflow has also not changed in this version. So that's all for my presentation. If any question. 

**Adrian Farrel:** Jim, please. 

**Jim Guichard:** Yeah, good morning. Thank you for the presentation. One thing that was going through my mind is have you cross-referenced this against the security considerations that were called out in the framework document that I've got on the telechat coming up? And if you haven't, please take a look at that security considerations section because there's a lot of things in there that were called out in the framework that would certainly need to be taken care of. So, it's difficult for me to tell just looking at this presentation. I haven't read your draft at this point. 

**Peng Liu:** Some echoes from the remote I think. 

**Adrian Farrel:** Yes, so the question as I heard it was please look at the security considerations in the framework document and make sure that you're properly tied in with those. 

**Jinyu Shi:** Okay, okay. Thank you. 

**Peng Liu:** Another suggestion is that please sort out which risk has higher priority because you list so many risks behind the CATS elements. So just to select which one is more important. 

**Jinyu Shi:** Okay, okay. We'll consider it and do something in the next version. 

**Peng Liu:** Okay, thank you. And we go to next. Thank you. Next: [3.3. Yang Model for CATS](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-slides-for-draft-yl-cats-data-model-05-00).

**Fu Junsong:** Hello everyone. This is Junsong again. I will present the data model for CATS on behalf of the co-authors. 

We also have presented this document at 123 and 124. And thank you for the comments from Joel, from Adrian and Peng. So we also updated the draft based on these comments. 

First of all, we do some editorial modification for the whole document after a deep review. And we also defined the terms and moved some discussions to the terms section used in YANG model, for example in section 1.1. And we removed the forwarding plane YANG. And we want to define a YANG model but it's not depend on the solution. And we also changed the structures of the document to enhance the readability, just like the below. We changed the all sections and titles and remove some of the sections. 

So, the first update is that we updated the overview of the CATS system to align with the framework and functionality functional components. Just like the figure, we align with the framework, the components, for example the CSMA and the CPS, data plane, control plane and management plane. We defined the database and interfaces in the as a new term and used in the YANG model. For example, we defined the CCIB to be used for the network, for... it is responsible for maintaining the CATS network computing information. And it provide base data for the CSMA. And we also defined the CNIB to responsible for maintaining the CATS network information and it used it for the CNMA. And we defined two new interfaces. For example, the CATS-SBI: it can be used between the CATS forwarders and the CATS control plane. It can be used to report the computing metric information and it also can be used to send the path and service policy information from the control plane to the CATS forwarder. And for CSMA-API, it can be used between the control plane and the management plane and the CSMA. It can be used to report the service metric information to the control plane or from control plane to the CATS forwarders. 

The second update is the CATS data model structure. This model extends the imports and augments the IETF routing YANG model defined in RFC 8349. It is not... it does not depend on some specific solution or some protocol. So it adheres to the CATS framework. And so it can be viewed as a critical diagnostic and control mechanism. So the CATS YANG model can include the basic CATS objects, traffic classifier objects and service metric objects and also include the notification. So we also removed the forwarding plane YANG. It is applicable to the CATS-SBI and the CSMA-API. 

So we... the co-authors think it may be ready for working group to consider the adoption. Thanks. 

**Adrian Farrel:** Yeah, so thank you for that prompt about adoption. As the working group has now pushed two drafts out to Jim and has another roughly approaching last call, the chairs are going to sit down and try and make a plan for what's next and then run that past the working group. And certainly these last three drafts that we've had are kind of high candidates for us, but we need to just sit and think about it carefully and then we will come to the working group and work out what we should be on next. 

**Fu Junsong:** Yeah, thank you. 

**Adrian Farrel:** Okay, next: [3.4. Computing metrics as a service (CMAS)](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-34-computing-metrics-as-a-service-cmas-for-facilitating-traffic-steering-in-cats-framework-draft-zhangb-cats-cmas-02-00). 

**Ina:** Hello everyone. I'm Ina. Today on behalf of my co-authors, I will present our updated draft computing metric as a service. It provides a service-oriented approach for CATS traffic steering. 

So let's start with a fundamental question: what do client and CPS need? Do we really need disseminate specific computing metrics? Let's look at different roles. First, client: they want to consume service, they want to know what service are available. So they don't need any specific computing metrics. From CPS perspective: its work is steering traffic. It needs to know which service are available at which nodes. So it doesn't need concrete computing metrics either. Actually, we need specific computing metrics locally only when we allocate the resource and deploy the service. Once the service is up and running, no matter raw metrics or aggregated metrics, it's completely unnecessary. So we propose that the network should only disseminate lightweight service level information. 

To achieve this, we introduce the public service platform, hosting logical registry called Public Service Table. It's an example of the table. It acts as a standardized recipe config for all available services. For client: this table defines what service exists and the required input, the expected computing time. It helps them understand the service and formulate requirements. For service site: this table defines the minimum computing requirements and storage requirements. The service site just query this table to fetch the running code and the software dependency and then allocate resources to deploy the service. The complexity of the hardware is completely hidden behind this table. 

Once the service is deployed, there will be an critical transformation. Instead of disseminating raw metrics, the service site model their results into service unit, as shown in Table 2. The most important metric is GAS, or globally available slot. For example, 3 here means that the site has three AI-1 instance at port 67, and it also provides the cost and local computing time. The site has full control over its capacity and the table is only thing needed to advertise to the network. 

This diagram shows overall information flow. The CSMA of each site collects the service level information and then advertised... advertised. The CPS collect them and append the network metric provided by the CNMA and then form a whole service table for the control plane. 

Then I will introduce you a concrete case. First, service modeling: service site 2 and site 3 deploy services and model their results into simple tables, just like this. Site 2 says it has three AI-1 instance at port 67 and four at port 68. Site 3 says it has six AI-1 instance at port 69 and three LLM-1 instance at port 70. 

Then service distribution: the CSMA then advertised the simple tables. The CPS collect them and combined with the network delay from CNMA. The result is a whole service table, just like this. It provides GAS, cost, computing time, network delay and contact address. Additionally, the network is full... is completely free of any raw hardware metric. 

Finally, service consumption: when client request AI-1 service and needs the lowest delay, the CPS then check this table and calculate the total delay, select the optimal one. In this case is this. Once the traffic is steered, maintaining the resource state is very easy. Look at the locate step: the CPS then decrement the GAS from 3 to 2, and when the service complete, the release step will increment the GAS back to 3. It's a highly scalable plus 1 and minus 1 operation. 

Let's watch a demo video. (Inaudible). Unfortunate that we can't play this video now, or we may update it and so we can check our demo. 

So why we choose CMAS? First, service level abstraction: it transforms raw data into actionable service unit at the source, decoupling hardware complexity from network routing. Second, strict compatibility: fully compatible with existing CSMA, CPS and CNMA components. Third, privacy preservation: raw computing metrics remain local, protects the proprietary infra data of service provider. 

For our next step, we will refine service unit template and accident GAS metric. We also seek more use cases and collaborators. Thank you very much. So if you have any question, I'm ready to answer it. 

**Adrian Farrel:** Guanmin, please. 

**Guanmin Zhang:** Thank you for your excellent presentation. And I'm Guanmin from Huawei Technologies. And I have a question, which is that the draft clearly separates computing metric advertisement from network topology. However, optimal path selection requires a consistent view of both compute and network state. How do you handle the synchronization between the CMAS updates and routing protocol convergence? 

**Ina:** Thank you for your question. The update frequency from the CSMA, we also... the framework is only concern about the usage of the slots. So if the service site has its metric update, it just give us some the GAS change and we will update our slots. We don't care about the detail of hardware metrics. 

**Speaker 3:** He's my student. I think I am the teacher. So I think the thing you care about is the table, how to work with the network convergence. Actually, the SDN controller has the TEDB database for his network topology and link state. Combining the... in this work, we have disseminate the service unit table, service information table, it's very lightweight table. After the table get to the CPS, the CPS will combine in the table to form the whole service table. The service table is also very lightweight. And the CPS combining the service table with the TEDB, he will get the decision how to steering traffic. So it do not interfere the network convergence. It's just the table to very light table to get to the CPS. The service information is very clear in the table and it's when consuming a service, just need to change the value of the GAS. So I think it is... and we have realized the system using the framework, using the framework. So I think it is very important for our group to first run... run the system to just to make the framework run. It's a very important thing I think. 

**Peng Liu:** Okay, next: Cheng. 

**Cheng Li:** Chuan-Shun from ZTE. Thank you for your presentation. And I wonder that what's the difference between the L1, L2 metric and the service unit, because from my view, they were aggregate the raw metric to several specific metrics. 

**Ina:** Thank you. The L1, L2 metrics are the some... we can say it is normalized physical metrics. But our metric is not concern about the physical. We... the service site use these metrics to calculate the service unit then it just send the service units that are our service metric to the internet... to the network. Then the network don't need to know the physical details. 

**Peng Liu:** Then maybe it would be better to add some augment to the L1 and L2. Okay, please move the discussion to offline because it is too specific. And from the working group perspective, you may consider that find out what should be done in the CATS working group document from your draft. And second one is that find out what you want to do in this working group. First is for the working group document CATS metric and another is that what you want... because in next steps we didn't see that what you want from the working group, right? Okay, thank you. Thank you for this interesting work. And we need to move to next one. 

Next: [4.1. Protocols Applicability for CATS](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-protocols-applicability-for-cats-03). 

**Huijuan Yao:** Good afternoon everyone. I'm Huijuan Yao from China Mobile. Now I'm happy to share our analysis about protocols applicability for CATS. 

Firstly, let's to talk about why we submit this draft. There are three things: one is to analyze existing IETF protocols for CATS applicability. Two is to evaluate extensibility for three key areas, including metrics collection and distribution, and path selection and traffic steering, then as well as service mapping and management. More importantly, this draft is no new protocol proposal. It is focused on analysis of the existing IETF protocols to the CATS system. 

Now let's have a go over the CATS framework quickly because it is our basis of our this draft. Now as shown in this figure, there are four key function components including CSMA, CNMA, CPS, CTC. From architecture view, we can see CATS can work in three planes, interconnected three planes including control plane, data plane and management plane. The working flow is very straightforward. It then we can collect metrics including network and computing metrics and then we can select a path for the service flow and then we make traffic steering to the corresponding service site. 

Now let's go to the core of this draft. We evaluate CATS applicability from the three plane including control plane, management plane, data plane. Then we step into one step by step, go through focus on the which protocols are extended. 

Let's go to the CATS control plane applicability. It is core part of the CATS applicability. It covers metrics distribution and path selection and traffic steering. As shown in this figure, we can see for metrics distribution for egress node, as shown in egress 1 or egress 2 can advertise metrics to the CPS with BGP extension or YANG model extension. If the egress as CPS, as shown in egress 1, egress 2, egress can advertise metrics from the CPS data from IGP/BGP extensions. For path selection, as well as CPS compute the optimal path and distribute to the egress through the PCEP extension. For traffic steering, it the controller sends the routing policies to egress via BGP flowspec to traffic steering to the corresponding site node. 

Let's move to the management control applicability. It main include configuration and provisioning and monitoring and telemetry. For configuration and provisioning we will extend the YANG model to configure CATS policies, CS ID mapping and CSMA, CNMA parameters. For monitoring and telemetry, we can set up YANG model PUSH and telemetry to management stream real-time CATS flow, such as status, path performance and compute resource status to management system. For OAM enhancement, we can extend the Ping/Trace operations to target specific CS ID for service level fault detection and path verification. 

Let's go to the CATS data plane applicability. For data plane, it is focusing forwarding and data forwarding and it can fully rely on existing data plane. That is, there is no new data plane. As shown in this figure, we use case for SRv6 data plane. It end-to-end process is very simple. For ingress node, it can classify packets, then encapsulate with correspond header to point to the select egress. And for egress node, it can decapsulate and deliver data to local interface. 

To make it clear, we make a summary table for protocol extension analysis. For control plane, it is very important, very critical for our draft. It can extend BGP LS, PCEP or BGP flowspec. For BGP-LS we can need extend the new metrics for computer or component metrics. For PCEP we can add a new objects to carry compute constraints or performance. For BGP FS, we can add a new match criteria for CS ID. For management plane, it is core model is about YANG. We can enhance models for CATS configure telemetry and OAM. For data plane, it is fully dependent on the IPv6 and SRv6 existing protocols. It just only define SID semantics for CS ID. 

The great thing for this draft is to analyze existing protocol to work in CATS and well still enabling efficient compute and networking convergence. Maybe we hope it can give a clear workable path to deploy CATS. Thank you. This draft is just a first version. We would like look forward any questions or comments. Thank you. 

**Peng Liu:** Xinxin, please. 

**Xinxin:** Hi, Xinxin from China Unicom. Okay. We think this work is very important and it's meaningful. And my first question is will this draft end up giving specific protocol recommendation for the deployment, such as you will recommend the BGP-LS for the distribution or you will recommend the some other protocol to the specific deployment? You will do this? 

**Huijuan Yao:** About this question, this draft just analysis BGP-LS protocol. Of course it can include other protocol extensions to work and this... 

**Peng Liu:** No, I think it was individual draft, right? And it do the analysis work. And I think for this draft just any related protocols could be added in this draft. Because it do the analysis work, not the solution or recommend any protocols to realize the CATS system. So you mentioned BGP-LS, that could be added in the draft. 

**Xinxin:** Yes, thank you. Because we proposed some protocol draft to do the CATS metric collection or the distribution. We want to discuss this work. 

**Peng Liu:** Okay, thank you. 

**Adrian Farrel:** Jeff Tantsura. 

**Jeff Tantsura:** Hi, Jeff Tantsura. One of the things that would be useful to discuss in the document is the rate of change of the state for the control plane. As the example, if you want to use BGP-LS, BGP-LS typically does not handle fast churning data. 

**Adrian Farrel:** Yeah, so I think the ask there is that you add to this document some consideration of the amount of data and the rate of change of data so that that helps us understand which protocols are best suited to each job. 

**Huijuan Yao:** Okay, thank you. 

**Peng Liu:** Okay, thank you. Please just consider the chair's suggestion and update the draft. And it is a good draft, maybe before any CATS solution draft. So thank you. 

Next: [4.2. BGP Edge Metadata Path Applicability](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-42-bgp-edge-metadata-path-applicability-00). 

**Linda Dunbar:** Good afternoon. This is Linda Dunbar from Futureway. So today I'm just going to give you a little update of what we have done in BGP in IDR group about the metadata path attribute and see how it can be applied to the metrics specified by CATS. 

So here's the summary of this edge metadata path attribute specified by IDR. It's optional, non-transitive BGP path attribute, can carry the metadata. And it is very important that not every prefix carry this path attribute. We want to make this only for a small subset because it carry lots of data through the network. And it's really based on the local configuration. And here we show on the actual BGP message has the path attribute. 

Okay. It is very important in the IDR group we talk about this is really for the limited domain metadata distribution. All the BGP speakers have to announce it during their open message to show they are capable of supporting it. And there's a flag when you send the open BGP open message, you can either allow this metadata to be available for all the AFI/SAFI or limited. If it is limited, you basically list down all those AFI/SAFIs. And it is very, very important from IDR's perspective to constrain the distribution of those metadata because it does contain sensitive information you may not want to... operators may not want to propagate those information to unintended audience. So in the BGP mechanism, there are three methods to achieve this method: one is non-advertisement community, one is AS scope adding a AS scope sub-TLV, one is the route filter and the policies. 

Okay. So here we want to emphasize this limited domain. The limited domain is really defined by deployment: it could be one region or one specific area for the deployment. And in this domain, the metrics can be propagated, but it cannot cross the border. 

Okay. So, non-transitive is actually added by the source. So when the edge data center generate those metrics and attach them to the services, it add this non-transitive path attribute so that the node receiving it will not propagate across the border. In addition, the route reflector can also add this non-advertise well-known community so that receiving node will not propagate across to the unintended audience, unintended neighbor. And to on top of that, to prevent any possibility of going cross border, the message itself, the update itself can also include the intended ASes, so that it will definitely not cross to the ASes not listed here. So those are the three methods which have been indicated in the IDR document. 

So, in terms of applicability to apply those metadata and the methods to the metrics specified by CATS, in the BGP metadata path attribute, there are currently those sub-TLVs has been specified. One is the first one is the Site Preference Index. This is mapping into CATS L2 policy metric. And second one is the Physical Availability Index. This is exactly mapped to the shared resource which has been described in one of the CATS document. So the physical availability index is really to show that you may have a fiber cut to a particular pod or particular shelf, and all the instances, doesn't matter is IPv4, IPv6 or VPN, all the instances are impacted. Instead of having so many individual withdraw message to the remote end and saying all those different prefixes need to withdraw, this method allow just one single message to be sent to the ingress nodes, so they can taking off just consider all the routes associated with this particular index are treated as withdraw. So that's the purpose of this site physical availability index sub-TLVs for. Then next: service delay prediction, which is can be mapped directly to the service processing delay. And then there's a service-oriented capability, which is mapped into the CATS computing resource capability. And there's also raw measurement, which is mapped into the traffic load utilization, which is like CATS L0 or L1 type of metric. 

Okay. So in the IDR document we have extended description on how those metadata are used in path selection. So the path selection is really deployment specific attribute selection. It influence the BGP decision process. The whole point of passing those attributes to the ingress node is for the purpose of ingress node to be able to select the path not only based on the network condition but also based on the service environment where destination is. And also there is handling of degraded metric, it's a policy. And there's a description on that and also there's a way to fallback when none of the metadata routes can be selected, how do we fallback. 

Okay. So in the path selection in the IDR document, we describe three different scenarios. This is really each of the scenario is by configuration. So scenario number one: metadata plays a higher priority than the traditional BGP. So that means when they make choose the path, they use metadata as the first choice. If it's equal, then go to the other BGP criteria. And second one is metadata value is same level as traditional BGP metric. And in the document it describe how the selection process basically goes through traditional BGP decision steps, right, from local preference through the path length to the origin and then go to the metadata. Scenario three is traditional BGP metric has higher priority. So basically metadata is used as a tiebreaker if two paths have equal level. So that's in the IDR document. 

Of course there are gaps from the metadata path attribute defined by IDR to be applied directly to CATS. So there's one thing about this service instance differentiation. In the IDR document we don't have the service instance indicated. So in order for the CATS metric to work properly, probably another instance ID need to be included. Second is when you have large amount of raw data in CATS terminologies L0 type metric, you need some kind of hierarchical types to make it scale to be processed properly. So that has to be introduced. CATS also define this matrix lifetime. In IDR document we don't have this TTL or time-to-valid-until this kind of attributes. So in order to support CATS, this has to be introduced. And also for the shared resource, there's a scope identifier. So this allow the site physical available index to be categorized by a scope identifier. There's also more need to support more dynamic metric classes. In the CATS they define metric classes which can change frequently. With IDR BGP update mechanism probably is not really suitable for that. 

So, that's the end. If anybody have questions. 

**Peng Liu:** Guanmin, please. 

**Guanmin Zhang:** Thank you for your presentation. And I have a question. I'm Guanmin from Huawei Technologies. Since 5G radio conditions and UE mobility states can change very rapidly, whereas the CATS control loop involving metric collection path computation typically operates on a slower time scale, what mechanisms do you suggest to handle this timing mismatch? 

**Linda Dunbar:** Oh, I don't have any suggestion at this point. Here I'm only present what IDR has done and what BGP can do for this dynamic metric. Maybe there will be some other consideration and there's a presentation earlier before me talking about all those control plane, maybe something has to be evaluated and then see if that applicable for this. 

**Guanmin Zhang:** Okay, thank you. 

**Linda Dunbar:** Well, thank you very much. 

**Peng Liu:** There are some discussion in the chat box from Jeffray. So the authors of the solution draft with BGP related or just the authors of the applicability draft please see some the discussion in the chat box. We may find out the rate change of the computing resource. So we can discuss whether BGP is a suitable protocol to realize CATS system. 

Okay, thank you. Next: [5.1. Framework and Applicability of CATS in Optical Transport Networks (OTN)](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-51-framework-and-applicability-of-cats-in-optical-transport-networks-otn-00). 

**Zhen Han:** Okay, good afternoon everyone. I'm presenting our work on the CATS for OTN. 

Today multisite compute services have become common, but the traditional traffic dispatching typically based on the nearest site selection often falls short. More importantly, for the highly demanding workloads such as model training and inference, the pure packet-based steering may not meet the stringent requirements for latency, jitter and determinism. Our work extends the CATS thinking into optical transport domains, bringing the deterministic transport capabilities into discussion to address these challenges. 

We have identified some use cases which require both the compute awareness and network awareness simultaneously. These include the model training and inference jobs, which require the... which impose the strict synchronization requirements on the distributed GPU clusters. And the high performance computing workloads and telehealth services are examples where the high bandwidth is very important. All these use cases share a common requirement: they need deterministic and high bandwidth transport with guaranteed performance. 

We take the agreed CATS framework and functional components and then extend them for OTN. The key idea is to use OTN to complement packet-based CATS by combining compute metrics with optical layer metrics. It enables us to establish end-to-end hard isolation for demanding service flows and the traffic can be mapped into optical containers such as ODUk and fgOTN. The path selector can consider several factors, such as deterministic path latency, wavelength continuity constraints, optical link performance and compute resource state. 

Let me walk through the framework and workflow. The key building blocks have been defined in the existing CATS framework and the workflow works as follows. First, a service is identified by its CS-ID, and then metrics from both compute side and network side are distributed to decision points. And the CPS will choose the best instance and the optimal path. And the traffic will be classified in the ingress and mapped into optical transport containers. Finally, the traffic is delivered to the selected service instance. 

We ask the CATS working group for some deeper thinking. For the metrics: on the compute side, we need to consider the service status, GPU or compute load, memory availability. And for the optical side, we need to look at the latency, wavelength, time slot availability and optical link quality. And of course there are some operational questions relevant to our work. 

And we request working group members to review and to... to review and comment. And we will integrate the all the feedback. Thank you. Welcome your questions and comments. 

**Adrian Farrel:** So I'm going to fill the gap. I think it's interesting. We need to be careful how we phrase this. This is not the applicability of CATS to OTN, it's the applicability of OTN to CATS. So it's how we might build a CATS system sitting on top of an OTN system. And I think that's, you know, an interesting thing that probably most people in the room hadn't been thinking about because they were coming at this from a sort of packet perspective. So we need to get some more eyes on this, get the people in CCAMP in particular, but probably also TEAS to be thinking about this. So it's a good start. 

**Zhen Han:** Ah, thank you. Yes, I agree. 

**Peng Liu:** Okay, thank you. No one in the queue, so we move to next. Next: [5.2. UONACO](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-52-uonaco-00). 

**Zhen Han:** Hello everyone. My name is Zhen Han from BUPT. Today, I will present the updates to UONACO. Thanks to the great feedback from Daniele, Steven and Adrian. We clarified our scope and resource models. 

At the last meeting, Daniele asked why we focus on the optical networks. The answer is distributed AI workloads require hard isolation, zero jitter and deterministic latency. Only optic layers like OTN can guarantee this. That's why we believe this work belongs in the CCAMP. 

So we propose UONACO. It enables bidirectional awareness, resource abstraction and joint orchestration between optical transport networks and AI computing infrastructure. 

We identified three main use cases, where remote AI access is typical user-to-compute scenario. Distributed AI training and distributed AI inference are massive compute-to-compute scenario. 

Currently, the compute schedulers and optical controllers are isolated. For example, a computer power scheduler assigns a distributed job to two data centers with free GPUs, but it's completely blind to congested optical link between them. So this leads to a massive compute efficiency loss. 

To solve these questions, we need joint orchestration. This brings us to three requirements: first, integrated control and management architecture; second, unified abstraction and evaluation framework; following the feedback from Steven, we have integrated the storage along with compute and optical states. Third, scheduling algorithm for joint orchestration. These three requirements leads to a question raised by Adrian: how is it different from CATS? 

The table shows clear boundary: CATS is about steering traffic over existing paths. It's triggered when packets arrive at the ingress. UONACO is a life-cycle orchestrator. Before the first bit is ever sent, UONACO evaluates service intent, locks required AI computing resource and provisions a new optical circuits. 

In CATS for OTN, optical channels are also pre-provisioned. For massive AI workloads, only steering traffic over existing shared pipes is not enough. We need control the optical layer to provision a new physical or logical links on demand. 

Before the architecture, look at the service model. The customers specify their AI service intent, like training a large model, then the service provider must translation this intents and orchestrate across two distinct domains: the network provider and the compute power provider. In the real world, they are usually different entities or at least different departments. So we must standardize the control interface to bridge them. 

UONACO architecture builds perfectly on the top of ACTN. The transport network controller is essentially as an ACTN-PNC, and the UTI interface is based on the ACTN-MPI. But here is a critical difference: the unified compute optical orchestrator act as an enhanced ACTN-MDSC. We introduce a new domain, the compute power scheduler, connected via the new UCI interface. So instead of routing traffic, the UCOO can take the customer's intents and orchestrate across two domains, include both compute nodes and the ACTN optical networks at the same time. 

Next steps: we will refine the architecture, clarify the relationship with ACTN and details the use cases. We also plan to update the draft name to better match UONACO's scope. We also will design YANG data model for the interface. Welcome more reviews and hope to seek WG adoption. Thank you very much. 

**Peng Liu:** Thank you. No one in the queue, but I have one question. On this slides, you list the relationship with CATS, but as it shows, I didn't see the similarity between them. So if you want promote this, you may need to make a clear relationship between it. 

**Adrian Farrel:** Sorry, this is just to wake up Huaimo. I'm interested, you're almost as old as I am, whether this reminds you of Layer 1 VPN. Yeah, go ahead. 

**Huaimo Chen:** Yes, this is a kind of Layer 1 VPN connection serving for I believe somehow like CATS service. 

**Adrian Farrel:** Okay, thank you. So my advice to you is go and see if you can find the RFCs about Layer 1 VPN. I'll drop a note to the mailing list. But Layer 1 VPN was about providing optical trails between edge points and discovering the edge points. So it may be helpful. 

**Huaimo Chen:** Oh, thank you. Yes, I agree. 

**Peng Liu:** Okay, thank you. No one in the queue, so we move to next: [6.1. IDN and ODSI](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-61-idn-and-odsi-00). 

**Hanlin Wang:** Good afternoon everybody. My name is Hanlin Wang from PCL. Today, I'm going to introduce two IETF drafts that we wrote recently: one is about IDN and the second one is about ODSI. Due to time limits, I will just give a short introduction of these two drafts, and we welcome the feedback from the CATS working group. 

Unlike previous drafts in this working group, these two drafts are more about the LLM or model inference aspects. Our first draft is called IDN. It is an Intelligence Delivery Network. Intelligence Delivery Network is a framework for deploying the deep learning models across the heterogeneous cloud and edge nodes. This IDN is inspired by the Content Delivery Network. In this IDN, we deploy the different models across the different layers of the computing nodes including the edge device, the networking device and the cloud computing resources. And the components of this framework is mainly composed of six components. 

The first one is about identification. It solves the problem that how the capability of a model is defined, for example what tasks are supported, what is the accuracy, what is the performance of the model. And the second component is about access. It solves the problem that how a new device can join these computing resources pool to provide their own computing power. And the third one is about deployment. It solves a problem about how the model can be deployed across these heterogeneous compute nodes. And the fourth component is about routing. It solves the problem that given a user request, how the request can be routed to the best devices just like in the CDNs. And the next is about cache. It use different mechanisms to improve the performance of the system and to improve the user experience including like caches of the model intermediates and KV cache. And the last one is about security. We are also aiming to improve the privacy and data security of the system. And we would like to hear the feedback from the community about the framework design and also about the details. 

And the second framework is about ODSI. It is an open, decentralized and scalable framework for large language model inference. Actually, the core idea is inspired by the blockchain. It's like that each computing node can join this computing resources and to provide their power for perform part of the model inference. And in this framework, we design the main three components. 

The first one is about a transport protocol that it device how... what are the data being transferred between different nodes of this distributed or decentralized computing nodes. And the second one is about the coordination. It solves the problem about how the request can be performed by using the decentralized computing power of different nodes. And the third one is about the economics design, because each computing node is not altruistic, so we designed a mechanism that just like in the blockchain to encourage each computing node to provide their computing power for the resources. So that's all about these simple introduction of the two drafts. We would like to hear any feedback from the community. Thanks. 

**Peng Liu:** Okay, thank you. No one in the queue. Okay, Chuanyang. 

**Chuanyang:** Okay, thank you very much and I'm Chuanyang Miao from ZTE Corporation. And I'm very interested in the IDN solutions because I'm familiar with the CDN as you said this is a very similar to the CDN mechanisms. But why other why I want to know is the CDN is has a core function is load balance would be implemented in the application layer which we call the GSLB... GSLB, yes, maybe that. And also we can use the CATS for the another type of the load balance, but implement in the network layer. We using CATS to select the right edge node, service node. And for the IDN, and we still have this problems: if we want to do the load balance to traffic the user request to the right large model in the edge site, which kind of the mechanism for load balance will be better? For the application layers implementation or we use CATS here? Because CATS needs to consider the compute resource and network resource but application layers only concerning the content or the the models for the nodes. So which kind of the mechanism will be better? Thank you. 

**Hanlin Wang:** Sorry, so your question is about the load balancing part of this framework? Yes. Load balancing can be the different scenarios used in CDN or CATS because CATS use the traffic steering by consider the computing source and network source. That's will be implemented in the in the network side, but CDN consider the content. What's the content will locate into distributed the nodes? But here you said you need to deploy the large model which is maybe computer sensitive in the edge node. So you may think the CATS will be good for the IDN. But is there any other possibility to just use application layers load balancing in the IDN? Or you are thinking the CATS is the more appropriate the solutions for implement load balancing in the IDN? 

Okay, thanks thanks for your question. So actually the load balancing in this part, our idea of design is to follow a similar pattern in the CDN. As we know that in CDNs, the content can be distributed to each computing nodes freely and since the contents can be replicated and very easy to access and stored in the in the computing node. But in this our framework of IDN, the model especially for the large language models, they can't be... they can't be easily decomposing to the small objects or the small parts that can be deployed on each device. So in this framework, our one of the most important design is actually the first component about how to decompose the large language model into different parts, for example by decomposing it into different phases, different layers, etc. 

**Peng Liu:** Okay, sorry we don't have so much time. So please just respond this question in the mailing list, okay? 

**Hanlin Wang:** Okay, thank you. We can discuss about that later. 

**Peng Liu:** Okay, thank you. We need to move to the last one: [6.2. In-Network Scheduling & Semantic Contract for AI Workloads (Intellinode)](https://datatracker.ietf.org/meeting/125/materials/slides-125-cats-62-in-network-scheduling-semantic-contract-for-ai-workloads-intellinode-00). 

**Speaker 4:** Okay, hello everyone. So this is my first attending an IETF meeting so I don't... I'm not very familiar with the process so my slide is relatively simple. Okay, next I will share some immature ideas about the potential capabilities that future network nodes might need to have for AI traffic. 

For the first slide, okay. So why is today's network not good enough for AI traffic? First, the mechanism are too coarse. QoS can separate video from web traffic, but in an AI job, it's treats a critical gradient synchronize the same as less urgent parameter fetch. So the network is blind to this semantics. Second, the network doesn't understand the meaning of traffic. It can't tell a packet is part of an activation, a gradient or a KV cache. These have very different meaning, timing and importance, but the network handles them all the same. Third, look at for example as the ECN is just a congestion signal. It says slow down, but it can't make a scheduling decision. It doesn't know which flow to prioritize, which one can be buffered or just want to tolerate lower precision instead of just slowing down. And in a cross-domain environment, this problem are much more worse. The RTT is longer and the bandwidth is expensive, sending the wrong traffic at the wrong time here is very costly. The old one-size-fits-all approach breaks down completely for AI. 

And the for next slide, what we propose? Our proposal is a simple a semantic contract between the app and the network. Here's the deal: the application provides a little bit of key information about the traffic, just like the basics like what a type of data is and how urgent it is, which compute resource it prefers, and it can tolerate like a bit of delay or lower position. The network then use this info as input for its policies. It doesn't treat every packet equally anymore. It can now tell flows apart and apply the right action: high priority for urgent gradients, buffering for large parameters or small tearing towards a specific type of processor like a GPU or FPGA. So this creates a clear map from semantic information like traffic class, urgency to network policies like priority queuing, shaping or steering. The network finally understands the context. 

Okay what a IntelliNode is and how it use the semantics? Okay, the contract provides the meaning, but how does the network act on it? This is where IntelliNode comes in. Think of IntelliNode as the network's brain for real-time scheduling. It's building inside the network so it can see live conditions, queue depths, link usage, what the compute node are doing and it gets the semantic info from the contract. It combines these two things: what like semantic and the how is the network right on... right now state. Then it makes microsecond-level decisions. Based on this, it can perform real-time actions right inside the data path. It can choose the best path, split a large tensor, buffer lower priority data or steer traffic to a specific server. So in short, the semantic contract tells the network what the traffic means, and IntelliNode is a framework that lets the network decide and do the right things with that knowledge. It can make the network active and service-aware. 

And what we plan to do next? Our plan focus on turning this idea to practice. First, we need to refine the semantic model. We will work with frame developers to nail down the smallest, most useful set of information that might be shared. Second, we must define how to carry this info in packets. We are looking at extensions, headers or new TLVs, especially for protocols like RoCEv2 so switches can read it at line rate. Third, we have to clarify the decision boundaries: what should the endpoints handle versus what's better decision inside the network? We need clear roles. And finally, we will build prototypes and test them. We need real data to provide that this approach actually improves the performance resource use and efficiency for AI workloads. Our goal is clear: to move from just talking about traffic semantic to actually enabling practical in-network handling for AI service. Okay that's all my share. Thank you. 

**Peng Liu:** Okay, thank you. No one in the queue. So, my suggestion is find out the suitable place to move this draft or just find out what's the relationship between your draft and the CATS working group. Okay, thank you. 

**Adrian Farrel:** Good, so that brings us pretty much to the end. Thank you for everybody for sticking exactly to your times. As we said earlier, our next kind of step is to work out what documents the working group should be picking up and moving forward, what topics. So if you have opinions on that, well technically there's a minute and a half you could say them now. Probably better to find the chairs and let them know your opinion and maybe start pushing ideas on the mailing list. Don't all jump in with "me me me" because we do have a charter, and we have to stick inside that charter, and we do need to take our work step-by-step carefully. Any last comments? Well done for using the tool and coming to the queue. Come to the queue. 

**Kyrillidi:** I'm sorry, I can't log in right now for some reason. Kyrillidi Kompella. Um, was the last presentation in charter? 

**Adrian Farrel:** I don't think it was in charter for adopting as work or anything like that. No, but the topic in charter in terms of hearing the discussion to find out what people are doing and thinking about around CATS, that's why it was on the agenda in the "if there's time to talk about it" section. But I... it doesn't feel to me like this is something that's in the current charter. 

**Kyrillidi:** Okay, thank you. 

**Adrian Farrel:** All right, then that's us done. We will see you in the corridors, on email and in Vienna. 

**Peng Liu:** Okay, thank you everyone. We're going to close our meeting. Thank you.