Task #1123
closed
Task #1115: Design Face and Prefix registration protocol
Face management protocol
100%
Description
Define a face management protocol that supports initiating Ethernet, UDP, and TCP connections, including both point-to-point and multicast.
Functionality is equivalent to addface and destroyface actions of CCNx Face Management Protocol.
Updated by Junxiao Shi almost 11 years ago
- Start date changed from 01/21/2014 to 01/22/2014
Updated by Junxiao Shi almost 11 years ago
- Due date changed from 01/26/2014 to 01/29/2014
- Start date changed from 01/22/2014 to 01/28/2014
Updated by Alex Afanasyev almost 11 years ago
I have put a skeleton for the face management protocol to wiki (FaceMgmt).
The types are assigned from the range specifically reserved for forwarding daemon use (I have updated TLV spec for that). To simplify our future debugging, the type assignment right now is non-overlapping.
Updated by Alex Afanasyev almost 11 years ago
- Subject changed from face management protocol to Face management protocol
- Status changed from New to In Progress
- % Done changed from 0 to 50
Updated by Junxiao Shi almost 11 years ago
- Due date deleted (
01/29/2014) - Category set to Management
- Target version changed from Mock to v0.1
- Start date deleted (
01/28/2014)
This protocol is missing the representation of underlying addresses.
@Alex, do you want to write this part, or should I write it?
Updated by Junxiao Shi almost 11 years ago
- Category changed from Management to Protocol
Updated by Junxiao Shi almost 11 years ago
20140208 conference call decides that underlying address should be written as a string using URI syntax.
There was disputes on whether to put additional fields (such as "local IP" of UDP multicast) in the query string or in the hash part.
- in the query string:
udp-mcast://224.0.23.170:56363/?local-ip=192.0.2.1 - in the hash part:
udp-mcast://224.0.23.170:56363/#local-ip=192.0.2.1
A problem with putting additional fields in the query string is that it may conflicts with an HTTP address, when this protocol is extended to allow connecting to a remote WebSocket endpoint.
ws://example.com/endpoint?svc=1&timeout=30 is ambiguous on which field(s) should be passed into HTTP Request-URI, and which field(s) are for local use. Suppose the WebSocket-enabled HTTP server is expecting svc and timeout fields, while the timeout field also has local meaning, it's unclear whether we should pass /endpoint?svc=1 or /endpoint?svc=1&timeout=30 as HTTP Request-URI.
Putting additional fields in the hash part does not suffer from this problem, because hash part is for local use.
The example could be written as ws://example.com/endpoint?svc=1#timeout=30, so HTTP Request-URI is /endpoint?svc=1, and the timeout field is for local use.
The conference call also decides that:
For UDP/TCP connections specified with a hostname, the IP address resolved from the hostname should be used to decide whether two connection are actually the same.
Suppose a.example.net and b.example.net both resolve to 192.0.2.4, and a face for udp://a.example.net:6363/ exists, a new request to create udp://b.example.net:6363 shall return the same face.
For UDP/TCP connections specified with a hostname, the IP address resolved from the hostname should be returned when querying the face.
In the above example, the URI of this face shall be udp://192.0.2.4:6363/.
Face description and URI are different.
Face description can be set to arbitrary value, such as "repo" or "nlsr", for diagnostics purposes.
Face URI is set by NFD to describe the underlying address of a face.
Updated by Junxiao Shi almost 11 years ago
- Status changed from In Progress to Feedback
- % Done changed from 50 to 80
I have completed URI definitions for UDP, TCP, UNIX stream, Ethernet.
I'm adding a ChannelName element, because this is the most accurate way to pick a local address.
Channels can only be created in the configuration file, because nfd process drops root privilege after processing the configuration, so that further channel creation is not possible after that.
A channel name is defined for each channel in the configuration file, and the faces/create command only needs to reference this name.
TLV-TYPE number assignment is needed for Uri and ChannelName elements.
Updated by Junxiao Shi almost 11 years ago
- % Done changed from 80 to 100
20140209 conference call decides that the configuration file should not require user to explicitly define every channel, because the IP address of a laptop may change due to DHCP lease expiry, and laptop user may plug in USB network device or enable/disable WiFi interface.
The configuration file example is updated to include less fields, such as port number, UNIX listener path, and multicast group.
NFD should scan the NIC list, and create necessary channels for existing NICs.
Handling of runtime NIC change or IP change may not be in first release.
Face management protocol is updated to remove the ChannelName field, because it does not exist in the configuration file anymore.
Updated by Alex Afanasyev almost 11 years ago
I'm confused again. We do not need any kind of "NIC listing" for all TCP and UDP faces. We will simply listen on 0.0.0.0 and :: and source IP address will always be handled automatically, for both UDP and TCP channels.
But I agree that for ethernet something special should be done, but I would suggest that for the first release we just manually configure all pure ethernet channels in config file.
Updated by Junxiao Shi almost 11 years ago
NIC list is only required for UDP multicast and Ethernet. Static configuration is not desirable, and is actually harder to implement than automatically creating channels from NIC list (for Ethernet, you still need the NIC list, and then filter it to find the configured channel).
Updated by Junxiao Shi almost 11 years ago
- Status changed from Feedback to Closed
reviewed on 20140210 conference call