GigE发现设备——IP Configuration和Device Enumeration

IP Configuration

​ 所有设备必须在重启、设备恢复默认或以太网链路协商成功后执行IP配置。IP Configuration必须支持两种协议，一是Dynamic Host Configuration Protocol（DHCP），二是Link-Local Address（LLA）。可以支持静态IP配置。

Protocol Selection

​ 每个IP配置协议的执行顺序必须是静态IP（若支持并启用）、DHCP（若启用）和LLA。
​ 出厂默认静态IP禁用，DHCP启用，LLA一直可用。
​ 注意：GVCP还提供了FORCEIP_CMD命令，用于将静态IP强制输入设备的接口#0，此地址覆盖使用本节描述的常规IP配置选择获得的IP地址。但是这个地址在重启或恢复默认后丢弃。
​ 选择IP分配的过程如下图：

​ 一旦生成了有效的IP地址，它的相关信息必须注册到寄存器中：
​ 1、Current IP address（address 0x0024 for network interface #0）
​ 2、Current Subnet Mask (address 0x0034 for network interface #0)
​ 3、Current Default Gateway (address 0x0044 for network interface #0)

Persistent IP

​ 静态IP相关的信息必须存储在设备的非易失内存中，如果没有该内存，则不能支持。
​ 以下为静态IP信息存储表：
​ 1、网络接口功能（网络接口#0的地址为0x0010）：第31位表示该设备是否支持静态IP，0表示不支持，1表示支持。
​ 2、网络接口配置（网络接口#0的地址为0x0014）：第31位表示用户是否激活了静态IP，0表示没激活，1表示激活。
​ 3、静态IP地址（地址0x064C用于网络接口#0）：这是用户分配的持久IP地址。由用户来确保这是一个有效的IP地址。
​ 4、子网掩码（地址0x065C用于网络接口#0）：这是与持久IP地址相关联的子网掩码。
​ 5.、默认网关（地址0x066C，用于网络接口#0）：这是静态IP的默认网关。
​ 如果设置的IP与同一网络上的设备IP冲突，设备就不能使用该IP地址并应告知用户，这时，设备必须使用下一个IP配置方案。RFC5227文档使用ARP协议来探测静态IP地址，以检测是否有潜在的冲突。如果分配的IP地址不能识别，应用程序可以使用GVCP的FORCEIP_CMD消息获取对设备的控制，修改引导寄存器的静态IP信息，设置为一个有效的状态或简单禁用静态IP。

DHCP

​ 一个DHCP可用标志存储在非易失内存中，如果没有储存介质，那么设备必须像启用DHCP一样进行响应，DHCP enable标志硬编码为TRUE，并且用户不可配置。
​ DHCP enable标志位于引导寄存器中。下列引导寄存器用于支持DHCP:
​ 1. 网络接口能力(网络接口#0的地址0x0010):第30位表示该设备是否支持DHCP(位集)(位清除)。这个位总是1。
​ 2. 网络接口配置(网络接口#0的地址0x0014):第30位表示DHCP是否已被用户激活(位集)或未被用户激活(位清除)。
​ DHCP消息如下图：

DHCP Retransmission Strategy（DHCP重传策略）

​ 当使用DHCP时，设备发送一个DHCPDISCOVER消息，DHCP服务器返回一个DHCPOFFER消息；设备发送一个DHCPREQUEST消息，服务器返回一个DHCPACK或DHCPNAK消息。当没有收到从服务器的任何回应，将启用重传策略。甚至允许最多2次重传（因为最坏情况下设备分别发送3个上述消息）。
​ 重传策略：
​ 1、在第一次传输时，如果在2s内没有收到应答消息，则设备将进行第一次重传；
​ 2、在第一次重传时，如果在4s内没有收到应答消息，则设备执行第二次重传，该重传可选由从-1到+1范围内选择的同一随机数的值随机分配。
​ 3、在第二次重传后，如果在6s内没有收到应答消息，设备移动到下一个IP配置协议。

DHCP租借到期（DHCP Lease Expiration）

​ 设备停止使用IP地址，并重启IP配置循环。

Link-Local Address

​ 即私有IP。IP地址范围从169.254.1.0 – 169.254.254.255。必须一直被激活。

Device Enumeration

​ GigE提供两种策略来枚举设备：
​ 1、GVCP Device Discovery（强制）
​ 2、Multicast DNS/DNS Service Discovery（可选）

GVCP Device Discovery

​ 在完成IP配置之前，设备不能相应设备发现请求，但是一旦完成了配置，并且有有效IP，那么它必须相应来自任何应用程序的设备发现请求。设备枚举是GVCP的一个组成部分。

Broadcase Device Discovery

​ 应用程序可以使用UDP广播消息来设备发现，但是广播消息不能跨路由，所以只能在同一个子网上，不能枚举与应用程序不在同一个子网的设备。在应答消息中，设备必须将源IP地址、子网掩码和默认网关设置为与IP配置期间获得IP信息相等。

Unicast Device Discovery（单播）

​ 仅仅当设备IP地址已知的情况下才能使用单播发现设备，它是通过直接将UDP数据包发送到设备。设备也必须通过单播应答来回应应用程序。

将设备关联到枚举列表

​ 为方便将一个设备关联到设备发现列表的对于条目中，设备外壳上应有一个序列号和MAC地址标签。

Zeroconf Discovery

​ 结合组播DNS和DNS服务发现。该机制将“主机”与“服务”这两个概念分开。一个服务有3个主要部分：类型（GVCP固定）、名称（识别特殊实例）及服务运行的UDP/TCP端口。每个服务还可以有一个惟一的TXT记录列表，其中包含关于特定实例的详细信息。这允许单个主机拥有N个IP接口和M个服务，而这两者之间没有显式的关系。在GigE Vision上下文中，每个服务实例对应一个GVCP控制通道。因此，可以通过这种机制实现以下用例。
​ 标准设备：通知具有一个服务的单台主机。
​ 带链路聚合的标准设备：通知具有一个服务的单台主机。多路连接可视为一个逻辑连接。
​ 带多链路无连接聚合的标准设备：通知具有多个IP地址及一个服务的单台主机，并映射到ML配置。要求程序决定连接哪一个链路，该实现已定义了。
​ 单链路的多控制器设备：通知具有多个GVCP服务的单台主机，每个服务被视为一个共享同一物理接口的SL配置。在同一以太网端口和IP地址之后的所有独立的GVCP栈共享同一IP地址，因此，如果程序改变了一台设备的IP，其他台上的IP也会跟着变化。
​ 多独立链路多控制器设备：每条链路通知一个对应不同的主机，每个主机通知单个服务。一般来说，每条链路只响应与该链路相应的唯一主机/服务名相匹配的查询，故在链路另一端的主机只能看到其连接上的接口，且能够通过特定链路降低可获得的服务数量。这映射到一个SL配置中，但每个服务有一个不同的物理接口。

Multicast DNS（mDNS 组播DNS）

​ mDNS是传统DNS协议的一种实现，但他是分散的，并且给予通过组播向正在运行的其它mDNS客户机发出查询，这些查询只是标准饿DNS查询，以用于A/AAAA记录（用于IPV4/IPV6名称解析）和服务的SRV记录。协议使用记录缓存、主机通知、已知的应答抑制和响应聚合来减少冗余流量。设备主机名由设备制造商名+设备名+设备MAC地址(大写十六进制)+".local."构成。
​ 在组播DNS Internet草案中，提供如下参考：
​ 1、分配给mDNS的IPv4组播地址是224.0.0.251。
​ 2、分配给mDNS的IPv6链路本地多播地址是FF02::FB。
​ 3、mDNS uses UDP port 5353。
​ 4、mDNS只使用UTF-8编码资源记录名称。
​ 5、mDNS使用DNS顶级域“.local.”。

DNS Service Discovery（DNS-SD)

​ 使用DNS来查找特定的服务名称。主要任务是列举服务名称列表，及将服务名翻译成相关联的IP地址。合法的服务名需为“_gvcp._udp”。若支持DNS-SD，其TXT记录必须至少支持如下键：规范版本号、设备模式、MAC地址、设备供应商名、模型名、具体制造商版本信息、具体制造商串名、序列号、自定义名和实例号。

设备的添加与删除

删除

​ 现场删除主要由控制协议处理，然后程序暂停其发送的消息命令，或者，控制和接收应用程序可以超时视频流上不再来自GVSP发射机

添加

​ 有三种方法：
​ ① 程序发送DHCP请求给服务器，后者做出响应并通知添加设备的程序，但要求客户端与服务器端联系密切；
​ ② 程序定时发送一个DISCOVERY命令，但这会消耗一定的网络带宽，尤其是每次有很多设备需要回应，一种解决方案是提供给用户一个控件来刷新设备列表；
​ ③ 执行组播DNS或DNS服务发现来发现新设备。
​ 除了网络带宽要分配给新设备外，原来的设备不受新添加设备的影响。