Link Status Dependencies（链路状态依赖关系）
DL_Down状态下的事务层行为
DL_Down状态表示链路上没有与其他组件的连接，或者与其他组件的连接已经丢失，并且无法通过物理层或数据链路层恢复。本节指定了当DPC未被触发并且数据链路层向事务层报告DL_Down状态时，事务层的行为，表示链路不可用。
•对于DL_Down状态的端口，事务层不需要接受从数据链路层接收到的TLPs，只要这些TLPs没有被数据链路层确认。这样的tlp不修改接收流量控制credit。
对于下游端口，DL_Down状态由以下方式处理:
•将任何缓冲区或与未完成的下游传输请求相关的内部状态初始化回其默认状态
◦注意:端口配置寄存器必须不受影响，除非需要更新状态与过渡到DL_Down相关。
•对于Non-Posted Request，对设备核心提交的传输请求进行Completion，返回不支持的请求完成状态，然后丢弃请求
◦Non-Posted Request已经被事务层处理，返回Completions可能是不实际的，被丢弃。
注意:这相当于在链路状态变为DL_Down之前请求已经传输但尚未完成的情况。
•这些情况由请求者使用完成超时机制来处理。
•端口必须终止任何针对端口的PME_Turn_Off握手请求，这样端口就被认为已经确认了PME_Turn_Off请求
•对于所有其他Posted Request，丢弃请求
◦这是一个与端口关联的(虚拟)桥的函数相关的报告错误(见6.2节)，并且必须作为不支持的请求报告。对于根端口，报告此错误是可选的。
◦对于已经被事务层处理的post Request，端口被允许不报告错误。
注意:这相当于在链路状态变为DL_Down之前发送请求的情况
•丢弃所有由设备核心提交的待传输Completion
对于上游端口，DL_Down状态通过以下方式被处理为复位:
•将所有PCI express专用寄存器、状态机和外部可观察状态返回到指定的默认或初始条件(定义为sticky的寄存器除外)
•丢弃所有正在处理的tlp
•对于交换机和网桥传播热复位到所有相关的下游端口。在支持5.0 GT/s以上链路速率的交换机中，上游端口必须将每个下游端口的LTSSM引导到Hot Reset状态，但不能保持LTSSM在该状态。这允许每个下游端口在热复位完成后立即开始链路训练。建议所有交换机都这样做。
DL_Up状态下的事务层行为
DL_Up状态表示与关联链路上的另一个组件建立了连接。状态为DL_Up的端口的事务层必须接受接收到的符合本规范其他规则的TLPs
对于RC或SW的下游端口:
•当从非DL_Up状态转换到DL_Up状态时，当槽位控制寄存器中的自动槽位功率限制禁用位为Clear时，端口必须向链路上的另一个组件发送Set_Slot_Power_Limit消息，以传递在槽位能力寄存器中的槽位功率限制规模和值字段中编程的值。如果槽能力寄存器还没有初始化，这个传输是可选的。
下游端口包含期间的事务层行为
在下游端口包含（Downstream Port Containment DPC）期间，与下游端口关联的LTSSM被定向到禁用状态。一旦它达到禁用状态，只要DPC状态寄存器中的DPC触发状态位被设置，它就保持在那里。
•一旦DPC被触发，不再接受来自数据链路层的额外(上游)tlp。
•如果触发DPC的条件与上游TLP相关联，则任何已经从数据链路层接受的后续上游TLP必须被静默丢弃。
下游端口处理设备核心提交的(下游)tlp，处理方式如下。
•如果触发DPC的条件与下游TLP相关联，则允许在链路断开之前静默丢弃或传输任何先前的下游TLP。否则，适用以下规则。
◦对于每个Non-Posted Request，端口必须返回一个完成并静默丢弃请求。“Completer ID”字段必须包含与下游端口关联的值。
•如果在DPC控制寄存器中设置了DPC Completion控制位，则生成的Completion状态为不支持请求(UR) Completion状态。
•如果DPC Completion控制位为Clear，则生成Completion时显示Completion中止(CA) Completion状态。
◦端口必须终止任何针对端口的PME_Turn_Off握手请求，这样端口被认为已经确认了PME_Turn_Off请求
◦对于所有其他Posted Request和Completion，端口必须默默地丢弃TLP。
对于触发DPC导致相关完成无法返回的Non-Posted Request，适用以下规定:
•对于支持DPC的RP扩展的根端口，根端口可以跟踪某些Non-Posted Request，当DPC被触发时，为每个跟踪的请求合成一个完成。这有助于避免完成超时，否则将作为触发DPC的副作用发生。每个合成Completion必须有一个由DPC Completion控制位决定的UR或CA Completion状态。跟踪的Non-Posted Request集是特定于实现的，但强烈建议跟踪由主机处理器指令(例如，“读”、“写”、“加载”、“存储”或对应于AtomicOp的指令)生成的所有Non-Posted Request。其他需要跟踪的候选对象包括来自其他根端口的对等请求和来自rciep的请求。
•否则，相关的请求者可能会遇到完成超时。软件解决方案栈应该理解并考虑到这种可能性。
到这事务层介绍差不多了，后面针对一些点进行介绍。
