网络层负责确定目标节点的NodeID。本章包含以下部分：
- 系统地址映射，SAM
- 节点ID
- 目标ID确定
- 网络层flow示例
1. System address map
系统中每个Requester(包括RN和HN)必须有一个System Address Map(SAM)来决定一个request的target ID。SAM的范围可能只是简单的为所有发送的requests提供一个固定的node ID。SAM具体的结构和格式是由具体实现决定的。
SAM必须可以对全地址空间进行解码，CHI协议建议所有没有对应物理组件的地址都应该分配个一个agent代理，该agent可以对这些无用地址的访问提供恰当的error响应。
2. Node ID
每一个连接到总线Port的组件都会被分配一个node ID，用于标识ICN上packets包路由的源节点和目的节点。一个Port可以有多个node IDs，但是一个node ID只能分配给一个Port，即ID唯一。 CHI协议支持的NodeID位宽为7~11bits，由具体实现决定，但是一个系统中所有组件的NodeID位宽必须一致，至于每个组件的NodeID值也是由具体实现决定的。
3. Target ID determination
本节描述对于不同的message types，如何决定target ID。包含以下部分：
- Request messages的Target ID的确定
- Response messages的Target ID的确定
- Snoop request messages的Target ID的确定
3.1 Request messages的Target ID的确定
为了对RN的request的TgtID进行映射，CHI协议要求SAM逻辑应该在RN或ICN中实现。如果在ICN中，ICN可能会对RN发送的Request packet的TgtID进行重新映射。
Request message的TgtID使用SAM由以下行为决定：
1.非PCrdRetrun：
- 如果请求没有使用预分配的信用证credit,，那么TgtID的决定方式是：
——DVMOp操作用单独方式决定；
——除了DVM操作的其它request是由address来决定。但是PrefetchTgt相对于其它请求有不同的地址映射方式，对于RN发出同地址的两笔请求，PrefetchTgt总是指向SN，其它request总是指向HN；
- 如果请求使用预分配的信用证credit，那么请求的TgtID是由RetryAck的SrcID决定的，即原始请求的TgtID。
2.对于PCrdRetrun：
- RN发送该命令的TgtID必须等于PCrdGrant中提供的SrcID。
从RN发送的transactions，除了PrefetchTgt是发往SN-F，CHI协议期望Snoopable transaction发往HN-F，Non-snoopable transaction发往HN-I或HN-F。当然Snoopable transaction也可以发往HN-I，但这样可能会导致error，比如软件编程错误。在这种情况下，HN-I仍需要对符合协议的行为返回响应，但这样会导致一致性无法保证。
HN上也可能使用SAM逻辑来对每一笔request进行映射决定发往哪个SN。
3.2 Response messages的Target ID的确定
组件在收到message后需要回Response packets，Response packets的TgtID是由收到message的SrcID、HomeNID、ReturnNID、FwdNID中的一个决定的。下表为对于Response message中每个Response packet的TgtID和接收到的message的决定TgtID的域之间的关系：
3.3 Snoop Request messages的Target ID的确定
Snoop request没有包含TgtID，协议没有定义snoop request的TgtID，是由实现具体实现确定。
4. Network layer flow examples
本小结举几个简单的网络层传输transaction flow例子。包含以下内容：
- Simple flow
- Flow with interconnect based SAM
- Flow with interconnect based SAM and Retry request
4.1 Simple flow
图3-1为一个简单的transaction flow，描述了requests和responses的TgtID是如何决定的。
在图3-1中，不需要重新映射的TgtID分配的步骤是：
- RN0使用内部SAM向HN0发送一个TgtID的RN0请求。——ICN不会重新映射节点ID。
- HN0查找内部SAM以确定目标SN节点。
- SN0接收该请求并发送一个数据响应。——数据响应包具有来自请求ReturnNID的TgtID。
- RN0接收来自SN0的数据响应。
- 如果需要，RN0发送一个CompAck响应，其TgtID来自数据响应包中的HomeNID，以完成事务。
4.2 Flow with interconnect based SAM
图3-2为在ICN上发生对请求的TgtID进行重映射的传输场景，重映射只发生在请求的TgtID上，transaction flow的其它packet的TgtID和simple flow类似，不需要remap：
在图3-2中，使用重映射逻辑进行TgtID分配的步骤如下：
- RN0使用内部SAM向RN0发送TgtID为HN0的RN0的请求。
- ICN会将请求TgtID从HN0重新映射到HN1。SrcID仍然设置为原始请求程序RN0。
- HN1查找内部SAM以确定目标SN节点。ReturnNID被设置为匹配原始请求程序RN0。
- SN0接收该请求并发送一个数据响应。——数据响应包具有来自请求ReturnNID的TgtID，并将HomeNID设置为匹配重新映射的主节点。
- RN0接收来自SN0的数据响应。
- 如有必要，RN0发送来自数据响应包中HN1的HomeNID，以完成事务。
4.3 Flow with interconnect based SAM and Retry request
图3-3为请求被retry的情况：
上图中重新映射TgtID且请求被retry步骤如下：
- 互连将RN0提供的TgtID重新映射到HN1。
- 请求接收RetryAck响应。——RetryAck和PCrdGrant响应从接收到的请求中的SrcID中获取TgtID信息。
- 一旦同时收到RetryAck和PCrdGrant响应，RN0将重新发送该请求。——retry请求中的TgtID与接收到的重新尝试请求中的SrcID或原始请求中的TgtID相同。TgtID必须再次通过重映射逻辑（？）。
- 事务流的其余部分中的数据包以基于互连的SAM的流类似的方式获得TgtID。
