Draft: draft-ietf-taps-impl

Commentary: After some discussion with  and Theresa , we believe the interface draft does not need any changes . This adds a UDP Multicast Receive protocol - specific section to outline the specific considerations for a UDP multicast receive connection . 
 Of course it 's fantastic if we can keep things as simple as that ! I must be missing something . E.g. , from this PR : So this means that I can create a connection but never use a Send on it . Actually , I ca n't even use Initiate . Fine ... but where in the process do I learn ( or , rather , specify and then expect ) that this is the case ? 
 You need to specify a selection property requesting a unidirectional / receive connection , therefore you are aware of it when the connection is ready . 
 Sure , that 's how I 'd also do it - but that selection property does n't exist AFAICT . So , that 's the required change to the API then . 
 The way we are doing it is that we check if the address of the local endpoint is a mc group address . So that s where the distinction between unicast and multicast is made . If that is the case we also require the transport properties to include that the direction is unidirection receive . 
 Ah , sure . That makes the most sense . Still , that 's also not written in the API document . I 'm just saying this should be there . 
 Well , there is a Connection Property called " Direction of communication " ( Section 5.2.13 in the API draft ) . Maybe this should be a Selection Property instead ? Because those you have to specify before the Connection gets established . Also , do you think it 's worth adding to that section that it 's not supported to call Send ( ) on a unidirectional receive Connection or Receive ( ) on a unidirectional send Connection ? Initiate ( ) being unsupported is probably not something that applies to all unidirectional receive Connections , even though I have n't thought about use cases other than multicast yet . 
 Yes and yes . " Direction of communication " should be a selection property , as it 's unlikely to make sense as something to change later . Also , just because that exists , there 's no relationship to multicast in the text - the word " multicast " does n't exist in the API draft right now . I 'm thinking that somewhere , almost literally the statement from above should be . Something like this : If the address of the local endpoint is a multicast group address : The " Direction of communication " selection property must be set to unidirectional receive . Initiate , Send , ... ( list them all here ) are not supported . ( whatever else should be said . ) 
 Oh , I just realized that " Direction of communication " already is a Selection Property , so we do n't need to change anything there . But yes , it probably makes sense to add a paragraph on multicast to the " Specifying Endpoints " section 5.1 in the API draft . 
 We did not make it a selection property , because is not of Preference type should be queryable and probably may change to bidi after establishment if the underlaying protocol is bi - directional my be settable from bidi to recv to half - close connections . Yes , this is one of the properties where our categories do not work so great . 
 - that 's ok , then we leave the property type as it is . 
 I think this is the mapping that works best for multicast . Just to give a bit of context : First , we tried to fit multicast into Initiate ( ) because the multicast receiver actively joins a group . However , this does n't work for Any - source Multicast , as Initiate ( ) requires a remote endpoint . Re - reading our definitions in the architecture draft for  , Connection , and so on , I think we do n't need to change them , as they are already generic enough for multicast to fit in there . In the Implementation draft , at the beginning of Section 2 it says that a listener is " a passive waiting object " . Here , " passive waiting " sounds a bit off to me if a listener can actively join a multicast group . So maybe we want to change that to just say that a listener is " an object that can receive incoming connections" . I think this is fine besides a little nit .
Paragraph (version B):
Established UDP Multicast Receive connections represent a pair of
specific IP addresses and ports.  The "unidirectional receive"
transport property is required, and the local endpoint must be
configured with a group IP address and a port.
Paragraph (version B):
Calling "Initiate" on a UDP Multicast Receive Connection causes an
immediate InitiateError.  This is an unsupported operation.
Paragraph (version B):
Calling "InitiateWithSend" on a UDP Multicast Receive Connection
causes an immediate InitiateError.  This is an unsupported
operation.
Paragraph (version B):
A UDP Multicast Receive Connection is ready once the system has
received traffic for the appropriate group and port.
Paragraph (version B):
UDP Multicast Receive Connections generate an InitiateError if
Initiate is called.
Paragraph (version B):
Once in use, UDP throws "soft errors" (ERROR.UDP(-Lite)) upon
receiving ICMP notifications indicating failures in the network.
Paragraph (version B):
LISTEN.UDP.  Calling "Listen" for UDP Multicast Receive binds a
local port, prepares it to receive inbound UDP datagrams from
peers, and issues a multicast host join.  If a remote endpoint
with an address is supplied, the join is Source-specific
Multicast, and the path selection is based on the route to the
remote endpoint.  If a remote endpoint is not supplied, the join
is Any-source Multicast, and the path selection is based on the
outbound route to the group supplied in the local endpoint.
Paragraph (version B):
UDP Multicast Receive Listeners will deliver new connections once
they have received traffic from a new Remote Endpoint.
Paragraph (version B):
Calling "Clone" on a UDP Multicast Receive Connection creates a
new Connection with equivalent parameters.  The two Connections
are otherwise independent.
Paragraph (version B):
SEND.UDP(-Lite).  Calling "Send" on a UDP Multicast Receive
connection causes an immediate SendError.  This is an unsupported
operation.
Paragraph (version B):
RECEIVE.UDP(-Lite).  The Receive operation in a UDP Multicast
Receive connection only delivers complete Messages to "Received",
each of which represents a single datagram received in a UDP
packet.  Upon receiving a UDP datagram, the ECN flag from the IP
header can be obtained (GET_ECN.UDP(-Lite)).
Paragraph (version B):
Calling "Close" on a UDP Multicast Receive Connection (ABORT.UDP(-
Lite)) releases the local port reservation and leaves the group.
Paragraph (version B):
Calling "Abort" on a UDP Multicast Receive Connection (ABORT.UDP(-
Lite)) is identical to calling "Close".