网络层的主要功能是决定各个目的地节点的node ID，主要按照下面四个小结来描述。
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，CHI协议支持的NodeID域宽在7~11bits之间可变，由具体实现决定，且一个系统中所有组件的NodeID域宽必须一样，至于每个组件的NodeID值也是由具体实现决定的。
3. Target ID determination
本节描述对于不同的message types，如何决定target ID。可以从request messages、response messages和snoop request messages三个方面来阐述。
Request messages的Target ID的确定：
为了对RN的request的TgtID进行映射，CHI协议要求SAM逻辑应该在RN或ICN中实现。如果在ICN中，ICN可能会对RN发送的Request packet的TgtID进行remap(重映射)。使用SAM，除了PCrdRetrun，Request message的TgtID由以下行为决定：
- 如果request没有使用pre-allocated credit，那么TgtID的决定方式是：a. DVMOp操作用单独方式决定；b. 除了DVM操作的其它request是由address来决定。但是PrefetchTgt相对于其它requests有不同的地址映射方式，对于RN发出同地址的两笔请求，PrefetchTgt总是指向SN，其它request总是指向HN；
- 如果request使用pre-allocated credit，那么request的TgtID是由RetryAck的SrcID决定的，即原始request的TgtID。
对于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，比如software programming error。在这种情况下，HN-I仍需要对符合协议的行为返回响应，但这样会导致一致性无法保证。
HN上也可能使用SAM逻辑来对每一笔request进行映射决定发往哪个SN NodeID。
Response messages的Target ID的确定：
组件在收到message后需要回Response packets，Response packets的TgtID是由收到message的SrcID、HomeNID、ReturnNID、FwdNID中的一个决定的。表1为对于Response message中每个Response packet的TgtID和接收到的message的决定TgtID的域之间的关系：
表1 Source of response packet TgtID
Snoop Request messages的Target ID的确定：
Snoop request没有包含TgtID，协议没有定义snoop request的TgtID，是由实现具体实现的机制。
4. Network layer flow examples
本小结举几个简单的网络层传输transaction flow例子。
4.1 Simple flow
图1为一个简单的transaction flow，描述了requests和responses的TgtID是如何决定的。
图1 TgtID assignment without remapping
4.2 Flow with interconnect based SAM
图2为在ICN上发生对request的TgtID进行remap的传输场景，remap只发生在request的TgtID上，transaction flow的其它packet的TgtID和simple flow类似，不需要remap：
图2 TgtID assignment with remapping logic
4.3 Flow with interconnect based SAM and Retry request
图3为ICN发送人map，且RN收到retry响应的transaction flow，除了retry响应，其它transaction flow和flow with interconnect based SAM一致。
图3 Remapping of TgtID and retried request