151

Good afternoon, everyone.Thanks.So in this talk, Patrick and I, we are going to talk about next generation MCTP work we are doing at DMTF.Quick intro.I'm Hamel.I'm a distinguished engineer architect at Broadcom.I'm also DMTF VP of technology and cochair of PMCI work group and also co-lead of hardware management project here.Unfortunately, you all, one of our presenters, couldn't be here due to the situation in Israel.So Patrick, go ahead and introduce yourself.

Thanks, Hamel.Patrick  Caporale, distinguished engineer at Lenovo and the DMTF.I'm vice president of marketing and also PMCI co-chair with Hamel.

Okay.So this is work in progress in DMTF, our standard disclaimer here, subject to change.

What I'll do is I'll give you some history and motivation before we jump into MCTP 2.0.And it's really good to see that option of MCTP 2.0.As we start with MCTP 2.0, after I introduce some of the features, I'll hand it to Patrick and then he will go over the rest of the stuff.So just stepping back to give you guys an idea about how MCTP, the whole management component transport protocol, came into existence.If I were to take it back all the way, this was in 2005, me, Tom Slate and others sitting on the paper trying to figure out what's the simplest protocol we can come up with for management communication.So that's when it started.It's been in industry for quite some time.Believe it or not, it was first adopted on desktops and mobile platforms, and then it was adopted by several platforms.So the needs were different.But over the years, it has evolved but still maintained through addition of features.MCTP adoption has been constantly increasing.And then OCP platforms, as you can see the talks, you see here talk about the PMs.MCTP is one of the transport I'll get into the PMCI, which is a platform management component in a communication stack, which basically includes MCTP, PLDM, SPDM, all of those.So those are all becoming really core of communication stack within the platform management subsystem.

In this talk, we'll specifically focus on what we are doing with the MCTP 2.0.Before that, just to give you a picture of this is how the stack, MCTP stack has came into existence.As it started smaller, and we added more layers, more bindings.Basically you can think about it at this point is equivalent of this, you can think about TCP/IP for internet, is same what you are seeing as a PMCI stack here.In the middle, you have transport, which is MCTP, and also we have another transport, RMII-based transport.Now each MCTP is physical medium independent transport.So we have number of binding layers in between, which binds it to underlying physical layer, which could be SMBus, which is one of the slow serial bus interface.It could be also USB, it could be PCIe, VDM.As you can see, there are a number of bindings we have defined, which also covers the host interface.Then as you move up to MCTP, MCTP has this built-in knowledge of it can carry multiple message type.Very similar to within TCP/IP, you can run higher level application protocol.That's where some of the session level protocol come into picture, whether it's a PLDM, PLDMFs.As you can see in here, there are different types within PLDM, which allow you to do monitoring and control function, firmware update, SMBIOS table transfer, BIOS configuration and control, and Redfish device extension.The list keeps going on, but it becomes basically all of these are messaging protocol.They take specific management domain and PLDM data model and command sets are defined for that.So that's one of the key protocol that runs on top of MCTP.And then SPDM, which is for device authentication, firmware measurement and attestation, which is also having its own binding or MCTP.We have also secured messages, which are used for encryption.So that also has its own binding or MCTP.So as you can see, all of those, and then we have Alliance partner defining their own control communication protocol on top of MCTP, like NVMeMI, where management commands over NVMe management interface can basically use MCTP as a transport.So this is the stack view of how the PMCI protocol stack has evolved over the years.What you see also on the side, which is more or less for the NIC NCSI, which is the sideband communication protocol, which includes both control and pass-through communication.And that can be done over RMII-based transport as well as MCTP.So for us, MCTP 1.0 and 1.x spec has been the core on which we have built all of those.

So the question is, things are working well.MCTP 1.0 or 1.x has been adopted so well.Why 2.0?These specs were published in 2009, right?And as I said, you pretty much open any platform, this is implemented.Whether it's a server, there are other platforms where MCTP has been used even in like small IoT kind of environments.So why do we need 2.0?And about maybe what, Patrick, a couple of years ago, we started thinking about, let's step back and see these new use cases that are coming in.So we started going through some of the requirements from our alliance partners, new use cases, and then we started really nailing down, what are the gaps?So one of the things we started seeing, newer platforms are going to have more and more devices within one platform.What that means is you will have so many endpoints within platform that MCTP 1.x won't be able to support.So that was one of the area where we started seeing.We also saw people asking for, we want to do file level IO transfer and really bulk transfer.We want to support really high speed transfer, which will require some kind of reliability in the transport protocol.So far to keep MCTP 1.x simple, a lot of reliability layer was moved up in the layer above it, whether it's a PLDM or SPDM.So then that kind of started triggering saying maybe some basic reliability semantics built into transport will help all these upper layer protocols.And we also saw that, as you can see, there are a number of bindings and number of medium we support.They have constantly grown and grown.So in general, we need to have more flexibility in the protocol so that down the road we can have more higher level protocols that can be supported by MCTP.We can define more physical binding.So that's also another area where we started thinking we need to do something about it.And then with SPDM secure message, when people started looking into it, naturally one thought came to mind is why not provide that security at the transport layer?And today, if you go to TCP/IP, we have security at the IP layer, we have the TLS, and then you have higher level application level security protocols.So we started thinking about we should have some basic encryption capability also built into the transport layer.So putting all this together, this is where we started thinking that now we are at a point almost 15 plus years of adoption of this protocol, we should start thinking about what's the next generation of that.And still we are very careful about making sure that MCTP 1.x specs and its compatibility and new features can be added.And that's how MCTP 2.0 discussion has gone in DMTF, and that's how we have started working on MCTP 2.0.And now I think next few slides you will see preview of what we are working on.We have released work in progress, so you can see some of the aspects we talk about here.They're publicly, you can review it, provide us feedback.Our expectation is by next year we should have this as published as a standard, and then it will go through its own curve, and depending on use cases, people will start implementing 2.0.And we also allow implementations to be both 1.x and 2.0 compliance.Patrick will cover that later in the slides.

So with that, let us start getting into the specific features, what we are considering for MCTP 2.0.First thing, as I said, today MCTP 1.x, it has logical addressing and point ID built into it, which allows it to have physical medium independence.And then just like you have ARP, it has similar address resolution protocol that you can use for medium, endpoint ID to physical address bus assignment or resolution.But it is limited to 255 endpoint, and that's just based on the protocol field.Now you can say, "Ah, today server 255 devices or endpoints are sufficient." It may be true today, but we are already seeing where people are having more devices.You are seeing more disaggregation kind of architecture where you might have every single instance of memory requiring its own endpoint ID.And also devices are having now multiple endpoint IDs because they are having multiple functions within that, and you may want to reach it through different medium also.So putting all that together, this is one area where in 2.0 we are going to really expand that EID space and go to 64K endpoint ID, which will give us pretty large address space.So that's the first.

The second thing is today MCTP, we have messaging layer and then we have packetization.And packetization is very simple.It basically allows you to have two bits of where you can figure out the packet being sick, but then it wraps over.So you can detect some basic packet loss.It doesn't have any retransmission or reliability built into MCTP.So this is where with 2.0 what we are thinking about is making that whole messaging layer more robust.And while doing that, what we are going to do is our current thought is we are going to have two layers.The upper layer message will get broken down into multiple segments and each segment will be further broken down into one or more packets.And each packet will map in onto the underlying physical medium packet format.So what this gives us is we can add reliability at the segment level.This is where we'll get into some of the reliability protocol flow control and retransmission, what we are adding.And while also we can maintain somewhat backward compatibility, if you don't want any reliability and keep it simple, then we can have this best effort transport mode where there is no transport level reliability.So we'll support both modes.When you have reliable transfer mode, then you can have segment level ACK, NACK and retransmission.So this will make the MCTP allows us to support really large message size that you can further segment it and which can get packetized as well as add some more reliability.

With that, let me hand it to Patrick to cover flow control and the rest of the features.

Yeah, we'll go into a couple more of these MCTP 2.0 features, but we'll start with flow control as Hemal just described, the new segmentation and packetization in MCTP 2.0 is different.And by enabling that, we'll be able to do an ACK, NACK protocol to support reliable transfers.As you can see as an example, as each segment is communicated from one end point to the other, if there is an issue, a dropped packet or a lost packet on one of the -- inside one of the segments, you can NACK that segment.That would retransmit that segment starting at the boundary at the beginning of the segment and be able to restart just there.So as we're seeing with the growth of MCTP, not just in the size of the networks, but also the amount of upper layer messaging and application data that's being sent over that, those messages are getting very large.So having that more granular ability to ACK and NACK at a segment level allows for those larger transmissions to flow better, you know, and more reliable over MCTP, and that's going to be a key addition to MCTP 2.0.Now in addition to the ACK/NACK, there will also be initiated aborts.So either the transmitter or receiver, because again, these segments could be many to make up an entire upper layer message, you'll have the ability where if something just has to be ceased and no further segments should be transmitted or received, you'll also have the ability to have an abort capability initiator from either side.So that's also being added into the flow control capability.Sender-based race limiting, that's actually part of MCTP 1.x today.So there is the ability to rate limit your traffic where you can advertise the amount of rate limiting that an endpoint can provide.A receiver can then ask the sender to rate limit its traffic.Again, there are some cases where these buses that MCTP can operate on are very high bandwidth and could completely send as much traffic as possible down to an endpoint where MCTP may want to rate limit that traffic.So we would plan to continue to keep that capability into MCTP 2.0 in the future.So that's one clear example of the flow control capability.

In terms of discovery, both the path and transmission unit discovery, one of the things on the why MCTP 2.0 page talked about that negotiation of transmission unit.Today there's a fixed baseline transmission unit in MCTP transport that is something that can be modified at a message type boundary, but we'll build that into the actual transport capability to negotiate that baseline transmission unit in case you have two endpoints that can just talk larger sizes and can make those packets and then ultimately segments larger in terms of expediting communication.The MCTP discovery, a lot of this will generally stay the same.That is the goal.You'll see in the next couple of charts we need to coexist between 1.0 and 2.0 environments.So the bus enumeration, the address assignment, the capabilities discovery, there will be some new capabilities to discover.A lot of these new features will be part of the discovery capability for 2.0.Endpoint ID assignment, simply larger number of endpoints.And the distribution and even routing, MCTP routing and the bridge functionality will continue into 2.0.That will still have the benefit of the bus owner and topmost bus owner, so some of those concepts are continuing forward into 2.0.But where needed, the discovery elements will be enhanced to support these 2.0 feature sets.

So of course with the introduction of SPDM and SPDM capabilities with our message type 6 for running secured messages over MCTP, looking at 2.0, security considerations are absolutely critical.There is an intent and a goal to have the optional message encryption integrity and encryption capability built into the transport.Now this is being done completely with the cooperation and consultation with the SPDM group.So we are working with them to get that input as to how to look at the MCTP security that we have already today with the 1.0 and the SPDM functionality and the encapsulation of MCTP messages using secured messages from SPDM.But can that be built into the MCTP 2.0 transport layer for MCTP messages?That is ongoing.That is certainly something that is a key item.And that would support secured messages directly at the MCTP 2.0 layer.That would allow those secured messages to flow through MCTP bridges.The end-to-end negotiation, again, secured messages are secured fully end-to-end.Once again, we would look to have SPDM provide that security coverage for any traffic that they would have through a secured session of MCTP 2.0.

So coexistence of MCTP 2.0 with existing 1.0 devices is of utmost importance.As Samuel mentioned, there is approximately 15 years' worth of now of the spec being out there.A significant number of devices support MCTP and, of course, the upper layer messages that ride on top of it.But we need to make sure that as 2.0 is standardized and becomes available, that as devices or business owners start supporting that capability, the coexistence is fully enabled and permissible.That starts with the EIDs.So we'll have some EIDs that have an 8-bit EID and some have a 16-bit EID.So that's going to be important to make sure that both can operate on the same physical bus and as well as those EIDs could be on the same MCTP network.So regardless of where those endpoints are across the MCTP topology, whether they're 1.x or 2.0 capable, there is a coexistence possible.Now a bridge, certainly if a bridge were to support MCTP 2.0 traffic flows, it would need to be 2.0 compliant.But a 2.0 compliant bridge will also need to support 1.0 devices or 2.0 devices behind it.And of course, any device, even a 2.0 device that needs to speak to a 1.x, that needs to be supported in the effort that is being done here for MCTP 2.0.So all of that is not just a goal, but it's a baseline requirement that's being driven here for this update of the spec.Clearly that's going to be critical just in terms of the ecosystem that continues to grow around MCTP.

A couple of other things we'll add into the transport layer.Today error and state reporting, they may be provided at the upper layer where you might get some higher level protocol information as to errors or states.But at the transport layer, as we're seeing again the larger increase of both message size and we're now segmenting down into those segments and packetization in MCTP 2.0, we'll have some additional capability built at transport layer to identify some statistics of encounters such as drop packets, some state information if you're in the pause state.That's going to be enhancing the robustness of MCTP 2.0.That's where the endpoints can learn from each other how the overall communication has been flowing.And where needed, could even take an opportunity to adjust things like baseline transmission unit and things.So providing counters is just going to be beneficial at the transport layer to endpoints.

Quickly looking at where this resides today.Again there's a work in progress out there.And we continue to take feedback which we'll talk about in a moment.The packet fields, so again you see that there will be new fields in the MCTP transport header.So it will start really with the same two bytes at the beginning there where the header version is looking to just go to header 2.So that's obviously going to indicate that this is an MCTP 2.0 packet.And then you will see that the main change of course is the destination and the source EIDs are going in size.That's just back to the address expansion and that has to be introduced into the header.And then as the packet sequence number and the segment ID is displayed here, that's how we look to do the segmentation of MCTP 2.0.This is a work in progress.So these are the proposed fields.But this will be one of the outcomes of the 2.0 specification which will be that clear definition.With the MCTP transport header, you get into the actual packet payload and that may include some other segment headers and then ultimately the upper layer message or application data if it has a header or other material that needs to be there at the beginning of its message.

These are the planned features.I'm not going to go through each one of these.It's here for reference.But there are a set of -- essentially these are the features that are being driven into 2.0.There is a reliable transfer mode and a best effort transfer mode.And there are some optional or mandatory differences between those two.Again as explained to Hemal in the beginning, reliable transport, that's where you'll have the ACK and NACK and the ability to retransmit at the segment level.Best effort, really similar to what we have today which is at the transport layer, it's just sent to the other side.If there's drop messenger things, the upper layer messages typically will come in and do retransmits.

And with that, it brings us to the call to action.So first and foremost, contribute to the MCTP 2.0 definition, a couple of methods can be done directly through the PMCI working group of DMTF.It can also, you know, feedback through the DMTF portal, link available there that would flow into Hemel and be brought into the group.Of course, submit proposals for specification considerations for OCP platforms.That's another critical area.We see the continued adoption of MCTP and upper layer messages here within OCP.And then for this content and more detail, there is the MCTP 2.0 overview WIP directly at that link as well.

And I think we encourage you guys to -- this is a good time to give us feedback on the work in progress.And as I said, the plan is to have this go to standard next year.

Are you going to have enough, I guess segments is the question, in flight to need more than just the ability to NACK the last segment?

Good question, David.It depends on the payload, but for some of the file I/O we are talking about, we might have enough segments where we might want to do a segment level NACK.

Bingo.Well, in essence, what I'm suggesting is that if you expect to have a good number of segments in flight, you might want to make provisions now for SACK, selective acknowledgement, which says, okay, I want this one, which might not be the most recent one that showed up.

Yeah.Yes, that's a great point.