Adding ID of connected Sender or Receiver to support flow changes, HDCP, and other dynamic behavior when a client is transient or simple.

[andrewstarks]

When supporting HDMI/DisplayPort devices, or in scenarios where the expectation is that the device behaves like HDMI/DisplayPort, there are many dynamic scenarios, most already covered in use cases, but in summary:

After initial connection, the sender needs to respond to receivers when a user...

• unplugs monitor from the gateway, plugs different monitor in.
• changes the mode of monitor, triggering a change in audio latency
  and a sender needs to respond when a user...
• changes the resolution change on their source, outside of NMOS
• uses content that includes HDCP, where there needs to be one direct TCP connection per node for use by each Sender on that node to each node that contains one or more receivers. (as per HKEP Protocol in development within VSF IPMX group)
• ...?

In each scenario, the Receiver or the Sender would benefit (or possibly require) from knowing what it is connected to. In the case of the Sender, this would include all of the connected Receivers.

Note: As currently specified, HKEP will require Senders to have a TCP/IP connection to each Receiver to support locality check, which uses a small amount of periodic traffic to verify that the connected device is HDCP compliant. There hasn't yet been any discussion on how to establish this connection, or whether or not its possible to use the connection for more than just locality check.

[N-Nagorny]

Closed because it's covered by IS-11 and NMOS controller concept.