Issue 10799: Unreliable Multicast issue (umcast-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: I have a few questions after reviewing the MIOP specification. The MIOP specification addresses issues that occur when using an unreliable transport, in particular UDP. The MIOP header that wraps GIOP request fragments is useful for packet reassembly. What I don’t understand is why this technique is limited to multicast addressing, when it would be equally useful with unicast addressing when using UDP, subject to the same constraints (GIOP requests with no response expected -- oneway operations only). There are circumstances when <<signals>> (oneway requests) directed to a specific endpoint (interface realization) may be desirable instead of to a group; when in fact the designer wishes to preclude multicast. Section 29.14 limits the address range to Class D IP addresses, is it possible to permit unicast addresses in the spec. It appears to me that the problem should be handled in 2 steps: First, handle the issues regarding GIOP over unreliable transports Limit transmissions to GIOP request messages with no replies Provide mechanism to handle fragments The preceding issue is done with the extra encapsulation (MIOP header) Second, handle the issues regarding network addressing unicast multicast There is a difference between the transport and network layers in the ISO/OSI communication model for a reason. Maintaining this distinction allows a more robust use of the transport by permitting its use with more than one network addressing mode. Resolution: Revised Text: Actions taken: February 27, 2007: received issue Discussion: End of Annotations:===== te: Tue, 27 Feb 2007 15:56:22 -0700 From: "Wesolowski, Charles" Subject: FW: MIOP Specification To: issues@omg.org Thread-Topic: MIOP Specification Thread-Index: AcdavCh3GxC0w5UzT3ChovmZYdyyEAABjDyA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 27 Feb 2007 22:56:21.0834 (UTC) FILETIME=[7FD79AA0:01C75AC2] X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Hello, I am forwarding the following issue regarding MIOP to this email address per the request of Char Wales, MITRE Please see original below. Thanks, --Chuck -------------------------------------------------------------------------------- From: Char Wales [mailto:charwing@mitre.org] Sent: Tuesday, February 27, 2007 4:11 PM To: Wesolowski, Charles Cc: Calloni, Ben A Subject: Re: MIOP Specification have you submitted these issues to the OMG issues database for disposition? I just checked if there are any active issues for Unreliable Multicast (MIOP) and it looks like there are a few that have banging around for a few years and not formally closed (http://www.omg.org/issues/umcast-ftf.open.html). But no FTF or RTF is active to handle them, though. In any case, while this is not a "bug" per se, it IS a clarification or a request for another way to interpret the existing spec. Suggest that you resubmit this email to issues@omg.org and follow up with Juergen Boldt to see what happened to it afterwards (juergen@omg.org). Regards, Char Wales (MITRE and also MARS co-chair) Wesolowski, Charles wrote: Hello, I have a few questions after reviewing the MIOP specification. The MIOP specification addresses issues that occur when using an unreliable transport, in particular UDP. The MIOP header that wraps GIOP request fragments is useful for packet reassembly. What I don.t understand is why this technique is limited to multicast addressing, when it would be equally useful with unicast addressing when using UDP, subject to the same constraints (GIOP requests with no response expected -- oneway operations only). There are circumstances when <> (oneway requests) directed to a specific endpoint (interface realization) may be desirable instead of to a group; when in fact the designer wishes to preclude multicast. Section 29.14 limits the address range to Class D IP addresses, is it possible to permit unicast addresses in the spec. It appears to me that the problem should be handled in 2 steps: First, handle the issues regarding GIOP over unreliable transports Limit transmissions to GIOP request messages with no replies Provide mechanism to handle fragments The preceding issue is done with the extra encapsulation (MIOP header) Second, handle the issues regarding network addressing unicast multicast There is a difference between the transport and network layers in the ISO/OSI communication model for a reason. Maintaining this distinction allows a more robust use of the transport by permitting its use with more than one network addressing mode. Sincerely, Chuck Wesolowski, OCUP, OCRES MEADS BMC4I Software System Lead Lockheed Martin Space Systems Company Huntsville, AL 35858 256.722.4165 -- Charlotte W. Wales Lead Information Systems Engineer The MITRE Corporation/Army Enterprise Systems http://www.mitre.org Mailing Address: 7525 Colshire Drive, MS H120 McLean, VA 22102 Ph: 703-983-7024 || Fax: 703-983-6143 || Email: charwing@mitre.org NB: As of 15 Apr 05, exchange was changed from 883 to 983