Conference azur::mcc

Peretz,

Ask a simple question and **look*** what it leads too.

I'm going to appologize up front for the length of my answer. It spans the next
three replies, two longish text files and a postscript diagram. The example
you posed was interesting enough that I started a real entity design excercise,
and I kept running into lots and lots of points of general interest that I
could explore. So there's lots of stuff below, perhaps not directly answering
your question, but providing a general lesson that everyone might learn from.

						Mark

Well, the first thing is for you to read the paper I wrote on how to design an
entity. You can find the original in 

	FILES::EMA$:[Public]ENTITY_ARCH_GUIDELINES.PS

That's been partially expanded in the EMA Folklore document (in the same
directory), and used in the MCC AM design course.

Now that you've read the paper, lets apply it to the SS7/SP entities you've
got.

The second step (after requirements gathering) is to construct an E-R design of
the "information" in your picture. I'd have at least the following in that
design.

    SP (the box)
    ST (the little box on the left)
    IF (little box on right)
    IF-Line (each IF has 2 of these going through it in your picture)
    Link (just the word in your picture)
    Linkset (a collection of Links)

Now at this point, these are just words. They haven't been defined, nor is
there any information (data, attributes, etc) associated with them. Nor do I
know how one word relates to another. I read the text below, & I get some idea,
but probably not enough to know for sure. From that text, and educated guesses,
I'll guess the following.

    SP = Signalling Point, An "end point" in the SS7 network. Probably a
    bunch of hardware, probably a control processor, probally all located in
    one place. There are probably SS7 "signalling trunks" coming into that
    place that are probably hooked into the SP. An SP is not a transit switch
    (switching data received over one signalling trunk out another).

    ST = Signalling Terminals, I'm not sure what this is. My guess is that this
    is a device that can receive and generate "signals". Much like a DTMF
    receiver can receive touch tone phone signals and send signals like dial
    tone to a telphone set. You say an ST can be inside a SP (i.e. there's a
    relationship between them). Some questions...

        What does it mean for an ST to be "inside" an SP, does it mean that the
        ST is in one of the racks of hardware that make up an SP? 

        If an SP has a processor, does being "inside" mean that the SP's
        processor tells the ST what signals to send?

        How many SPs can an ST be "inside"? Exactly one?

    IF = Interface, I assume that represents an "interface card", a piece of
    hardware. Like an ST, it can be inside an SP. So we have to answer all the
    questions about what "inside" means we raised for ST.

    IF-Line = Interface Line, You show two lines inside an IF. I presume that
    means that an IF card really supports more than one "signalling channel"
    (an interesting side question is how many signalling channels fit one a
    signalling trunk,...). I guess that each IF-Line is in exactly one IF, and
    an IF has in it some number (is it fixed?) of IF-Lines.

    There's a cross connect between ST and IF (that appears to match up with an
    IF-Line) That implies a "cross-connected" relationship between them. I'll
    guess from that each IF-Line is "cross-connected" to exactly one ST, but an
    ST is "cross-connected" to 1..N IF-Lines.

    There's a line emerging from the SP to the right (actually each line seems
    tied to an IF-Line). I think that line represents what I'd called above a
    "signalling channel". The picture doesn't clearly indicate what's on the
    other end of the signalling channel, it implies a Link is on the other
    side, but the text below says there's "eventually" another SP (or to be
    precise an IF-Line in that SP) on the other end. I think this is a 1-1
    relationship between two IF-Lines. I.e. each IF-Line has exactly one other
    IF-Line "at the other end" of the signalling channel it's hooked to. This
    is probably one of those "relationship entities" because there's probably
    data associated with the signalling channel (like a channel number, or the
    trunk it is carried over...).

    Now the Link entity is somewhat problematic. You will note that the
    information I need to understand the configuration of an SS7 network of SPs
    is completely described by the information above. This is true because I've
    described *all* the hardware (at a component level) and *all* their
    interconnections. However, it is often useful to be able to talk about the
    "end to end" connection/path from one ST to another. I.e. the connection
    from
    	ST cross-connect IF-Line signalling-channel IF-Line cross-connect ST

    Now is that bidirectional, end to end, connection what you meant by a
    "Link"? Or do you mean that a Link is one half the connection (from ST out
    to somewhere in the middle of the signalling-channel)? Or perhaps you meant
    that a Link was a uni-directional signalling path from ST to ST?

    I'll guess that a Link is the whole thing (but just to make sure I'll also
    talk about a "half-Link" which ends somewhere in the middle). Each link is
    related to exactly 2 IF-Lines, 2 STs and 1 signalling channel. On the other
    hand, each IF-Line and each signalling channel is related to exactly one
    Link, and an ST can be related to 1..N Links. For half-links, each
    half-link is related to exactly 1 IF-Line, 1 ST and 1 signalling channel,
    and an IF-Line is related to 1 half-link. But a signalling channel is
    related to 2 half-links, and a ST is related to 1..N half-links.

    Now there's a lot of redundant data in this description, and a lot of rules
    on legal values and relationships between these entities. For example, if a
    ST is cross-connected to a IF-Line, then the ST and the IF that the IF-Line
    is in must be in the same SP. (you can't cross connect to a device in some
    other SP). Similarly, the ST and IF-Line that make up a half-link must be
    cross-connected, and if an ST and IF-Line are cross-connected, then there
    is one (and only one) half-link made out of them. Essentially, there are a
    lot of facts that can be deduced by following chains of relationships
    according to the rules of what's legal ande what can be deduced from a
    chain. The E-R model can be simplified by eliminating the redundant data,
    more on that later.

    And finally, a Linkset. The definition is a group of links, all going to
    the same SP. Now since a Link (as I defined it) hooks 2 SPs together (the 
    chain here is that a Link is made up of 2 IF-Lines, each of which is in
    1 IF which in turn is in 1 SP), it's not quite clear what "going to the
    same SP" means. Applying a little formal logic helps clarify. Lets define a
    Linkset between two SPs (SP-A and SP-B) is the set of all links that hook
    together SP-A and SP-B. Note that the Linkset between SP-A and SP-B is the
    same as the Linkset between SP-B and SP-A. Also note that saying it is
    *all* opf the links, rather than *some* of the links makes it unique.

    A Half-link-set can be defined similarly. Since each half-link is "in" one
    SP (because the ST and IF-Line that make up the halflink must be in the
    same SP). Each half-link has an SP at "the other end" of it's signalling
    channel. Thus we define the Half-Link-Set to SP-B as the set of all the
    half-links in SP-A that have SP-B at their "other end".

    Now we can take all that information and draw an E-R diagram that
    represents the relationships and entities we've defined so far. Drawing E-R
    diagrams in text is no fun, so I'll draw that up in DECwrite and post the
    postscript of the diagram in the next note.

    The story picks up (and hopefully finally answers your question) in the
    note after that.

    				Mark

%!PS-Adobe-2.1
%%Creator: DECwrite V1.1
%%+Copyright (c) 1990 DIGITAL EQUIPMENT CORPORATION.  
%%+All Rights Reserved.
%%DocumentFonts: (atend)
%%EndComments
%%BeginProcSet DEC_WRITE 1.06
/DEC_WRITE_dict 150 dict def DEC_WRITE_dict begin/$D save def/$I 0 def/$S 0
def/$C matrix def/$R matrix def/$L matrix def/$E matrix def/pat1{/px exch
def/pa 8 array def 0 1 7{/py exch def/pw 4 string def 0 1 3{pw exch px py 1
getinterval putinterval}for pa py pw put}for}def/pat2{/pi exch def/cflag
exch def save cflag 1 eq{eoclip}{clip}ifelse newpath{clippath
pathbbox}stopped not{/ph exch def/pw exch def/py exch def/px exch def/px px
3072 div floor 3072 mul def/py py 3072 div floor 3072 mul def px py
translate/pw pw px sub 3072 div floor 1 add cvi def/ph ph py sub 3072 div
floor 1 add cvi def pw 3072 mul ph 3072 mul scale/pw pw 32 mul def/ph ph 32
mul def/px 0 def/py 0 def pw ph pi[pw 0 0 ph 0 0]{pa py get/px px 32 add
def px pw ge{/px 0 def/py py 1 add 8 mod def}if}pi type/booleantype
eq{imagemask}{image}ifelse}if restore}def/PS{/_op exch def/_np 8 string def
0 1 7{/_ii exch def/num _op _ii get def _np 7 _ii sub num -4 bitshift PX
num 15 and 4 bitshift -4 bitshift PX 4 bitshift or put}for _np}def/PX{[15 7
11 3 13 5 9 1 14 6 10 2 12 4 8 0]exch get}def/FR{0.7200 0 $E defaultmatrix
dtransform/yres exch def/xres exch def xres dup mul yres dup mul add
sqrt}def/SU{/_sf exch def/_sa exch def/_cs exch def/_mm $C currentmatrix
def/rm _sa $R rotate def/sm _cs dup $L scale def sm rm _mm _mm concatmatrix
_mm concatmatrix pop 1 0 _mm dtransform/y1 exch def/x1 exch def/_vl x1 dup
mul y1 dup mul add sqrt def/_fq FR _vl div def/_na y1 x1 atan def _mm 2 get
_mm 1 get mul _mm 0 get _mm 3 get mul sub 0 gt{{neg}/_sf load
concatprocs/_sf exch def}if _fq _na/_sf load setscreen}def/BO{/_yb exch
def/_xb exch def/_bv _bs _yb _bw mul _xb 8 idiv add get def/_mk 1 7 _xb 8
mod sub bitshift def _bv _mk and 0 ne $I 1 eq xor}def/BF{DEC_WRITE_dict
begin/_yy exch def/_xx exch def/_xi _xx 1 add 2 div _bp mul cvi def/_yi _yy
1 add 2 div _bp mul cvi def _xi _yi BO{/_nb _nb 1 add def 1}{/_fb _fb 1 add
def 0}ifelse end}def/setpattern{/_cz exch def/_bw exch def/_bp exch def/_bs
exch PS def/_nb 0 def/_fb 0 def _cz 0/BF load SU{}settransfer _fb _fb _nb
add div setgray/$S 1 def}def/invertpattern{$S 0 eq{{1 exch
sub}currenttransfer concatprocs settransfer}if}def/invertscreen{/$I 1
def/$S 0 def}def/revertscreen{/$I 0 def}def/setrect{/$h exch def/$w exch
def/$y exch def/$x exch def newpath $x $y moveto $w $x add $y lineto $w $x
add $h $y add lineto $x $h $y add lineto closepath}def/concatprocs{/_p2
exch cvlit def/_p1 exch cvlit def/_pn _p1 length _p2 length add array def
_pn 0 _p1 putinterval _pn _p1 length _p2 putinterval _pn
cvx}def/OF/findfont load def/findfont{dup DEC_WRITE_dict exch
known{DEC_WRITE_dict exch get}if DEC_WRITE_dict/OF get exec}def
mark/ISOLatin1Encoding 
8#000 1 8#001{StandardEncoding exch get}for /emdash/endash
8#004 1 8#025{StandardEncoding exch get}for /quotedblleft/quotedblright
8#030 1 8#054{StandardEncoding exch get}for /minus 8#056 1 8#217
{StandardEncoding exch get}for/dotlessi 8#301 1 8#317{StandardEncoding 
exch get}for/space/exclamdown/cent/sterling/currency/yen/brokenbar/section
/dieresis/copyright/ordfeminine/guillemotleft/logicalnot/hyphen/registered
/macron/degree/plusminus/twosuperior/threesuperior/acute/mu/paragraph
/periodcentered/cedilla/onesuperior/ordmasculine/guillemotright/onequarter
/onehalf/threequarters/questiondown/Agrave/Aacute/Acircumflex/Atilde
/Adieresis/Aring/AE/Ccedilla/Egrave/Eacute/Ecircumflex/Edieresis/Igrave
/Iacute/Icircumflex/Idieresis/Eth/Ntilde/Ograve/Oacute/Ocircumflex/Otilde
/Odieresis/multiply/Oslash/Ugrave/Uacute/Ucircumflex/Udieresis/Yacute/Thorn
/germandbls/agrave/aacute/acircumflex/atilde/adieresis/aring/ae/ccedilla
/egrave/eacute/ecircumflex/edieresis/igrave/iacute/icircumflex/idieresis
/eth/ntilde/ograve/oacute/ocircumflex/otilde/odieresis/divide/oslash/ugrave
/uacute/ucircumflex/udieresis/yacute/thorn/ydieresis
256 array astore def cleartomark 
/encodefont{findfont dup maxlength dict begin{1 index/FID ne{def}{pop
pop}ifelse}forall/Encoding exch def dup/FontName exch def currentdict
definefont end}def/loads{/$/ISOLatin1Encoding load def/&/encodefont load
def/*/invertpattern load def/+/revertscreen load def/-/invertscreen load
def/:/concatprocs load def/^/setpattern load def/~/pat1 load def/_/pat2
load def/@/setrect load def/A/arcn load def/B/ashow load def/C/curveto load
def/D/def load def/E/eofill load def/F/findfont load def/G/setgray load
def/H/closepath load def/I/clip load def/K/kshow load def/L/lineto load
def/M/moveto load def/N/newpath load def/O/rotate load def/P/pop load
def/R/grestore load def/S/gsave load def/T/translate load def/U/sub load
def/V/div load def/W/widthshow load def/X/exch load def/Y/awidthshow load
def/a/save load def/c/setlinecap load def/d/setdash load def/e/restore load
def/f/setfont load def/g/initclip load def/h/show load def/i/setmiterlimit
load def/j/setlinejoin load def/k/stroke load def/l/rlineto load
def/m/rmoveto load def/n/currentfont load def/o/scalefont load
def/p/currentpoint load def/r/currenttransfer load def/s/scale load
def/t/setmatrix load def/u/settransfer load def/w/setlinewidth load
def/x/matrix load def/y/currentmatrix load def}def
end
%%EndProcSet
%%EndProlog

%%BeginSetup
DEC_WRITE_dict begin
loads
version cvi 23.0 gt {
currentdict {dup type /arraytype eq
{bind def} {pop pop} ifelse} forall} if
0.0100 0.0100 s

%%EndSetup
%%Page: 1 1
/$P a D
g N
90 O
S
R
S
7200 -899 T
N
0 G
300 -1200 M
300 -55839 M
-7200 899 T
S
N
S
6300 -55800 66600 53201 @ I N
6300 -2599 T
N
S
29699 -14200 T
N
0 G
2706 -1050 M
/Helvetica-ISOLatin1 $
/Helvetica & P
/Helvetica-ISOLatin1 F 1000 o f
(IF) h
300 -2446 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-29699 14200 T
R

S
11699 -24999 T
N
0 G
2511 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(ST) h
300 -2446 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-11699 24999 T
R

S
29900 -25300 T
N
0 G
2706 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(IF) h
2205 -2250 M
(Line) h
300 -3646 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-29900 25300 T
R

S
20700 -25764 T
N
0 G
1955 -1050 M
/Helvetica-Oblique-ISOLatin1 $
/Helvetica-Oblique & P
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(cross) h
1399 -2250 M
(connect) h
-20700 25764 T
R


S
N
23850.00 -24998.00 M
20700.00 -26798.00 L
23850.00 -28598.00 L
27000.00 -26798.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
15300 -23581 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-15300 23581 T
R

S
33049 -17800 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-33049 17800 T
R

S
23400 -9470 T
N
0 G
2761 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(in) h
300 -2446 M
-23400 9470 T
R


S
N
26550.00 -8800.00 M
23400.00 -10600.00 L
26550.00 -12400.00 L
29700.00 -10600.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
17999 -25380 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-17999 25380 T
R

S
33300 -24100 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-33300 24100 T
R

S
13500 -6100 T
N
0 G
2483 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(SP) h
300 -2446 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-13500 6100 T
R

S
N
19800.00 -8800.00 M
23400.00 -10600.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
19799 -8282 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-19799 8282 T
R

S
N
27000.00 -12400.00 M
30600.00 -14200.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
27000 -25380 T
N
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
-27000 25380 T
R

S
12600 -15770 T
N
0 G
3211 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(in) h
300 -2446 M
-12600 15770 T
R


S
N
16200.00 -15100.00 M
12600.00 -16900.00 L
16200.00 -18700.00 L
19800.00 -16900.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
33300.00 -17800.00 M
33300.00 -19600.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
33300.00 -23200.00 M
33300.00 -25301.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
18000.00 -26800.00 M
20700.00 -26800.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
27000.00 -26800.00 M
29700.00 -26800.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
17100 -10082 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-17100 10082 T
R

S
29699 -12400 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-29699 12400 T
R

S
29700 -20270 T
N
0 G
3211 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(in) h
300 -2446 M
-29700 20270 T
R


S
N
33300.00 -19600.00 M
29700.00 -21400.00 L
33300.00 -23200.00 L
36900.00 -21400.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
17100.00 -9700.00 M
16200.00 -15100.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
16200.00 -18700.00 M
15300.00 -25000.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
48599 -25318 T
N
0 G
1544 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Signaling) h
1738 -2250 M
(Channel) h
300 -3646 M
S
0 -3601 7201 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-48599 25318 T
R

S
39399 -25764 T
N
0 G
1232 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(attached) h
300 -2446 M
-39399 25764 T
R


S
N
42549.00 -24998.00 M
39399.00 -26798.00 L
42549.00 -28598.00 L
45699.00 -26798.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
36698 -25380 T
N
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
-36698 25380 T
R

S
51999 -24100 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1..n) h
S
0 -1419 2701 1419 @
R
-51999 24100 T
R

S
45699 -25380 T
N
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
-45699 25380 T
R

S
N
36699.00 -26800.00 M
39399.00 -26800.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
45699.00 -26800.00 M
48399.00 -26800.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
48599 -14200 T
N
0 G
1433 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Signalling) h
2322 -2250 M
(Trunk) h
300 -3646 M
S
0 -3601 7201 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-48599 14200 T
R

S
51949 -17800 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-51949 17800 T
R

S
N
52200.00 -17800.00 M
52200.00 -19600.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
52200.00 -23200.00 M
52200.00 -25301.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
48600 -20270 T
N
0 G
2100 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(carries) h
300 -2446 M
-48600 20270 T
R


S
N
52200.00 -19600.00 M
48600.00 -21400.00 L
52200.00 -23200.00 L
55800.00 -21400.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
12600 -43900 T
N
0 G
2261 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Half) h
2233 -2250 M
(Link) h
300 -3646 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-12600 43900 T
R

S
48599 -43901 T
N
0 G
2233 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Link) h
300 -2446 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-48599 43901 T
R

S
30199 -44667 T
N
0 G
1677 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(makes) h
2594 -2250 M
(up) h
-30199 44667 T
R


S
N
33349.00 -43901.00 M
30199.00 -45701.00 L
33349.00 -47501.00 L
36499.00 -45701.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
18900 -44282 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
S
0 -1419 2701 1419 @
R
-18900 44282 T
R

S
45900 -44282 T
N
S
0 -1419 2700 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2700 1419 @
R
-45900 44282 T
R

S
42299 -35066 T
N
0 G
1839 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2283 -2250 M
(of) h
-42299 35066 T
R


S
N
44999.00 -34300.00 M
42299.00 -36100.00 L
44999.00 -37901.00 L
47700.00 -36100.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
49499 -35066 T
N
0 G
1839 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2283 -2250 M
(of) h
-49499 35066 T
R


S
N
52199.00 -34300.00 M
49499.00 -36100.00 L
52199.00 -37901.00 L
54900.00 -36100.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
35100 -35066 T
N
0 G
1839 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2283 -2250 M
(of) h
-35100 35066 T
R


S
N
37800.00 -34300.00 M
35100.00 -36099.00 L
37800.00 -37901.00 L
40501.00 -36099.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
52200.00 -34301.00 M
52200.00 -28900.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
52200.00 -37900.00 M
53100.00 -43901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
45000.00 -34301.00 M
35099.00 -28900.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
37800.00 -34301.00 M
17100.00 -28601.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
16738 -34767 T
N
0 G
2288 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2733 -2250 M
(of) h
-16738 34767 T
R


S
N
19888.00 -34001.00 M
16738.00 -35801.00 L
19888.00 -37601.00 L
23038.00 -35801.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
24059 -34767 T
N
0 G
2288 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2733 -2250 M
(of) h
-24059 34767 T
R


S
N
27209.00 -34001.00 M
24059.00 -35801.00 L
27209.00 -37601.00 L
30359.00 -35801.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
10303 -34767 T
N
0 G
2328 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(part) h
2773 -2250 M
(of) h
-10303 34767 T
R


S
N
13493.00 -34001.00 M
10303.00 -35801.00 L
13493.00 -37601.00 L
16683.00 -35801.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
18900.00 -45701.00 M
30600.00 -45701.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
36900.00 -45701.00 M
48600.00 -45701.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
13500.00 -34001.00 M
13500.00 -28601.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
19800.00 -34001.00 M
31500.00 -28900.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
27000.00 -34001.00 M
49500.00 -28900.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
44999.00 -37900.00 M
51300.00 -43901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
37799.00 -37900.00 M
48600.00 -44201.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
27000.00 -37601.00 M
18000.00 -43901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
19800.00 -37601.00 M
16200.00 -43901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
13500.00 -37601.00 M
13500.00 -43901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
13500 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-13500 28982 T
R

S
29699 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-29699 28982 T
R

S
46799 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-46799 28982 T
R

S
18900 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
S
0 -1419 2701 1419 @
R
-18900 28982 T
R

S
35999 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
S
0 -1419 2701 1419 @
R
-35999 28982 T
R

S
52199 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-52199 28982 T
R

S
43200 -40301 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1..n) h
S
0 -1419 2701 1419 @
R
-43200 40301 T
R

S
17099 -40682 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-17099 40682 T
R

S
20700 -41201 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
S
0 -1419 2701 1419 @
R
-20700 41201 T
R

S
13500 -40301 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1..n) h
S
0 -1419 2701 1419 @
R
-13500 40301 T
R

S
48600 -41582 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-48600 41582 T
R

S
52199 -41582 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-52199 41582 T
R

S
58499 -34767 T
N
0 G
1767 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(member) h
300 -2446 M
-58499 34767 T
R


S
N
62099.00 -34001.00 M
58499.00 -35801.00 L
62099.00 -37601.00 L
65700.00 -35801.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
59399 -25001 T
N
0 G
2233 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Link) h
2400 -2250 M
(Set) h
300 -3646 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-59399 25001 T
R

S
N
62100.00 -34001.00 M
62100.00 -28601.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
901 -34767 T
N
0 G
1316 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(member) h
300 -2446 M
-901 34767 T
R


S
N
4051.00 -34001.00 M
901.00 -35801.00 L
4051.00 -37601.00 L
7201.00 -35801.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
900 -25001 T
N
0 G
1205 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(Half Link) h
2400 -2250 M
(Set) h
300 -3646 M
S
0 -3601 6301 3601 @
S
100 w
0 c
0 j
2 i
0.00 G k
R
R
-900 25001 T
R

S
N
3601.00 -34001.00 M
3601.00 -28601.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
4500.00 -37601.00 M
12600.00 -44801.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
62100.00 -37900.00 M
54900.00 -44801.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
58499 -6867 T
N
0 G
2266 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(hooks) h
1766 -2250 M
(together) h
-58499 6867 T
R


S
N
62099.00 -6101.00 M
58499.00 -7901.00 L
62099.00 -9701.00 L
65700.00 -7901.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
62100.00 -9701.00 M
62100.00 -25001.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
58500.00 -8201.00 M
19799.00 -8201.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
5400 -15770 T
N
0 G
3211 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(in) h
300 -2446 M
-5400 15770 T
R


S
N
9000.00 -15100.00 M
5400.00 -16900.00 L
9000.00 -18700.00 L
12600.00 -16900.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
0 -9471 T
N
0 G
2460 -1050 M
/Helvetica-Oblique-ISOLatin1 F 1000 o f
(other) h
2766 -2250 M
(end) h
0 9471 T
R


S
N
3599.00 -8801.00 M
0.00 -10601.00 L
3599.00 -12401.00 L
7200.00 -10601.00 L
H
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
9000.00 -15101.00 M
13500.00 -9701.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
7200.00 -10601.00 M
13500.00 -7901.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
3600.00 -12401.00 M
3600.00 -25001.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
N
9000.00 -18701.00 M
6300.00 -25001.00 L
S
100 w
0 c
0 j
2 i
0.00 G k
R
R

S
11700 -10082 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-11700 10082 T
R

S
10800 -7001 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-10800 7001 T
R

S
6300 -23582 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-6300 23582 T
R

S
900 -23582 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-900 23582 T
R

S
54899 -43901 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-54899 43901 T
R

S
9899 -44282 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-9899 44282 T
R

S
3600 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-3600 28982 T
R

S
62099 -28982 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(1) h
S
0 -1419 2701 1419 @
R
-62099 28982 T
R

S
19799 -6101 T
N
S
0 -1419 2701 1419 @
R
0 G
1072 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(2) h
S
0 -1419 2701 1419 @
R
-19799 6101 T
R

S
62100 -23582 T
N
S
0 -1419 2701 1419 @
R
0 G
516 -1050 M
/Helvetica-ISOLatin1 F 1000 o f
(0..n) h
S
0 -1419 2701 1419 @
R
-62100 23582 T
R

R


R
R

showpage
$P e

$D restore
%%Trailer
end % DEC_WRITE_dict
%%Pages: 1
%%DocumentFonts: Helvetica-ISOLatin1
%%+ Helvetica-Oblique-ISOLatin1

    Now at this point, I should associate any data (attributes) with these
    entities that are needed. I have no idea what attributes these might have,
    you ought to think about that.

    Once that's done, we can now think about simplifying the picture. One thing
    to look for is pure 1-1 relationships. For example, between Half Link and
    IF Line. Often, we *can* force these two entities to be one. Whether we
    *should* depends on a number of factors.

    Sometimes, a 1-1 relationship means that the two concepts are really the
    same concept (you've just given an alias name to a single concept). If this
    is the case, by all means, merge the two entities.  I don't think that's
    the case here.

    Sometimes, it means that these two concepts are (by their very nature)
    logically equivalent, i.e. that whatever facts are true about one, are true
    about the other. Or that some of the information in one concept duplicates
    information in the other. If this were a relational database design issue,
    and we were building a third/fourth normal form database, I'd be force to
    merge the two entities or violate one of the normal forms. But we're not
    designing a database, and we are not forced to merge the entities.  In this
    example, we **know** that the IF Line and the Half Link are logically
    equivalent. That's because all the information stored in a half link can be
    derived from the information in the IF Line and the related ST and
    Signalling Channel entities.

    So why not merge the two? Sometimes the two entities are just different
    ways of looking at the same information. Because the Entity Model only
    supports one naming path for an entity, we might need to clone an entity to
    give the same thing two very different names. In this case, I think a Half
    Link serves a different function. It exists to gather together data from
    multiple entities, the ST, the IF Line and the Signalling Channel, and to
    present it as a single whole. Now we could do that by extending the IF Line
    entity, but in this case, I think that's not appropriate.

    Similarly, a Link is logically equivalent to a Signalling Channel entity.
    But its not the same concept.

    At this point, I ought to explore the dynamic nature of these entities. But
    I have no information worth talking about. I can only point to a few things
    worth discussing... How do the cross-connect relationship between ST and IF
    Line get established/torn down? How do IF Lines get attached to Signalling
    channels?

    So finally, I come to the question of choosing which relationships ought to
    be used as naming (i.e. containment) relationships.

    Clearly, SPs are not contained in anything larger (other than the
    enterprise or SS7 network as a whole). They thus serve as our first global
    entities. 

    The relationship that each ST is "in" an SP meets all the tests for a
    containment relationship (1-n, existance dependancy, there is an
    identifying attribute or could be). No other relationship for an ST meets
    that test. Besides, since an ST is a physical thing, a board, one generally 
    uses physical containment to determine the naming. It's just the natural
    thing to do. The identifier is probably something like a slot name or
    number.

    For an IF, the situation is similar. It is contained in an SP, and is
    probably named by a slot name or number.

    An IF Line is a bit harder to deal with. There are actually *5* candidate
    parent entities.

    1   It could be named relative to the IF it is "in". That follows the
        physical containment model closely. This is what I'd recommend. The
        identifier would be something like a "line number".

    2   It could be a child of the Signalling Channel it is "attached" to, each
        IF Line is "attached" to 1 Signalling Channel, so it matches the 1-N
        test, or does it? We have to look more closely at this relationship. Is
        it possible that an IF Line could exist in one of these SPs that isn't
        attached to a signalling channel? I would bet the answer is yes. If so,
        then an IF Line cannot be a child of a Signalling Channel, because it
        doesn't match the existance test, "detaching" the Signalling Channel
        from the IF Line doesn't delete the IF Line.

    3   It could be a child of the ST, it meets the 1-N test, but does it meet
        the existance test? Must an IF Line be cross connected with an ST? That
        depends on the cross connect technology. My bet is no. There's a second
        reason why an IF Line should probably not be a child of an ST...

            When faced with a choice of two parent entities, favor the parent
            with the more "stable" relationship.

        Presumably, the cross connects can change fairly dynamically, while the
        IF and IF Line is in never changes.

    4   It could be a child of a Link, it meets the 1-N test, but just like
        a Signalling Channel, an IF Line doesn't have to be part of a Link.

    5   It could be a child of the Half Link it is "part of". It meets the 1-N
        test (1-1 is a special case of 1-N). Does it meet the existance test?
        This is harder to tell because it depends on those rules on the
        "logical equivalence" of a IF Line and a Half Link. My guess is that
        you don't have a Half Link unless the IF Line is "attached" to a
        signalling channel and "cross connected" to an ST. Since we've already
        decided that IF Lines can exist that aren't attached or cross
        connected, that means an IF Line can exist that isn't "part of" a Half
        Link.

    I'll let you in on a secret. Although I know you are building an AM, and
    designing it, I've been pretending (so far) that you are actually building
    the SP entity itself. I.e., you are the software designer of JT&T's (Joe's
    Telephone and Telegraph) SS7 development, and you have free rein to design
    the entity as you see fit. The SP's processor would have an EMA agent in
    it, which makes a bunch of managed objects available to managers. Now it's
    useful to think that way, even if you're actually building an AM, because
    an AM is just software, and it is unconstrained. Every AM has 4 kinds of
    stuff that can be in it...

    1   The "protocol stuff" to talk to the entity.

    2   Mapping stuff that translates an EMA entity view into whatever commands
        the protocol/entity *really* understand.

    3   Stuff that makes up for deficiencies in the entity (as compared to
        *real* EMA entities), for example stuff to generate UIDs or Time
        Stamps.

    4   Added value functionality that makes the entity "better" (easier to
        manage, whatever).

    1-3 must be done in the AM, but 4 does not. Added value function could be
    in the SP AM, but it also could be in a different AM, or in an "object
    specific FM" (FM's don't have to be generic to all entities, some of the
    most useful FMs provide knowledge that "understands" a particular entity
    class). More on this later.

    For Half Links and Half Link Sets, it matters a lot whether the SP entity
    understands these concepts (i.e. it's type 2 stuff) or if those concepts
    are added value concepts you want to add to make managing an SS7 network
    "easier" (i.e. it's type 4 stuff). If half links and Half Link Sets are
    known to the SP, then they probably should be contained in that SP!

    My guess is that an SP does know (at least rudimentarily) about half links
    and half link sets. If we were in a data networking environment, I'd figure
    that while the STs and IFs and IF Lines and cross connects are all part of
    the "physical" and "data link" layers of the network, the idea of a Half
    Link and Half Link Set are "network layer" concepts. 

    My guess is that if an SP wants to send some signal to some other SP, it
    would see if it had a Half Link Set that had the destination SP at its
    "other end", chose a half link which is a member of that set, and pump the
    signal out the ST which is "part of" that Half Link. (See, all those
    relationships do prove useful in describing what the heck is going on in
    that box. :-) Describing how Half Links, and Half Link Sets are used like
    this give me a big clue as to how they can be named.

    A Half Link Set is a child of an SP (that's easy) but which relationship is
    used? Is a Half Link Set a child of the SP it is "in" or is it a child of
    the SP at its "other end"? It's a child of the SP it is "in", because
    that's the SP that uses it. The identifier attribute then is the name of
    the SP at the "other end". Note that using a relationship attribute as an
    identifier as we did here is quite common.

    A Half Link is probably the hardest entity to name in this diagram. It
    could rightly be a child of any of the following: Half Link Set, ST, IF
    Line, Signalling Channel and Link. It's 1-N to all of them, it's existance
    depends on all of them (except perhaps the Link), and all of them are as
    stable (or more stable) than the Half Link. Still the choice is clear based
    on how I think it's used. A Half Link is a child of a Half Link Set. The
    identifier could be a free choice name or number, or it might be a
    combination of the  IF name and IF Line Number of the IF Line that is part
    of the Half Link. The latter would only work if the Half Link always had to
    have an IF Line which is part of it. Generally, we've used an arbitrary
    name attribute in cases like this.


    We've now named all the entities on the left. Looking at the Signalling
    Trunks and Channels, and at the Links and Link Sets, how are they named?

    A Signalling Trunk is a physical thing, a cable from one building to
    another. It can't be named by either endpoint, and there could be lots of
    Signalling Trunks between thesame two buildings, so there's really nothing
    this entity could be contained in. So I'll assume this entity is global,
    and give it a name.

    Signalling Channels are data channels in the trunk, and are best modeled as
    children of the Signalling Trunk entity that "carries" them.

    Now if I use my trick of pretending I'm designing these entities as
    entities rather than as AMs, a couple of points can be called out. First of
    all, since signalling trunks have no CPU's in them, and certainly nothing
    that would have an EMA Agent, these two entities are **entirely** type 4
    stuff. Now they may well be related to other physical entities that we
    really can control (for example there might be a physical switches we can
    control in the physical network that allow us to configure these trunks
    from an AM). But those physical entities are likely to have their own AM's
    which we will use to achieve that control. Thus the Signalling Trunk and
    Signalling Channel entities could be implemented by either an AM (which
    really needs no protocol engine) or an object specific FM.

    In the not too distant future, MCC will be distributed,  and allow FMs and
    AMs on different systems to work together. Anyone designing an AM or FM
    should be thinking ahead to that day, and asking, how would my AM/FM work
    in that environment? For the SPs, they are scattered around the country,
    and it would be "nice" to place the AMs physically "close" to their SPs.
    That means different SPs will be controlled by AMs on different systems.
    For Signalling Trunks/Channels, which end do we put the AM/FM at? Well,
    neither. It probably should be centralized (or at least regionalized).

    For these reasons, I recommend that you build not one, but 2 AMs or an AM
    and an FM. There's an AM for the SP (and the entities contained in it).
    There's an AM/FM which implements the Signalling Trunks and Channels (and
    the Links and Link Sets too).

    Just like Half Links Links and Link Sets are a higher layer concept. A Link
    Set is a bundle of logical connections (each represented by a Link)
    between two SPs. 

    A Link Set shouldn't be a child of either of the SPs it "hooks together",
    it ought to be a global entity (or contained in an SS7 Network entity).
    The identifier of a link set ought to be an unordered pair of SP names
    (i.e. if we have an SP ALPHA and an SP BETA the Link Set between them ought
    to be named Link Set {ALPHA,BETA}) unfortunately, I don't think DNS can
    deal with that naming scheme. Thus the identifier is probably a DNSname.

    Links ought to be children of the Link Set they are in. They are probably
    named by an arbitrary name.

    So that's all the entities, and a fairly complete collection it is (even if
    it is based on a lot of guesses). To summarize, the entities are:

    Entity Class		(Identifier : Data Type)

    SP				(Name : Sp-Name = FullName)
        ST			(Name : SimpleName)
        IF			(Name : Simple Name)
            Line		(Number : Integer)
        Half Link Set		(Other SP : SP-Name)
            Half Link		(Name : SimpleName)
    Signalling Trunk		(Name : FullName)
        Channel			(Number : Integer)
    Link Set			(Name : Unordered Pair of SP-Name)
        Link			(Name : SimpleName)


    That's it, sorry to have answered about 20 times as much as you asked. But
    this tuerned out to be an interesting and useful example, one I intend to
    expand upon in the EMA Folklore document.

    					Mark

Mark,

I am overwhelmed by the sheer size of your answer. I intend to copy all the
files you mention, print them and then read everything very carefully. It 
may take me a couple of days before I can come back with a reply.

Thank you very much for your efforts. I think it is reMARKable..:-).

Peretz

Mark,

First I want to thank you again for your long and detailed reply. It 
really help me to focus on the issue. Your "guesses" regarding the nature of 
the entities are indeed educated and your assumptions were correct. The
entity model you propose looks good. However, I still have some questions:

1. In your reply you mention "Type 2" and "Type 4" entities - What are these
   types? They are not mentioned in the "Guidelines" or the "Folklore"
   documents.

2. A LINKSET is just a collection of LINKs, nothing more. So why not
   see it as a domain? When is "something" a domain and when is it a Global 
   Entity?

3. My biggest problem is the LINK entity. The LINK is a 64Kbps channel which 
   connects two SPs. It is a stable entity. If there are no technical faults
   then a LINK is in service for years.
   When I (as the network manager) am looking at a LINK entity I want to see 
   all the elements that the LINK is going through as well as the two ends of 
   the LINK. A LINK is an END TO END entity. it "Contains" all the elements
   along the way:
      ST (May be only the port of the ST dedicated to this LINK)
      IF (May be only the port of the IF dedicated to this LINK)  
      Cables, channel banks, repeaters, radio equipment, and whatever equipment
      there is that connects the two SPs.
      IF
      ST
   All these elements are part of the LINK. However, they are also Global 
   Entities (I.E a channel bank) or Child Entities (I.E the ST) and EMA does
   not allow that an entity will have two "parents".

   This seems to me like a big disadvantage of EMA! Why a child entity cannot
   be contained in two Global Entities?

4. Stating the previous question in DECmcc terms: I want to be able to "look
   into" the global entity SP and see all it's child entities and be able
   to operate on them.
   I also want to be able to "look into" the global entity LINK and see all 
   it's child entities and be able to operate on them.
   I do not see why some of the child entities of the LINK cannot be also
   child entities of the SP.
  
5. Assuming that EMA and DECmcc are not going to change, and that a child
   entity can have only one "parent", then how do you propose to structure
   the entity LINK? When I look at the entity LINK I need to know the status
   of the STs and IFs and all the rest of the elements that the LINK depends
   on them for its availability. 
   One way to achieve this is that a LINK will have several status attributes
   that will indicate the status of these elements. The problem is that status 
   attributes are generic to the LINK entity, but not all LINKs are physically
   the same!
   For example:
       Suppose I have status attributes for the LINK entity:
          ST_A_status
          IF_A_status
          ST_B_status
          IF_B_status
   Then this answers the simple case where a LINK is connecting SP_A and SP_B 
   directly. 

   But there are many other possibilities! for example:

    -----------                ---------------                     -----------
   |   SP-A    |              |    SP-B       |                   | SP-C      |
   |---     ---|   LINK       |---         ---|                   |---     ---|
   |ST |---|---|--------------|---|-------|---|-------------------|---|---|ST |
   |   |   |IF |              |IF |       |IF |                   |IF |   |   |
   |---     ---|              |---         ---|                   |---     ---|
    -----------                ---------------                     -----------

    Here the LINK is connecting SP-A and SP-C. It is just  "switched through" 
    SP-B (did I mention that an SP is actually a telephone switch? The LINK
    may be  switched like any other channel).
    
    SP-B does not look at the information carried by the LINK. Yet, a failure
    of an IF in SP-B will cause a LINK failure. 

    The problem is that we cannot have different attributes for each LINK.
    A LINK is a LINK is a LINK. So what to do? 

Please help,
Peretz

    Peretz,
    
    Unfortunately, I can't answer all your questions today - some quick
    answers to some of the simpler ones...
    
    1 - Type 2 and Type 4 refered to the various sorts of functions that
    could be embedded in an AM, Type 2 mapped functions in the foriegn
    entity into EMA operations on managed objects. Type 3 were functions
    that made up for "deficiencies" in the entity (like a lack of time
    stamps and UUIDs). Type 4 were added value functions to make the
    management "better" or "easier".
    
    2 - A link set is (or could be) a domain, but not all domains are link
    sets. A link set might have an attribute that told "the number of links
    that are working right now", that wouldn't be an attribute of a generic
    domain. Until we have inheritance fully supported, you're probably
    better off making linkset a new entity class.
    
    4 - You are right, it would be useful to allow an entity to have more
    than one parent at a time. Neither EMA V1 nor OSI allow that. I'm
    thinking about adding that to EMA V2 - details are TBD.
    
    Right now, DECmcc "navigation" (i.e. moving from one entity to another
    through the windows & map user interface) is limited to navigation from
    parent to child. There's a long standing proposal to allow navigation
    in the user inteface by *any* relationship between 2 entities. Note
    with that capability you'd have a lot more powerful browsing
    capability, and could look from a Link into all it's IF's and Cross
    connects and SPs... This would be "better" for your users than simply
    allowing an entity to have more than one parent.
    
    Mark