SAS - PL_OC state machine - How many?

Seto, Pak-lung pak-lung.seto at
Wed May 14 14:39:18 PDT 2003

* From the T10 Reflector (t10 at, posted by:
* "Seto, Pak-lung" <pak-lung.seto at>

-----Original Message-----
From: Elliott, Robert (Server Storage) [mailto:Elliott at]
Sent: Wednesday, May 14, 2003 4:22 PM
To: t10 at
Subject: RE: SAS - PL_OC state machine - How many?

* From the T10 Reflector (t10 at, posted by:
* "Elliott, Robert (Server Storage)" <Elliott at>

> * From the T10 Reflector (t10 at, posted by:
> * "Seto, Pak-lung" <pak-lung.seto at>
> *
> How many PL_OC state machines per PORT LAYER?
> The way that is stated 8.2 of SAS v2g - "There is one PL_OC 
> state machine per port" - it seems match the state machine 
> description.
> What if I have a "chip" that can support multiple links (e.g 
> 4 links) and wide port configuration.  First, I would assume 
> the "chip" will try to attempt to make wide port link
> initialization (in this example - 4 links) by
> sending out IDENTIFY frames on all 4 links with the same SAS 
> address.  In this case, if all the returning IDENTIFY frames 
> has the same SAS address, a 4-links wide port is established 
> - therefore - ONE PL_OC state machine.

Correct (assuming the chip chose to send the same address
out its 4 phys).

>>>>>>> If a chip have multiple links and support wide port configuration.
>>>>>>> It should try to use the same SAS address to try to initialize it's
>>>>>>> with the maximum width because it will give the system higher
>>>>>>> If that fail, base on the returing SAS address, it can re-configure
>>>>>>> to match the IDENTIFY frame response to the next best configuration.
>>>>>>> If a chipo with multiple links and support wide port, but uses
>>>>>>> SAS addresses for IDENTIFY frames (e.g. 1 SAS address per link), it
>>>>>>> not be able to configure itself to wide port.  Of course, the system
>>>>>>> always pre-configure to certain configuration instead of automatic
>>>>>>> configuration.

> What if the returning IDENTIFY frames has all different SAS 
> address and assume the "chip" will try to re-initialize the 
> link by [assigning?] different SAS addresses to each links 
> (assuming to make config stay in one SAS domain).

The chip should not change its own addresses (the ones it sends
out with outbound IDENTIFY address frames) just because the
inbound IDENTIFY address frames had different addresses.

>>>>>>> This is not true unless you want to disable some links/ports
>>>>>>> For example, a chip with 4 links, two links connected to one
>>>>>>> and the other two links connected to another expander.  The two
>>>>>>> are connected to a FAN OUT expander.  If this chip does not change
the address
>>>>>>> for one of these two link set, it will have to disable two of the
links, because
>>>>>>> no two ports can have the same SAS address within a single SAS
domain - because
>>>>>>> of the FAN OUT expander

It's OK to have the same SAS address in two domains at the
same time.  (this is why is serves as a "port identifier"
in the SCSI architecture but not as a "port name.")

>>>>>> Not when it is connected like the example described above.

A "port" is a virtual concept - a collection of phys
using the same SAS address that are attached to another
set of phys using the same SAS address.

>>>>>> Yes, this is true, but the PL_OC SM is not virtual

> After link initializaiton, 4 single link - 4 ports configuration is
> established.  In this case - there will be 4 PL_OC state 
> machines with "ONE" port layer???

There are 4 ports in this case, each with a PL_OC state 
machine.  They're all at the port "layer" architecturally.

Each port object has its own transport layer state machines, 
port layer state machines, and one or more phys.

Each phy object has its own link layer state machines and 
phy layer state machines.

>>>>>>> It is easy to create "OBJECT" in software, but how can it be
>>>>>>> handled in hardware - in gates.  This is the major problem with
>>>>>>> AL3.

> Does the standard expect the SAS port layer being implemented 
> in firmware?
> Otherwise, how does hardware implemented SAS port layer can 
> dynamically support various number of PL_OC state
> machines (not easy)?

The standard is not very close to actual RTL implementation in the
port and transport layers.  The transport layer describes state 
machines being created and destroyed based on frame reception and
application layer requests.  This is not how real hardware works.

>>>>>>> Exactly, "create" and "destroy" is simple for software

One way to conceptualize an implementation is as a single
"port layer" state machine that handles up to 4 ports 
simultaneously.  Everything it deals with has a
"port number" index appended to it.

> In the SAS spec, it does not mention about this kind of 
> situation and how
> the PL_OC state machine or port layer handle this situation?  Did I
> interpert the PL_OC state machine wrong?
> Pak

Rob Elliott, elliott at
Hewlett-Packard Industry Standard Server Storage Advanced Technology

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list