Imagine an object in a running program. [Yes, I know this is not a node in your model, but the paradigm might be easier for illustration.]
This object is an instance of a class. At run time the object instance will have (some or all of) its parameters set to specific values, which would be specific to the instance.
For example, let's say that each object of this class has an ID field that tells them apart (perhaps the ID is the database key of the record where object data is persisted). The class itself simply as an ID field with a data type (let's say Integer). Each instance of the class (each object of that class type) would have its own value for that attribute. So I might have an object with ID=1, another with ID=2, and so on.
Now in model some classes might have associated tagged values. These tell us something about the class, beyond the 'basic' characteristics defined across UML. Every instance of this class shares the 'tagged' characteristic. However, the values of the tag - or even the tag itself - are not accessible to the running instance. For example, these values might provide instructions to a code generator; by the time the source code is produced the tagged values have been 'consumed' and have done their work. Or perhaps they represent some characteristic that will be 'built in' for each instance of that class. The point is that the tagged value sets one class, and all its instances, apart from another class and its instances.
Now that you've got the flavor of the two things, let's proceed.
You might have several nodes in your model. Many of them might be of the «server» type, with general characteristics as appropriate. Some of these will fall into specific groups based on common characteristics, but at a lower level than the stereotype indicates. The different lower level categories would be difficult to explain using 'basic' UML, since they could be based on values that are specific to your organization or project, and might even be relevant only to a given viewpoint. You might use tagged values to differentiate them.
However, by the time you get to a detailed deployment model you need to tell the reader which is which, and perhaps give 'hard' specifications. That's where run state generally comes in. For each specific instance of a «server» of a given category (with a specific tagged value setting) you could have property settings that provided the instance-specific values required. These might be something like server address or URI. These would be common attributes but would have different run time values for each actual (instance of) server. There's your run state.
Hopefully you can extract some meaning out of the above mass of verbiage...
David
