Storage Developer Conference - #131: Redfish Ecosystem for Storage

Episode Date: August 4, 2020

Hello, everybody. Mark Carlson here, SNEA Technical Council Co-Chair. Welcome to the SDC Podcast. Every week, the SDC Podcast presents important technical topics to the storage developer community. Each episode is hand-selected by the SNEA Technical Council from the presentations at our annual Storage Developer Conference. The link to the slides is available in the show notes at snea.org slash podcasts. You are listening to STC Podcast, episode 131. My name is Jeff Hillen. I'm president of DMTF. I'm one of the people that started Redfish a long time ago. I've been working on it for nine years. It's been out in the public for five, and the standard's been released for four.

So it's funny how these things happen. How many people have seen or heard about Redfish before? Because there's a lot of overhead stuff in here. Is there anybody who hasn't? Yes, yes, you don't count. Because I don't want to dwell on a whole lot of it, and I could do a little bit of the folklore of where it came from and all that kind of stuff instead, which I find far more interesting.

After you're in this business a while, it's probably more interesting what it takes to get something like this out the door and adopted by the industry than it is just to do the design work. But a lot of what's in the contents for these slides is all the design work. Disclaimer, some of this stuff is changing. I go off the rails sometimes. what we were really trying to do right up front was create an architecture for all of hybrid IT in an interoperable way, but start with something that could pay for it.

And redo something that's working perfectly, said no manager ever. So how do you go in and re-architect something that's kind of working? And in our case for servers, it was IPMI. And I say IPMI was kind of working because it was breaking on the security level. There wasn't really any interoperability. A customer would come to you and say, well, Dell does it this way, and you find out it's an OEM extension, and they're using I2C addresses on the wire, and you have to know where these devices are. Or in the Moonshot case, they were doing that too.

It was really, really ugly. So we really wanted to take where developers were going and try and intercept it. And if you've seen the previous versions of these slides, it shows a whole bunch about JSON becoming a thing. And JSON doesn't really matter. It could have been XML encoding. It could have been anything else because a lot of these libraries will encode it and decode it.

It doesn't matter. But what leveraging JSON does for you is makes you get your variables in order so the developer can actually use them. Because what you think are properties inside of a schema are actually variables in somebody's code. And so if you're thinking correctly, you're thinking like a programmer, you're thinking like your client when you start developing these data structures. And so you don't do something like fan with a thing under it called fan temp, because their variable is going to be fan dot temp.

You know, so that was kind of one of the design tenets. The other design tenet that's really not up here, that kind of all of these say, is we're focusing on data objects and separating out the protocol. It doesn't matter what the protocol is. It could be HTTP was the cool thing. And so that's what we glommed on to because all the tool sets out there had a way of getting data to and from HTTP. And with REST, you basically had CRUD, which is unless you're doing request reply semantics, gives you your create, read, update, and delete operations.

So if you kind of design something around CRUD, separate the protocol from the data model, and concentrate on the data objects, the variable that is going to be used by the person doing the code, you're preserving the up being interoperable and interchangeable no matter what system it's on, no matter what transport it's on, no matter what encoding it's on. And those architectural tenants that really aren't on this side, it's kind of between the lines on this slide, is what enabled us to do Swordfish and especially Swordfish 1.1, what's enabling us to apply this across the data center and other topologies because we came up with certain architectural constraints

and create enough common building blocks where folks could go off and do things in their own sandbox and still leverage what we did. And so it isn't a complete throwaway of the code. You want to do something else. Everybody's building something out of an industry standard server, whether it's a switch solution or a storage solution or IoT or whatever. Those constructs all have the same fundamental building blocks when it comes to needs for power and cooling and temperature sensors

and all the stuff people forget about. And then there's kind of another thing going on in the DMTF which enables disaggregation so that you really are enabling the industry to build things out of pieces and components in a way where, you know, what's the last thing people think about besides QA? It's management. And they kind of bolt on the management once they get a product idea. So they're all worried about, you know, speeds and feeds and codes and how long it's going to take this.

And the manageability ends up kind of being last. So if you create not only the data objects and preserve that investment in the code that your client end is writing and instead can also plumb this ecosystem, again, with any transport you want over any media you want you've really you know kind of when i started this journey nine years ago was enable an industry to build anything we want out of fundamentally commercially off the shelf building blocks and that's kind of what that slide meant to say. So what is Redfish really?

Well, it started out as 1.0 was meet comp with IPMI. We had a whole bunch of other stuff in there. There was an RDMA, like the RDMA consortium before it went to the IETF, we used that model with the Redfish consortium, put some of us together, kind of agreed what it looked like, and, of course, when it came out of the DMTF, it looked completely different because OData happened to it. But it kept those fundamental concepts which was HTTPS and JSON format and then we added on the OData version 4. Schema backed but human readable. Nobody reads manuals. If you

can't read that data object coming across the wire for 90% of your data and kind of figure it out and get a good idea, then we've done our development community a disservice. Some of this stuff, when it gets a little more complex, yes, I'm trying to put a fabric together or something like that, yeah, of course, you're going to have to go and read a little bit of documentation. But even the early implementations we saw from I won't say which company, they put payload out with the DMTF copyright statements in it.

They didn't read this part of the spec that says you don't do that. So even the developers weren't reading the spec on the production side of the wire. So that's just the state of the industry we're in. So it really had to be human readable, and yet you know you're going to put orchestrators, you're going to put AI engines on top of this stuff, stuff-eating metrics and complex code. And so we needed to make that machine-readable stuff because that's where a lot of the value-add goes when you make an industry-standard interface. You're going to put value-add on one end of the wire or the other, and if one end in the bottom end is starting to become commercially and off available off the shelf and you want an interoperable,

then you're driving the revenue to the GUIs and apps and, and, and, and services. So we need to make that easy too. And of course, secure and interoperable again, one Oh was focused on servers.

We had people going through and removing stuff from the spec before it went out the door to make sure it was IPMI compliant. And then we started adding stuff back to it. Additional features coming out about every four months from the Redfish Forum. And then we've got a whole slew of industry partners we're working with, this Neon Swordfish, Green Grid and ASHRAE to cover facilities, power and cooling. Working on Ethernet switching we've got work with gen z and then there's some folks bringing ip in for fabrics we've got pci in there as fabrics so we've really thought about you know how how does that back end look as well as the front end and when we need to expose it versus when we don't. When you look at the Redfish Forum, Jeff Otter's been co-chair of it,

and one person or another from Dell, Mike Ranieri, known as Mr. Whitespace, has been a real asset to the DMTF when he came along, helped automate a lot of stuff, and a really sharp person. We formed in September of 2014, and then we just started a three-month churn. Every three or four months, we've used GitHub for the whole process of developing the spec and the schema. So if something is ready, whether it's small or large, we just pull, merge it into the tree, and add it to the release notes. It's become a real good way to keep the engine rolling and keep additions coming across. When you start looking through that list, we finished mocking out the server completely and identifying the server.

It took us about two years to do that by the time we added advanced communication devices and replacement for KCS on the host interface. Then we added composability and started the telemetry work in 2017. And then we finished up the initial profile work in late 2017. And I'll go into profiles in a minute, why that's important. We added open API support in 2018. We couldn't have done that if we were focused on a true API, where you are tying your data model to the semantics of the transport.

We were able to add JSON schema. We were able to add OpenAPI. We were able to add any schema. We could go back and do the common information model if we wanted, but there's no desire to do that. So just any language that you can express a data model in, you can express Redfish in. Gone through and added certificates.

We're looking at redoing the sensor model completely. When we started, we did power and thermal as part of the chassis, and that makes sense. I'll go on to that in the next slide. But the reason we did that is, well, you know, physical things go with physical, and logical goes with logical, and I can compose a system out of anything, logical constructs, but my power and cooling zones you can't really just change on the fly well yet. So those are pretty static. What we found out is when we started going through and modeling things with ASHRAE,

when it comes to racks, you're okay. When you start doing buildings and outlet groups and rooms, the current sensor model gets a little hard because it's tied to a chassis. And not everybody is wild about modeling a building as a chassis. Firmware update multi-part was added. So we had push, pull semantics for a couple of years. Everybody started doing multi-part push. And all did it differently.

So this latest release has a multi-part firmware update in it, some last PCIe mods. I won't go into what that was. And then the composition registry. We have this concept called registries, and they're kind of three different things. They're all defined the same way, but we use them for three different use cases. So you've got the schema language, but what about errors that come back? I really don't want to populate that whole error construct and force a lightweight implementation to fill out large text strings.

It's just, you know, so we do the whole key thing, right, where I've got the name of a registry and the entry in the registry. It's still human readable, right? It could be task, task aborted. Okay, I can read that and know what it is. But that task tells you to look up in the task registry and task aborted says go find the task aborted message and it's got parameters.

You can fill out a nice pretty little message for the user. That's one thing we use them for. The other thing is BIOS because everybody's BIOS is different, wildly different, even from version to version from the same vendor. The strings change. So we basically redid the HII tables with a registry. And then the last thing is a new one, and I'll let Rochelle talk about that one,

which is another cool use for registries. And then alignment with other standards organizations. In August 2016, SNEA released the model for network storage. That was Swordfish. If you think about that, that's been three years. And more on that later. We worked OpenYang Redfish mapping algorithm for Ethernet switch. You can find that out there.

There's kind of two models when it comes to switches. There's the brute force one, and that's what Ethernet switches, all those Yang mappings, Yang to Redfish. And that makes sense if you're building a switch out of a Redfish-enabled server. All you're adding is a switch Ethernet part, and you can still manage the server like a server. It doesn't make sense when you're trying to do underlay overlay. That's more of a fabric model.

And then we've got work registers with all these alliance partners, UEFI, Open Compute's been a big supporter of stuff, the Green Grid, ITF, we've been working with them, Broadband Forum, ASHRAE. And then, of course, we've got an interesting bit of work going on, first three-way work register we ever did between NVME, SNEA, and the DMTF to make sure we had mappings for the NVME work. So this is kind of a base Redfish without fabrics, no bells, no whistles. This is kind of the initial version of it. We really had three major collections, and everything else was kind of a service.

You had systems. Systems, think of that as the data plane, right? Anything that's the, you know, I'm going to connect up so that they can talk to each other within what I would have traditionally drawn a piece of sheet metal around. That's a computer system, and it'll have processors, disks, NICs, memory, all those, you know, we'll call them logical resources because they don't have to be physically on the system once you put a fabric on there. There's the chassis. That's the sheet metal view. Where does everything live? Power and thermal are there, but my disks could live in a chassis and then dotted

line go into a computer system, for instance, or the volumes could. And then you've got this management stuff. And right now, the BMCs and chassis managers, rack managers, all of that kind of those extra processors that are out there doing neither data plane nor physical plane management, they're off there. And since they're a separate set of processors, they're off in their own collection. And that would be, you know, enclosure managers, rack managers, that kind of thing. And then there's a bunch of services on the bottom. Tasks, not everything is done right away, so you can have the ability to get a long-running task started for you,

whether you like it or not, unfortunately, because you can't plan what the implementation is ever going to do. Some system might do a firmware update instantaneously. Somehow I doubt it. Normally when you do a firmware update, it may take a little bit of while to get all the bits loaded and get it ready to reset. So that task will be there and let you know when it's done. Sessions, well, you've got to establish a session. We don't, but if you're going to establish and then make and break a connection, every time you do a single I.O., you don't get much scalability in HTTPS.

So we needed a session collection, accounts, event, service, a place to find the registries, and then schemas can actually be on chip. And that's handy if they've actually modified than what you are allowed to do from the standard version. They might make a property writable. And then there's OEM extensions.

We've cleanly carved out all the OEM areas, so it's in a section called OEM, but we've included that in the normal object. You get a computer system, you're going to get all the normal stuff, and then you might get an OEM section that's got some special sauce from any given vendor in it. Events, we've got two kinds of eventing. One was a traditional Redfish event, which means I've got an HTTP server somewhere else, and it's going to send push messages over to it. And the other kind of eventing service is server-side eventing, SSE. If you want another one, let us know what it is, but those are kind of the two most popular ones right now.

We had to redo the host interface for Redfish. IPMI specified three different host interfaces. BT was a block transfer engine, which is almost DMA-ish kind of thing. KCS is really a PIO kind of byte at a time interface neither one of those are very modern and so what we decided to do was let's put a NIC inside the system and make it available to host OS

that sounds kind of expensive but all of these BMCs were already doing remote virtual media of one kind or another so they had USB controllers and USB hooks and if you looked at how they were making CDs and disks available, it was just firmware.

So it was just code. So all we had to do was take a bunch of open source code, put it in the firmware, hook it in. It took about a day and a half to mock this up and get it to work inside of existing shipping BMCs. So some of the BMCs out there can add the host interface, zero change to silicon. It's just a firmware update.

What's the advantage to that? The outside interface to get into this thing is a NIC. All my code is set up to do HTTP, gets and puts and all that. Well now the same code, it doesn't matter if I'm going out on the management fabric or from the host OS to talk to the BMC, it's the same code. I'm still doing the same HTTP gets. I'm using the same accounts the VMC, it's the same code. I'm still

doing the same HTTP gets. I'm using the same accounts. Set up the LDAP the same way. So just leveraging the code and replacing the old stuff. Oh, yeah, it has a side advantage of anything you can get to on that, whether it's OEM or not, you can get to. So like a web page. Everybody's gotem or not you can get to so like a web page everybody's got a web page now that my ups has a web page i can go to and land on it your router does at home and so you can get to that web page to run it too it isn't necessarily restricted to redfish access um interoperability interoperability profiles was another thing we had to write the as with any standard everything you put in there ends up being optional

because not everybody even in your own company or your own product line can end up being supported on every product right i might have a system with no fans it's completely passive cooled or liquid cooled still has no fans it's got a motor instead a pump those kind of things so everything's kind of optional. What we found it necessary to do then was go through and start making profiles. It basically, instead of a line item veto, it's a line item requirement list or conditional list. If you have a fan, it must have properties, temperature has to exist, for instance. So you can do conditional requirements as well. OCP was one of the first people to get a profile through.

There's a base server profile out there. Even then, it was kind of fun watching them argue what should and shouldn't be in it because when you start looking at Redfish, some people wanted virtual media. Well, we thought that was something the cost-reduced people wouldn't want. Well, some people in that room did want it. so we expect a few more profiles out of them. SNEA has leveraged the profile concept as well. You have, what, six or something? Thirteen.

Thirteen now? So they're probably the largest consumer of profiles. One of the unintended side effects, and we really like this, well, okay, some of us really like this, is that your customer can go and create their own profile. It's just a JSON document. And we've modified the tool chain so that the conformance test suite that goes in and tests an implementation can use the profile as input and verify that that implementation does everything that your profile says is required and produces an html report so real easy for a customer to go out and say here's my requirements

list in json hand it to all the vendors and then double check it super simple um yeah create open source tool to document and test conformance, right? So the Redfish storage model was really meant to be a local storage model. We started out with something called simple storage. I think it was actually called simple storage. It was just an array of disks, a collection of disks off the computer system, and that's it. That's all you had. It was really meant for local SATA drives, that kind of thing.

I'm not showing that model. I'm showing when we got to RAID controllers and more complex controllers, you know, a SAS controller, that kind of thing, where you'd have this storage object, and think of storage as a domain, and that storage domain really is that set of volumes drives and storage controllers that are visible in that domain there's usually only one storage controller in that object it's the raid controller or or sas or whatever it's an array because there were people trying to do software raid or redundant redundant controllers, that kind of thing, so we ended up making an array in there. We didn't want it to be a collection of controllers

because we just didn't want you doing that many of them. You should do multiple storage if you have multiple controllers that don't talk to the same media. And then we added drives, right? That's the physical media for the data. And one of the, I guess, architectural consistency things we had in our mind when we started Redfish was, how many are there? Collections are a pain for the client code. And since then, we've evolved our thinking to collections aren't so bad. And the thing that made us change our thinking was an option called expand.

And what expand does is it says, okay, I got an object, I got a computer system, and it's got an array of, sorry, a collection of disks. That collection is really another object that's got an array of members and then all the little members. So I can say expand level equal

two, and it'll suck in all that payload into my original get operation, and it all comes back over in one IO. So now, as more people support expand, particularly in aggregators or more advanced functionality, there's really no difference between an array and a collection. That wasn't true when we were trying to do it retrofitted on these super small BMCs that existed five years ago, right? Moore's law, we may be catching up with that processors, but we're still catching up with it on BMCs. We've got a long way to go. So we made the original

drive set an array. And that gets real painful once you get past 10, 12, once you get 14. Every time I do a get on that storage controller to get its status, I pull along all the list of drives. And so you start getting some scalability problems. You certainly can't get to rack scale with this particular solution. Volumes, at least, we did right because it's real tough to do a create with a patch to an array. Instead, you do a post to a collection to create the volume to point to the disks,

and you're able to create a volume by posting to a collection. And so we got that part of the model right. All the volumes are in a collection. It's kind of weird that disks is an array and volumes is a collection, but it all had to do with that creative of volume and make a volume span the disks. So here's what storage looks like in Redfish. Again, those three things. Hanging off a computer system is my storage collection.

I may have more than one storage controller in this system, and that's represented by the controller object inside of the storage resource. Hanging off of that storage resource is a subordinate collection called volumes, and it's got one or more members of volumes that points across one or more disks. The disks can either be directly off of the storage controller or be in the chassis. Really, that comes down to what's the URI. Everything can only live in one place, right? My URI that goes down to the device can either be slash redfish V1 system one storage one disk one disk two disk three, or it can be redfish V1 chassis one disk one disk two

disk three disk four. And so, you know, if in a JBOD case you'd hang them off of the chassis, in a local arrayed array case they'd probably be hanging off the storage controller. You could do either one. It's just a URI. When you do the volume collection, you're just using a blob. You just grab one of the disks. You select which one it is. That URI is a blob of a string. You don't have to understand it. Put it in your post for your volume to create the volume. It does help you know where it lives, though.

So when coming across implementations in the field, they could hang the disks in either place. The volumes will still be hanging off of the storage collection in the Redfish model. And I say in the Redfish model because that will be different once we start moving across to Swordfish. Oh, look, there we have a note. So, again, those limitations of the Redfish model, the Redfish storage model is best aligned with local server storage. It's really not meant for rack scales.

It's meant for controllers that are in an array, the disks in an array. Hopefully there's only one controller in that array. It's really not meant for rack scales. It's meant for controllers that are in an array, the disks in an array. Hopefully there's only one controller in that array. It's kind of odd. You'll see them where you've got redundant controllers. But the volumes are in a collection, and that gets difficult for scale, right, because that array is hard to manage. You know, how big is too big for an array?

Well, the Swordfish people have an answer. We worked with them for about the past year plus on the Swordfish solution with the thought that, remember what I was talking about, about that need for preservation of client code. Well, you have a problem in the industry with the original Swordfish having all this class of service, line of service, big objects all over the place, and the Redfish model having just a simple storage collection with some disks and some volumes in it. It's a big disparate gap. Neither one of those served the just rack-level storage need without getting wildly complex or not scaling very well. So we really didn't have a good way to preserve that client code or for you to find out, gee,

this is a Redfish implementation and there's Swordfish available. There was one. You could go look at a computer system it was hosted in, look for hosted service, and then find your storage collection that way. But it meant a bunch of hops through the system. So it wasn't real scalable. So, you know, clients really needed to implement a migration path so that they can, as they walk through a Redfish collection, realize, oh, wow, this is a Redfish collection with stored fishy things in it. Or this is actually a sword fishy thing backed by Redfish.

We needed a way to preserve that client code out there and give them a migration path, kind of a crawl, walk, run scenario. Hopefully Swordfish 1.1 addressed that. Spoiler alert, you have to stick to the next presentation to hear that. Probably should have saved that one for the last slide because that is the next presentation. So I'm going to take a quick trip down. I don't know how many of you go inside the box, but I got a BMC. How do I get all of this information up there?

Remember earlier I said part of the DMTF's mission is to create all that signaling inside the box so that we can create these ecosystems out of commercially off-the-shelf components, not just hardware, right? And that's where this thing called RDE comes in. There's this, I hate the acronym PMCI, but that's the name of the work group. There isn't really anything called PMCI other than platform management controller interface. It's kind of this overall architecture. There's a new version of the white paper coming out. If you're into signaling inside the box, it should be out hopefully within a month or two. I mean, we've been sitting on it forever. That really kind of explains that there are processors and signals inside the bus, I2C, PCIE,

those kind of things, later on Gen Z, CXL, I3C. You've got all these wires running around inside your box that you can actually do management traffic over, and you can find out a lot of things. The problem is a decade ago we were all doing it a different way, and that was vendors hated it. They were producing all the components because they had to do a different one for each OEM,

and the OEMs hated it because it costs us extra money every time we wanted an OEM to do something. So we created this thing called PMCI, and it's got a couple of transports that transport packets around inside the box. So these packets are a different format. There's some that are meant for monitoring and control. We do firmware update with it. But we really didn't have anything

that expressed Redfish data very well. Well, gosh, provider architectures aren't anything new. I mean, Sim was based on a provider architecture, WMI, Pegasus, whatever. You had a little plug-in that knew its management domain. I manage the disks. I manage this. I manage that.

If I can just turn that into something that it can eat, I'm not going to put HTTP and JSON over this thing. It's a bitwise interface. It's not meant for streaming data. So what we did with RDE was we took that JSON packet that came in, hey, Mr. Storage Controller, tell me all your information. The BMC wraps it up, turns it into binary, sends it down to the device.

The device handles the request and pulls it back out. That was the concept behind it, was leverage all that PLDM network that was inside the chipset in order to get traffic inside the box without going through the CPU, just do it to the BMC. And, oh, by the way, the BMC, if we do it right, doesn't have to have any a priori knowledge about what that controller looks like. It's just data model going over a transport. I've expressed that data model with JSON schema.

So just translate it into binary. And that's what we kind of did with RDE. When an RDE device is out there on the network, this thing called PLDM goes out and does its discovery, feeling every device out there for what language it speaks and what part of the architecture it supports. Do you have sensors? Do you do firmware update? We're adding one for security. I'll get into that in a few slides. Do you do RDE? And if it supports RDE, which is pldm type 6 if you really

care they start negotiating parameters and one of those first thing it asks is all right how many objects do you have i've got four disks two controllers and you fit me in this part of the hierarchy all of that's in there in a bitwise format and we've taken that JSON translator and made dictionaries. And so these dictionaries, it's a recursive dictionary. So as you're going through the object, it just comes out as a 1, 1, 2. Okay, I'm going object 1, first element 1, the second property. Use that string and substitute it out for your thing. And it's like 47 lines of code inside the BMC.

If you're doing some of the bitwise interfaces in the devices, there's no worse off-coding to it than what you've got already. You've just got to, instead of my ASN1 type string, it's a little bit smaller than some of the ASN1 data in some cases, a little bit larger than others. But the packet, worst case we're seeing them be about a K to 4K. Most cases, they're below 256 bytes.

So expressing a Redfish data object in that size of a payload is something that works inside the box. So that translation that I talked about is this thing called beige which is binary encoded json and i wish we wouldn't have called it that because somebody else got a thing out there called beige binary encoded json it's not the same so if you're into this i don't know how many of you want to go into beige i'll just skip this part of the slide because it's a little early

in the morning but the whole point is dictionaries are the key that dictionary is on chip with the device when it does the registration the bmc pulls that dictionary stores it into memory so they're all it's when it's doing the operations it's using that for the encode decode and it's you know it knows how to handle nested objects annotations if you'reed objects, annotations, if you're aware of what annotations are. We had this thing where one of the fundamental design premises was separate metadata from data because data changes, metadata doesn't. Metadata is going to be the same over the lifetime of an object.

The data is not. Data is going to change. Status changes. Speed, temperature, all that changes. Well, annotations are kind of this metadata that sneaks into the data every now and then. And so we needed a way to handle that. And a few other redfish nuances. But we see about a 10 to 1 data compression coming across the wire.

And some of these objects that aren't all that big to begin with end up really small. Now, the DMTF is going to be producing these standard dictionaries. That'll have every property in it. But it's perfectly fine for an OEM to produce an OEM dictionary, a subset of that dictionary with only the properties that you use in your device, and shrink that puppy way the heck down because those properties are never going to be there. That works because of restful semantics. If an unknown property comes in and Redfish can't translate it, it's okay to ignore it.

Now, we'd hope you'd spit out a message, but the BMC can spit out that message. The device doesn't have to deal with it. So the operations, basically, we went through in all the CRUD operations, and we say CRUD, but there's kind of two outliers when it comes to CRUD. Create is read is get, put is update, delete is delete, patch is also update, whereas put is a full replace. And then post, we double team. It can either be an action, which are kind of this anomaly in Redfish.

Not everything works really well in RESTful interfaces. For RESTful interfaces to work, you have to expose a state machine. That means first you do this, then you do this, then you do that. That's not the easy button for the client. So occasionally we'll do these actions like firmware update. Just go update it. Don't load the image and check the state and transfer the next byte and transfer the next. Don't make them do that. So we've done some

operations as like reset. I don't want, there's a race condition in reset. How do you know it was reset? I just turned it to off. It still says off. I don't know if it went on and off or if I don't know if it really reset. Did it do a power cycle cycle because by the time you went and looked at it so there's these kind of things we added actions for and we turned all those in rde operations as well and then head is this funny operation um which is like a get without any data um and and the reason that's needed is some of the headers carry metadata for like where's the location of the json schema where's the location of the annotations, that kind of stuff that something doing discovery wants. Again, they don't happen a lot. Most of it's gets and puts with the occasional action.

So how does this all fit together? So before a client ever contacts a Redfish service, the management controller is using MCTP to go out there and enumerate all the devices, finds all the storage controllers, all the temp sensors, network controllers, all kinds of stuff that's out there. It then uses, goes out there and says, okay, I'm going to give you an MCTP ID. What do you support? Ah, you support PLDM. I'm going to start using PLDM. Do you support type six? Yes, you do. Great. We're going to fall into RDE discovery. Give me all your addresses, all

the object IDs that you have. Let's get all those resources. What actions do you have? What associations between things do you have? Entity associations. And give me all your dictionaries. This happens at system boot up or when the device gets plugged in. Once all that discovery and setup's

been done, now you're ready for a request to come in. A request comes in from the client. The MC determines that that URI is okay. This is a URI I made up and I exposed, and it really isn't slash storage slash one. It's slash MCTP endpoint ID 47, and decodes it and sends it to the right device. It translates all those HTTP headers that need to be passed down.

It uses the binary encoded JSON to take that JSON object and encode it into binary. It shoves it over there using PLDM. The device processes the request, decides what to do with it. Response comes back. The BMC then goes and reassembles all that data, taking it the other way through the beige dictionary. Instead of taking the strings and turning them into numbers, it takes the numbers and turns them into strings

and formulates that HTTP response and sends it out the wire. It sounds, I don't know, either dirty or intuitive and a lot of work, but there were people that five years ago when we started this said it couldn't be done. It took folks literally to prototype it and get it to work to show it was not only not heinous, but it was actually kind of easy in some spots. So RDE, there's a bunch of stuff that's in Redfish that RDE handles. Tasks, right?

So if a task is long running, who knows about it? The device knows about it. So the device has to be able to handle a task. It's perfectly fine to do one task at a time, but it's saying, hey, it's going to take me a while to do a secure erase or to rebuild a raid set or whatever that is, right? These things don't happen quick, so it's okay to hang on to that and keep it going. Specify how events are handled. So that's another thing that, you know, something bad happens, somebody pulls a disk drive, pulls up cable, whatever, that event has to go back to the BMC. That's all handled. There's information for how to do OEM dictionaries and OEM

sections. There's state machines and examples in the rear end appendix of the spec. The binary format for the dictionaries is specified. and there's a bunch of examples of what a Redfish tree would look like and payload would look like, so we tried to do as much as we could to help folks out the first time around. And the dictionary builder has also been made open source.

So you can just take your schema and build a dictionary out of it. And there's some rules around that. So just a couple more things. The DMTF does more than just Redfish. I don't know if anybody ever heard of SMBIAS. It's probably the most successful DMTF standard. It's been in every machine for the past, what, 15 years.

It's how the operating system learns what's inside a lot of the machine. And it's something that most people just don't realize it's there. I mean, it's in x86 Apple machines. It's just something that most people just don't realize it's there, and yet it's in billions of machines. PMCI is a group that really took off once their specs made it into the south bridges and we could start tunneling traffic through PCI from the BMC. The I2C and I3C, it wasn't all that interesting, but once we could start tunneling traffic, then we started running PMCI everywhere. There's work going on with Gen Z. We hope to get something going with CXL. We've got a relationship with MIPI. I could do a couple of slides on what PMCI does alone. There's more mappings coming along because we're starting to

realize the more mappings we do to those signals inside the box. I got a controller and in a Gen Z environment, that's a FAM drawer over there, fabric attached memory. Well, traditionally, that was inside the box. I ran I3C over it to get my temp sensors. Now I've disaggregated it. Where does that temperature sensor data go? Who's in charge of it? How does it get it? You know, it's kind of this hole

that everybody kind of forgot about. What if I want to do that with PCI? How do I get that temperature sensor back to the BMC? How do I get it to the system to know things are failing? Do I use it just to the fabric manager? Does the fabric manager go back to the BMC? The more places we run MCTP, the better off the industry is for creating other fabrics besides the ones we've got. The latest thing is this thing called SPDM, which is Security Protocol and Data Model.

Remember the lecture about data objects, right? SPDM is just the data objects and the protocol to and from, you know, get version, version response, negotiate, negotiate response. It's all those messages that go through and are used for authentication, identity, and in 1.1 we hope to do encryption key exchange. It's based on what the USB guys started with, USP authentication spec, and so we know it's tested, but we've changed some stuff. We've added firmware measurement. And the reason we've added that is you've probably seen some of the supply chain issues that are going on in the industry. Well, how do I know what code was landed on that device if I can't measure the firmware?

PLDM does firmware update. I can measure that firmware that I'm sending to you, and we're going to agree on the hashing algorithm, and if you don't agree on the hash, when you come up next time, I'm not going to turn you on in the system. That's what's missing from TLS. We couldn't just use TLS. TLS does authorization and key exchange. It doesn't do identity management.

It's just doing certificates and then doing the key, which, by the way, we're using X.509 certificates too. So we're leveraging everything that's out there in the industry, but we're adding what's needed to build secure zero trust based on root of trust all the way up to the processes. And it's not just us. We've got a work register with the PCI SIG. They're going to use the objects.

OCP, we're working with them to get them in. JEDIC, HDBaseT. HDBaseT wants it for consumer equipment and video cameras and stuff like that. There's folks interested in doing this when you start thinking about your car. If somebody hacks the sensors on your car or the cameras on your car, you really need to do, and they're trying to build it out of basically computer components. So SPDM is one of those things that's really making it across the industry.

Those are the known mappings. We've got a bunch of other mappings that we can probably do that we're working on, but we've got to get the specs out the door first. The.95 spec, if you're into this at all, should be available on the DMTF website, if not now, then early this morning. That.95 WIP has a couple of bugs in it.

They're noted in the appendix, but they're already fixed in the GitHub, and we're going through one last round before we get it out the door. And then the PMCI updated white paper is forthcoming. It's been forthcoming for two years, though, so hopefully it'll make it out pretty soon. But every time we add a new mapping, right, we've got to go back and update the white paper, and that slows it down. And then SIM.

You know, DMTF was known for the common information model. I think we just did our 52nd or 53rd release of it. It's been around for a really long time. When it was formed, it's almost like Redfish. Redfish, we've got the core group, and there's a neat thing in the DMTF, you just spawn a task force to do a bunch of work. You don't have to take up a whole meeting.

So we'll spawn a task force, and they just kind of kick themselves off to work on a subset of work. There's a firmware task force, a fabric task force, a network switch task force. I don't know. There's eight or ten of them. It does expand your meeting count, but it does limit the conversation of the people that really care about something, and then they bring it back to the regular group. Well, that's what the SIEM kind of was. We had the architecture group and the schema group and core and all

these other groups, and as SIEM has matured and development has become complete, we've consolidated all those down into one SIEM forum. So the SIEM forum was the one people doing all the conformance tests for smash and dash. And so they had the money, and they've just got a new dash conformance suite that just got released a month or two ago. And so that's out there. Anyway, that's SimForum. They just consolidated.

We just consolidated everybody under one org. It just didn't make sense to have it populated out like we used to. How are we doing on time? Good. Got five minutes. So in summary, I mean, Redfish, along with the DMTF working groups and all our alliance partners, and we've got a bunch of them, man, and I'll tell you, the way work is done this way, you know, in the old days, somebody would produce a spec and then try and shove it down the industry's throat,

and those days are gone. You really got to take the industry along with you, step at a time, get buy-in, and that's one of the reasons that Redfish was successful. That and some of the architectural principles, getting them right, it wasn't a coincidence, right? We had the right people in the room, people who had done this before and before that, and had learned their lessons from how not to do things. Is Redfish perfect?

No, it's not. Are there other ways to do things? Sure. But Redfish is in every server that's being built nowadays. I don't think there's anybody who's not shipping it. So it's out there. It's secure. It's easy.

It's scalable. It's human readable. And it's good for hybrid IT management for server storage, networking, power cooling, fabrics. Gen Z is going to use their fabric management completely with Redfish, which is kind of an interesting concept. But it helped clean up a lot of stuff, too. And we're solving the problems for composition, resource management, aggregation engines, fabric management. They're all in the model now.

Aggregation has been one of those quiet concepts that we've had since day one that we've never really published a lot of information about. And I'm going to do what I can to make that change this year. So we're going to try and get out all – well, I'm going to try and get a lot out about aggregation. We'll see how well we do. And then we're plumbing the mechanisms inside the box to make all of this work. That's no, I mean, that's a lot in one sentence. But the ability to go through and get all of that stuff interoperable has taken the better part of a decade. And we're getting closer and closer to it. And then we're enabling that root of trust, right? You hear a lot about root of trust in a decade. And we're getting closer and closer to it. And then we're enabling that root of trust, right?

You hear a lot about root of trust in a platform. Everybody's building it. Nobody's really got it 100%. But without an industry standard secure way of doing attestation, identity, and key exchange, you can't do any of it. And that's what everybody's realizing that SPDM delivers. So that's it. Any questions?

Oh, yeah, don't miss the hands-on workshop tomorrow. And then there's the little tickets for the raffle. If you did not get your ticket, every Redfish and Swordfish session you go to today, there's a set of Bose headsets being raffled off tomorrow night at the Swordfish event. You have to be present to win. Make sure you get your tickets. And when we switch presentations, go get another ticket. Go ahead.

Yeah. go get another ticket go ahead so question is are you planning any redfish extensions for NBME outside the work that's being done so we've got a mapping effort underway who's got the pen on that you so

I went to last January we met three-way NVMe, SNEA, and DMTF, and we said, look, NVMe MI has got his own thing. By the way, NVMe MI, you're using the wrong version of MCTP. Please wake up. They're kind of the outlier when it comes to MCTP NVMe. They did their own bitwise data model. I would be much happier if they used RDE.

If they get to the point where they're trying to express complex relationships in a bitwise data model, they'd be much better off served using NVMe, and they've kind of said, yeah, you're probably right. As a result of that meeting, we sat down, and I went to tell and sat down with some folks, and we went through the NVMe spec, and we have what Mark Carlson is calling the Rosetta Stone of how do I map NVMe and my properties to Redfish objects. It's a by-hand mapping. And so I've got the chicken notes in the PowerPoint, and then somebody was going to turn it into an Excel spreadsheet, and it's kind of gone. We really could use somebody to work on it if you've got time. Let's put it that way.

So I think I would supplement that probably is we're going to add to redfish and swordfish whatever needs to be added to support the engineering resources. Absolutely. How much is that? Yeah, I think we need to figure out what that is. But, you know, we started with that online agreement that Jeff talked about. And, you know, we're driving that through the resource right now. We've got the fabrics model. There's Ethernet on the fabrics, PCI on the fabrics, Excel. We'll go into whichever models we need to and extend them.

Right now we know we have a few concepts that are missing that we need to find a way to inject in. We want to reuse existing concepts where we can. We'll add properties and make that happen. We know we'll have some concepts in our domains so we can figure out what that maps to and how to add that in.

And then see what else we need to do. So is that domain from MDME or MDME MI? I'm sorry, I'm sorry, it's company independent. I think what I Well, domain is coming into MDME, that's why I got confused. Um... Well, domain is coming into NVMe, that's why I got confused. The term domain is actually coming into NVMe. Yes. So, coming from the NVMe guys, we've got, rather than diving into the whole model, because I think we're actually out of time right now, we have the concept mappings coming from NVME and NY both, coming from single drive usage,

coming from NVME over fabric. So we'll take all of, you know, basically all of those permutations and map them to Redfish and Swordfish and make sure there's no gaps. Because the thing we really don't want to end up with is clients needing to have multiple interfaces when they're trying to get everything up to the end user,

especially when they've got Redfish at the top end. Those things need to match together, so that's what we're going to commit to making sure gets done. And then to the point Jeff was just making as to how that gets implemented on the bottom end, that's a whole separate question. Yeah, yeah. So, yeah.

So, yeah, respond. Sure. So independent of EMI and AMMI, I think we should be able to build on redfish and scorpfish and still get that. Because EMI comes short, it deals with virtual resources and comes short of some properties like port domains and stuff like that. It's really important.

So I'd just like to see a model that's sort of independent of MI should be complementary with independent. So that's an interesting... So when I hear you say that, I hear you say, draw me an instance map and ask someone to try and use RDE with it. I don't know if it will happen, but that would be an easy way to do it. Yeah.

That would be one way to address it. Yeah. Okay. If you go back to slide 13 and explain for me what that bullet about the spirit. 13. Which one? that bullet about sparing. Thirteen. Which one? It said not optimized for shared resources like shared

sparing. What do you mean by that? It's in the middle of the page. I'm looking. Not optimized for shared resources like shared sparing. Oh, yeah. So, the storage model in Redfish, not Swordfish, in Redfish, I got an array of disks. I got a volume.

What if I want one of those disks? I got this volume and that volume. What if I want to share the same spare across the two volumes? We don't really have that pooling concept, that way of doing it. It's not in the Redfish model. It's not very efficient. There's some ways to do some of it, but way of doing it. It's not in the Redfish model. It's not very efficient. There's some ways to do some of it, but it's really ugly. All right. Thanks. Thanks for listening. If you have questions about the material presented in this podcast,

be sure and join our developers mailing list by sending an email to developers-subscribe at sneha.org. Here you can ask questions and discuss this topic further with your peers in the storage developer community. For additional information about the Storage Developer Conference, visit www.storagedeveloper.org.