| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Pat, A one-to-many relationship already implies there are many instances of MAC associated with a single MAC Merge instance. We do not need to show them explicitly, since there is nothing different about these MAC, less their designation for express and preemptable (or whatever we chose to name them). Otherwise, we will have to start showing separate diagrams for each combination of optional features we include in devices. Marek From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx] Here is another alternative for the relationship diagram (the alternative is the second page in the file. I like this one better, but I don’t know if it is allowed. What I’ve done is contain a second oMACEntity for the pMAC in the oMACEntity for the eMAC. (The decision of which to make the primary containing one was arbitrary so I honored Hugh’s preference that the Express side be considered the “normal” MAC and the premptable MAC be considered the additional MAC.) It gets rid of the problem of having both oMAC own the oPHYEntity and having oResourceIDs. If it is allowable to have one oMACEntity containg another, I’d prefer this alternative. Comments? Regards, Pat From: Pat Thaler Here is my initial try on a relationship diagram for MAC Merge. I haven’t done one of these before. For now this is a diagram that applies only when MAC Merge is present. If adding MAC Merge to Figure 30-3 is done similar to this diagram, then I think this could be merged into Figure 30-3 in a way similar to what was done with MAC Control. I.e. Add a one to many relationship between oMACEntity back and oPHYEntity in and in the description of oPHYEntity state that it is contained in oMACMerge when oMACMerge is present and otherwise it is contained in oMACEntity. I also considered having oPHYEntity always contained by oMACEntity as it currently is, but then which MACEntity of a MACMerge sublayer own it. We don’t have any many to many or two to many relationships defined. Also, this is more similar to the way MAC Control was added. I have a number of questions about this drawing: There are a number of questions about this diagram: Should the deprecated objects be removed since it is a new diagram? Should a new symbol be added to indicate a two to one relationship instead of using the many to one relationship? Should this relationship be shown in some other way?] Should oResourceTypeID stay where it is or should it be contained by oMACMergeEntity? If it stays where it is, there may be one for the eMAC and one for the pMAC. Note that oResourceTypeID is specified in 802.1F, a withdrawn standard. Because of that, I lean toward leaving it where it is. |