Allow for federate type instead of federate name in deployment element

[bergtwvd]

Currently the Deployment element in NETN-ORG-ComplexTypes.xsd uses the name of the federate. This is however too rigid. A federate name is federation specific, and we want to be able to use MSDL data between federations. Also, a federate - when it joins - is not required to specify a name. In that case the RTI will generate a name. So, federate names are not necessarily known in advance.

A better approach is to use the federate type. A federate - when it joins - is required to provide a federate type name. So, a type name is guaranteed to be present. A type name provides more flexibility in the allocation of units/equipment to federates by e.g. an ORBAT server. Any federate of a given type name can be allocated the modeling responsibility of equipment. E.g. there could be two federates of type Platform Generation Service, one named federate A, the other federate B. An ORBAT Server can allocate the modeling of en equipment item to either A or B, based on simple load-balancing rules.

This solution is compatible with the existing approach of federate name, when we require the type name to be unique for each joining federate.

Proposal: change

1025: <xs:element name="Federate">

to

1025: <xs:element name="FederateType">

[lofstrandbjorn]

The ability to reference a specific federate/model by a unique name is important. Federate type is not unique but I can see that allocation to Any model of a specific type might make sense in some cases. I recommend to push this comment to Ed C and re-address in context of generalization, load-balancing, etc.

[bergtwvd]

When we want to scale out federates (of the same type) this addition makes sense. We want to be able to allocate a unit to any federate of this type.

HLA Evolved already has the notion of federate type in the join call, although intended to be used in the save/restore service calls:

The federate type argument shall distinguish federate categories for federation save-and-restore purposes. Declaring a federate to be of a given type shall be equivalent to asserting that the joined federate can be restored using the state information saved by
any other joined federate of that type.

This concept seamlessly fits into this change request. The way the MSG-163/MSDL schema works now is really just a special case of this. I.e. for each federate type there is at most one federate. With this change request we generalize this and allow more than one federate for each type.

The change can be made explicit via a schema change (as proposed above). Or per agreement indicate that the federate name value must be interpreted as federate type value. That is, a note with the MSDL file if federate name values are to be interpreted as federate type values.

[lofstrandbjorn]

So if I have two federates of the same type in the federation (e.g. 15 "CGF" types, "10 VR-Forces" and "5 MASA SWORD") and I want to simulate 1000 entities of which 100 specific entities will be allocated to a MASA Sword running in Brazil and the rest I do not care where they run. How will this work??? I would much rather allocate 100 to a specific named MASA SWORD perhaps 500 to "VR-Forces Load Balancer 1 Federate" and the rest to a "MASA SWORD Load Balancer Federate". The Load Balancer Federate will take care of any required load balancing. E.g. change the allocation attribute to VRF1, VRF2 etc. or start new instances of VRF and provide allocation to new named instances. If we only use the federate type how will it work?

[bergtwvd]

If you want to allocate 100 entities to a specific federate then you need to use a specific federate type name for that federate. E.g. for the federate named MASA-1 in Brasil use the type name MASA SWORD BRASIL. The other MASA Sword instances are typed as MASA SWORD.

The MSDL files uses federate type names. An ORBAT Server will process the MSDL file and allocate 100 entities to the federate typed MASA SWORD BRASIL and 900 to the other federates that are typed MASA SWORD.

If you want to keep the current mechanism of allocation, then every federate has a unique type name. That type name is used in the MSDL file. As type name you can use the federate name actually, and maybe postfix it with the name Type to emphasize that it is a type name.

A ORBAT Server could make use of other information to distribute entities across federates, but it becomes more infrastructure aware in that case. E.g. specific labels that are attached to a federate, CPU/memory capacity available at the federate, other federates that are already executing on that node.

This change request is just a schema change, not a NETN-ORG change.

[lofstrandbjorn]

So in MSDL if you specify that Federate Named A shall be allocated Entities 1...100 and Federate Named B shall be allocated Entities 101...200. The ORBAT server may know (by configuration) that Federate Named B is enabled for load-balancing. It starts up or selects existing federates of the same (or some compatible) type as Federate Named B and allocate some of the entities allocated to Federate Named B in the MSDL to these other federates by publishing NETN-ORG allocation.

[bergtwvd]

In this example there is additional configuration data (not in MSDL), basically to inform the ORBAT Server that federate B is of type FederateTypeB and entities may be allocated to any of these. The idea is however to use the federatetype in the existing MDSL, while keeping backward compatibility. The current use of the MSDL file w.r.t. the depoyment is just a special case of the proposed change.

[lofstrandbjorn]

So the proposal is to add federate type in MSDL deployment? Semantics: No FederateName or FederateType = No initial allocation of modelling responsibilities Only FederateName = Allocation to specific federate Only FederateType = Allow some service to perform allocation to specific federate based on FederateType Both FederateName and FederateType = Allocation to specific federate (same as only name). ???

[LennartOlsson]

Do not change a very well working deployment method.

There must be a way for a load-balancing ORBAT Server to do the task with combinations of federation design, configuration file, subscribing to HLAfederat and user input and then assign entities to federates with respect to the federate name.

I do not know of any serious federate that are not able to change the federate name before joining a federation execution.

I do not remember that we ever have discussed using HLA Save/Restore in a NETN federation, so I do not think we need to consider any aspects of that.

[bergtwvd]

I think we make it more complicated than needed. The change is about semantics. There is no FOM change, and there needs to be no schema change either. We just provide the option (in the documentation ) to interpret the federate name in the MSDL file as federate type (by an ORBAT Server ), to allow load-balancing for instance. When following this approach the only requirement (make it a federation agreement if you will) for the federate is to use the federate type name from the MSDL file....

[lofstrandbjorn]

Potentially Solved by #42

[lofstrandbjorn]

Change semantics of ORG_Root attribute Name to:

"Required. A unique name in the federation used to reference units, equipment items or forces. For the initial allocation of modelling responsibilities, the name is used to determine if a FederateApplication object provides allocation information to a specific federate, normally by matching Federate Name but a federation Agreement may specify that some or all federate match in a different way, e.g. Federate type."

[bergtwvd]

Slightly reworded proposal, but the idea is the same:

"Required. A unique name in the organization to group units and equipment items. This group name is used to determine the initial allocation of modelling responsibility of units and equipment items to a federate. The federation agreements should specify how this name is to be interpreted and how the allocation will be performed. A common agreement and practice is to use the federate name as group name, i.e. the units and equipment items are allocated to the federate with that name. Typically one application will be responsible for performing the allocation. Alternatives for the group name are for example: federate type name, a functional name."

[lofstrandbjorn]

ok

[bergtwvd]

We should devote a section on this topic in the ORG documentation page.

[lofstrandbjorn]

We should devote a section on this topic in the ORG documentation page.

Will do.