Subject: Re: M3UA07: Network Appearance

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 12:16:56 -0500

John,

Plese see commends below...

John Schantz wrote:                                          (Wed, 08 Aug 2001 09:24:37)
> 
>    Liu,
>    
>    
>    
>    You guys have been busy on this last night, I only working on my
>    sprinkler system.
>    
>    
>    
>    I didn't want to go backward in the thread but I would like to reply
>    back to your first message where you represented the problem and
>    proposed that there were 3 solutions.  Actually there are two more and
>    I think they may already be used in regular SS7 networks:
>    
>    
>    
>    4) SG merges the traffic from its multiple network accesses and
>    presents a single node/PC view to the ASs

If you look back in the messages, this is not possible since this places
requirements on routing configurations within the SS7 network which are
not natural.

>    
>    
>    
>    5) SG does not merge the traffic from its multiple network accesses
>    but assigns a network appearance per access (used locally by an SEP to
>    support multiple linksets to the same set of STPs).

This was proposed.  You originally thought that this violated the pristine
concept of Network Appearance is Network Id...

>    
>    
>    
>    I'll recap the network so others don't have to dig down for it.  We
>    have an SG with two "appearances" on an SS7 network (PC A and PC B).
>    There is a signalling point, PC C, in the network that is unavailable
>    to the SG's PC A's access to the network, but node C is available via
>    the SG's PC B's access to the network.  There are ASs behind the SG,
>    so the question is "How is the unavailability of C presented to these
>    ASs?"
>    
>    
>    
>    Option (4), the SG merges the traffic from its multiple accesses and
>    presents a single node/PC view to the ASs (i.e., the ASs do not need
>    to know how the SG is connected to the network) and C is available via
>    the SG's B side, NO unavailability is forwarded to the ASs connected
>    to the SG since the SG still has an available route to C (via the SG's
>    B access).  It is a local implementation issue at the SG of how it
>    merges its traffic from the SS7 network and presents it as coming from
>    a single SG to the ASs.  Actually, I think this is how it should be
>    done.  Nodes connected to the SG should not know how the SG is
>    connected to the network.

But, this is not the way that it is done in the SS7 network (an not in the
IP network either for that matter).  See the example which does not require
gateway screening to fail.

>    
>    
>    
>    Option (5),  the SG is not able to merge the traffic from its multiple
>    accesses (appearances).  Hence it must present separate traffic flows
>    to its connecting ASs.  The SG should assign a network appearance per
>    access, hence allowing the traffic to flow on the same associations to
>    the ASs.  This should be sufficient to identify the flows for the SG
>    and the ASs.  When a DUNA for A is received for one of the network
>    appearances, an AS will know that it can not use that "network
>    appearance" to send traffic to A.  There is a local issue of whether
>    the AS is intelligent enough to know that [network appearance 1 / node
>    A] is the same as [network appearance 2 / node A].  If the SG was not
>    intelligent enough to merge the traffic, why should the AS be any
>    different.  Perhaps the service application sitting on top of all of
>    this could be intelligent enough to know and it could move the traffic
>    over, but this still a local implementation issue.

This was originally proposed (and is how it stands in the draft).  You
objected strongly to it at that point.  Has your position changed?

>    Your Option (2) does not work.  The DATA messages are not addressed to
>    PC A, you have not separated traffic flows, and SG is functioning as
>    an STP, hence since the DATA messages are addressed to PC C, there is
>    nothing to stop them.  Placing an OPC A in the DUNA or making A as an
>    affected point code has no effect, you have not separate your traffic
>    flows.  The PC-to-PC model is broken in (2) and (3).  If the SG must
>    maintain the traffic separation for its multiple accesses, then either
>    use separate associations (option 1 where SG is now SG/PC-A and
>    SG/PC-B) or use separate network appearances (option 5).

Agreed.  I didn't have the heart (or stamina) to point it out.

..........

To summarize, your Option (4) does not work, and Option (5) has been
proposed.  The proposals that work are:

	(a) Network Appearance == Network Access (the easiest way to ensure
	    this is to make the NA a Network Id and SPMC point code).

	(b) Include optional Concerned Point Code on SNMM (perhaps with
	    Network Id embedded, obviating need for Network Appearance
	    in SNMM).

	(c) Include optional Routing Context(s) in SNMM (obviating need
	    for Network Appearance in SNMM).

I prefer (c).  It is less work for both the SG and the ASP in these
circumstances and it is consistent with SUA.

--Brian

>    
>    
>    
>    John
>    
>    -----Original Message-----
>    From: Hong Liu [mailto:[email-masked]]
>    Sent: Wednesday, August 08, 2001 9:59 AM
>    To: sigtran
>    Subject: RE: M3UA07: Network Appearance
>    
>    Hi, Tolga,
>    
>    
>    
>    One solution to the A-link congestion problem is to assign multiple
>    point codes to an SEP, as the A linkset is limited to 16 links. (There
>    may be other reasons to have multiple point codes.) I don't know how
>    many SEPs in the SS7 networks can support this feature but it is (I
>    heard) one solution that is being used today. Supporting multiple
>    point codes in an SEP definitely introduce additional complexity in
>    management (as seen in this discussion), maybe that is why not many
>    SEPs are able to do that today. Of course, there are other solutions
>    to the A-link capacity problem, such as high speed links.
>    
>    
>    
>    In the meantime, I think the problem we are talking about here goes
>    beyond just having multiple point codes in an SGP, irrespective of
>    whether the network is quasi-associated or fully associated. Only when
>    the SGP has different connectivity into the same SS7 network with
>    different point codes, i.e. partitioning the SS7 network, will the
>    problem occur. Is such connectivity scheme being used in today's SS7
>    networks? I don't know for sure. On the other hand, with M3UA, we
>    already go beyond existing SS7 network configurations, as illustrated
>    in your diagram.
>    
>    
>    
>    Although I hate to impose restrictions on configurations, it would be
>    helpful to crystalize the underlying architectural models M3UA intends
>    to support. It seems to me that many discussions on the list about
>    M3UA, including this thread, boil down to this issue: different people
>    seem to have different assumptions. Maybe now it is time to put them
>    all on the table.
>    
>    
>    
>    Cheers,
>    
>    
>    
>    --Hong
>    
>    
>    
>    -----Original Message-----
>    From: Asveren, Tolga
>    Sent: 2001-8-8 () 14:26
>    To: sigtran
>    Cc:
>    Subject: RE: M3UA07: Network Appearance
>    
>      Brian,
>      I agree that the restriction I have proposed would limit the
>      flexibility of
>      M3UA, although personally I don't like a SG working in SEP mode
>      with
>      multiple point codes. But it seems nobody else is complaining.
>      But the other thing I have proposed will solve the problem I think,
>      to have
>      SG with its own point code. Then one can have as many direct links
>      as
>      desired to any other destination from SG. What is wrong with this
>      configuration? One disadvantage would be, that one uses one more
>      point code
>      for SG, but I think this is acceptable in this case. The
>      configuration I am
>      speaking of is below.
>                         +-------+
>                         | ASP1  | (AS1 with DPC = 5.255.3)
>                         +-------+  (AS2 with DPC = 5.255.4)
>                            |
>                            |
>                            |
>                         +--------+ (AS1 with DPC = 5.255.3)
>                         |  SG1   | (AS2 with DPC = 5.255.4)
>                         +--------+ SS7 PC of SG1 = 5.255.6
>                          |    | |
>                        +---+  | |
>                200.1.4 |SEP|  | |
>                        +---+  | +------------------+
>                          | |  |                    |
>                          | |  |                    |
>                          | |  +---+                +----+
>                          | + -|STP|----------------| STP|
>                          |    +---+                +----+
>                          |                            |
>                          +----------------------------+
>      The goal is by no means to resist adding a new parameter ;)
>          Regards,
>          Tolga
>      -----Original Message-----
>      From: Brian F. G. Bidulock [[1]mailto:[email-masked]]
>      Sent: Tuesday, August 07, 2001 8:50 PM
>      To: sigtran
>      Subject: Re: M3UA07: Network Appearance
>      Tolga,
>      Also, the restriction you propose does not work for the fully
>      associated (F-link connected) network.  One cannot restrict
>      an SEP to not be connected multiply to the network because
>      multiple F-link connections in fully associated networks (common
>      in Europe, I hear) would also be restricted.  This would make
>      M3UA useless in a large portion of the deployed SS7 networks.
>      I'm sorry, you can twist it this way and that way and the same
>      problem arises.  The simplest way to accomplish this is to
>      relieve the problem by adding an optional parameter to the SNMM
>      messages which must be included in these otherwise problematic
>      configurations.
>      I don't understand anyone's resistance to an optional parameter
>      (Routing Context or Concerned Point Code) which is immediately
>      available at the SG to be populated in the message and which is
>      immediately usable at the ASP so that the ASP can ignore the
>      idiosynchrasies of these configurations.
>      Its simple, just add the parameter.  Otherwise you can talk
>      yourself blue in the face for several months.
>      It just so happens that including Routing Context obviates the
>      need for Network Appearance, and even adding a Concerned Point
>      Code with an embedded Network Id (high byte), obviates the need
>      for Network Appearance as well.
>      Network Appearance is primarly useless because there is no
>      corresponding concept in SS7 (unless you consider the equally
>      useless NI bits in the RL as equivalent).
>      --brian
>      Brian F. G. Bidulock wrote:                        (Tue, 07 Aug
>      2001
>      19:40:30)
>      > Tolga,
>      >
>      > But then M3UA would be imposing a restriction of the
>      configuration
>      > of SG/ASP.  It is M3UAs objective to not impose such a
>      restriction,
>      > and doing so for the sake of not permitting an optional parameter
>      > is a message is absurd.
>      >
>      > --brian
>      >
>      > Asveren, Tolga wrote:                             (Tue, 07 Aug
>      2001
>      18:53:50)
>      > > Brian,
>      > >
>      > > What I mean is that to have SG with its own point code
>      (different than
>      > > the ones of SEPs in your example).  Because, I think, the real
>      reason
>      > > why there is a problem with management messages is that two
>      SEPs have
>      > > different connectivity to SS7 network in your example.
>      Separating SEPs
>      > > from SG will make this connectivity again single.  I know SG
>      can also
>      > > run in SEP mode. What I am only saying is that, if there would
>      be a
>      > > restriction saying that a SG cannot have more than one SEP with
>      > > different network connectivity, then your example wouldn't be a
>      valid
>      > > configuration, and there wouldn't be a problem.
>      > >
>      > >      Tolga
>      > >
>      > >
>      > >
>      > > -----Original Message-----
>      > > From: Brian F. G. Bidulock [[2]mailto:[email-masked]]
>      > > Sent: Tuesday, August 07, 2001 7:42 PM
>      > > To: sigtran
>      > > Subject: Re: M3UA07: Network Appearance
>      > >
>      > >
>      > > Tolga,
>      > >
>      > > That would be the IPSP case, I believe.  M3UA has to work that
>      > > way too.  There is a long dicussion on multiple STPs on another
>      > > thread.  If your meaning that the SG is an SP with the transfer
>      > > function (not an STP, there is just one of them), then, again,
>      > > it is the IPSP case.  This is running with a modified MTP and
>      > > everything gets real blurry.  M3UA does not address the IPSP
>      > > case sufficiently in the draft to even comment.
>      > >
>      > > M3UA must address the backhaul case with SEP, because STP or
>      > > "transfer function" interconnect might not be available to the
>      > > operator.
>      > >
>      > > --brian
>      > >
>      > > Asveren, Tolga wrote:                                    (Tue,
>      07 Aug
>      2001 18:19:41)
>      > > > Brian,
>      > > >
>      > > > Then what about running SG in STP mode with its own point
>      code? In
>      fact I
>      > > > don't like the configuration where SG is working in SEP mode
>      with more
>      than
>      > > > one point code.
>      > > >
>      > > > Just another try ;)
>      > > >
>      > > >       Tolga
>      > > >
>      > > > -----Original Message-----
>      > > > From: Brian F. G. Bidulock [[3]mailto:[email-masked]]
>      > > > Sent: Tuesday, August 07, 2001 7:13 PM
>      > > > To: sigtran
>      > > > Subject: Re: M3UA07: Network Appearance
>      > > >
>      > > >
>      > > > Tolga,
>      > > >
>      > > > Sorry, that should read "Hong's solution (1)..." (i.e.
>      multiple
>      associations,
>      > > > one per network attachment).
>      > > >
>      > > > --brian
>      > > >
>      > > > Brian F. G. Bidulock wrote:
>      (Tue, 07 Aug
>      2001 18:10:31)
>      > > > > Tolga,
>      > > > >
>      > > > > That is not a workable solution in fully associated
>      networks: a
>      single
>      > > > > SPMC may be conntext to the network via multiple F-link
>      connections,
>      > > > > each which serves as a separate network attachment.
>      Instead of 1 SG
>      > > > > with 192 F-links, you would have this be 192 SGs, each with
>      1
>      F-link,
>      > > > > requiring 192 separate SCTP associations.  Separating into
>      separate
>      SGs
>      > > > > does not scale in fully associated networks.
>      > > > >
>      > > > > This is not terribly different than Hong's solution (2),
>      which is
>      > > >                                              ^^^^^^^^^^^^
>      > > > > equally unworkable for the same reason.
>      > > > >
>      > > > > --brian
>      > > > >
>      > > > >
>      > > > > Asveren, Tolga wrote:
>      (Tue, 07
>      Aug 2001 17:53:09)
>      > > > > > Hong,
>      > > > > >
>      > > > > > I think another solution would be, splitting SG in
>      Brian's example
>      in
>      > > > > > two SG's, so that every SG serves only one SEP. Then one
>      would
>      have
>      > > > > > different associations from ASP to two different SGs.
>      This would
>      solve
>      > > > > > the problem.
>      > > > > >
>      > > > > >     Regards,
>      > > > > >      Tolga
>      > > > > >
>      > > > > > -----Original Message-----
>      > > > > > From: Hong Liu [[4]mailto:[email-masked]]
>      > > > > > Sent: Tuesday, August 07, 2001 6:36 PM
>      > > > > > To: sigtran
>      > > > > > Subject: RE: M3UA07: Network Appearance
>      > > > > >
>      > > > > >
>      > > > > > Hi, Brian and others,
>      > > > > >
>      > > > > > Since I was the one bringing up this thread again, I feel
>      "obligated"
>      > > > > > to chip in what I feel about this issue. In case my
>      thoughts have
>      been
>      > > > > > already expressed and discussed, please take them as
>      refresh of
>      the
>      > > > > > memory since this thread has been very long, -:)
>      > > > > >
>      > > > > > I guess there are two issues involved here: the semantics
>      of
>      Network
>      > > > > > Appearance and the need to demux the management messages
>      from a
>      common
>      > > > > > SCTP association betweeen an SGP and an ASP.
>      > > > > >
>      > > > > > >From the semantical perspective, I agree with John,
>      Klaus, Tolga
>      and
>      > > > > > >Barry about the definition of Network Appearance as a
>      network ID,
>      > > > > > >when an SGP is sitting on multiple SS7 networks. What
>      Brian has
>      been
>      > > > > > >arguing is that the parameter itself is NOT sufficient
>      for an ASP
>      to
>      > > > > > >distinguish SNMM from different point codes an SGP
>      represents,
>      and
>      > > > > > >hence he needs some mechanism to do that. (Brian, please
>      correct
>      me
>      > > > > > >if I misunderstood your point.)
>      > > > > >
>      > > > > > In fact, the problem manifests itself for an SGP
>      attaching to a
>      single
>      > > > > > SS7 network, but bearing more than one point code, and
>      there are
>      > > > > > different routes into the SS7 network from these point
>      codes. (See
>      > > > > > Brian's example in the earlier part of the thread.) In
>      this case,
>      the
>      > > > > > ASP needs to update its own routing information based on
>      the SNMM
>      > > > > > messages relayed from the SGP.  Hence, the problem
>      actually has
>      little
>      > > > > > to do with Network Appearance for multiple networks.
>      > > > > >
>      > > > > > To make the example more concrete, say the SGP has two
>      PCs A and
>      B,
>      > > > > > and A and B have different linksets into the SS7 network.
>      The fact
>      > > > > > that an SS7 signaling point C is not reachable from A
>      does not
>      > > > > > necessarily imply that it is not reachable from B.
>      Suppose C is
>      still
>      > > > > > reachable from B, then the ASP, when receiving an DUNA
>      message
>      from
>      > > > > > the SGP, needs to differentiate that the unavailability
>      of C is
>      > > > > > through A, not through B, and updates its routesets
>      accordingly.
>      It
>      > > > > > seems to me there are three solutions:
>      > > > > >
>      > > > > > (1) Establish separate SCTP associations between SGP and
>      ASP for
>      each
>      > > > > > PC pair;
>      > > > > >
>      > > > > > (2) Add PC A also in the DUNA message as an affected
>      point code;
>      > > > > >
>      > > > > > (3) Use a separate parameter to convey the information of
>      > > > > > "reachability via A in the SGP"
>      > > > > >
>      > > > > > Option (1) mirrors the linkset concept in current SS7
>      networks,
>      but
>      > > > > > does not seem to be favored by the M3UA community. Option
>      (3) is
>      in
>      > > > > > essence what Brian was trying to do. I think Brian's
>      intention was
>      not
>      > > > > > to introduce another parameter, so he tried to maximize
>      the use of
>      > > > > > Network Appearance with additional information. (which
>      caused
>      > > > > > objections from semantics viewpoint.) Option (2) seems to
>      be less
>      > > > > > intrusive, but additional procedures need to be specified
>      as how
>      to
>      > > > > > interpret "A" in this context. For example, if A is the
>      only
>      affected
>      > > > > > PC in DUNA, then it means the SGP is disconnected from
>      the SS7
>      network
>      > > > > > via PC A, etc... In any case, I don't have strong
>      opinions on any
>      > > > > > options above as long as we find a solution to this
>      problem.
>      > > > > >
>      > > > > > The ultimate question, of course, is whether this example
>      has any
>      real
>      > > > > > meaning. I will leave it to the experts in SS7 operations
>      to
>      justify
>      > > > > > that. The beauty of M3UA is that it is flexible to
>      accommodate
>      > > > > > different usage scenarios, many of which seem to be
>      extensions to
>      what
>      > > > > > SS7 can do today. However, it also places the burden on
>      the
>      protocol
>      > > > > > itself in order to meet the needs in these scenarios...
>      > > > > >
>      > > > > > Cheers,
>      > > > > >
>      > > > > > --Hong
>      > > > > >
>      > > > > >
>      > > > > > -----Original Message-----
>      > > > > > From: Brian F. G. Bidulock
>      > > > > > Sent: 2001-8-7 (???) 18:25
>      > > > > > To: sigtran
>      > > > > > Cc:
>      > > > > > Subject: Re: M3UA07: Network Appearance
>      > > > > >
>      > > > > >
>      > > > > >
>      > > > > > Tolga,
>      > > > > >
>      > > > > > Asveren, Tolga wrote:
>      (Tue, 07
>      Aug 2001 07:53:03)
>      > > > > > > I think the definition of NA should be clarified as
>      soon as
>      > > > > > > possible. My personal opinion is to use NA to
>      differentiate
>      between
>      > > > > > > different networks, not between SPMCs. If an ASP is
>      serving ASs
>      on
>      > > > > > > different point codes, then correct handling of
>      received DUNA,
>      DAVA
>      > > > > > > etc... is a responsibility of ASP based on Affected PC
>      and NA
>      fields
>      > > > > > > in the received message. NIF on ASP can do the required
>      analysis,
>      > > > > > > which is out of the scope of M3UA.  I like definition
>      of NA in
>      > > > > > > draft6 more than the one in draft7-8.
>      > > > > >
>      > > > > > Sorry, doing the required analysis on DAVA etc. is *NOT*
>      out of
>      scope
>      > > > > > of M3UA.  It is fully within the scope to address how to
>      > > > > > (successfully) process M3UA messages.  There is not
>      enough
>      information
>      > > > > > in DAVA etc. to accomplish this in all cases.  DAVA etc.
>      will
>      require
>      > > > > > a concerned point code field or the Routing Context
>      included in
>      the
>      > > > > > kmessage in those cases.  When Routing Context must be
>      included,
>      > > > > > Network Appearance is unnecessary.
>      > > > > >
>      > > > > > So, basically, if you want to keep your definition of
>      Network
>      > > > > > Appearance as Network Id, it goes away and is replaced by
>      Concerned
>      > > > > > Point Code or Routing Context in all messages except REG
>      REQ.
>      > > > > >
>      > > > > > --brian
>      > > > > >
>      > > > > >
>      > > > > > >
>      > > > > > > draft6:
>      > > > > > > "The Network Apperarence identifies an SS7 network
>      context for
>      the
>      > > > > > > purpose of logically separating the signalling traffic
>      between
>      the
>      > > > > > > SG and the ASP overa common SCTP Association."
>      > > > > > >
>      > > > > > > draft7-8:
>      > > > > > > "The Network Appearence uniquely identifies an SS7
>      entty(Point
>      Code)
>      > > > > > > into an SS7 netwrk, as presented by SG."
>      > > > > > > Especially the following sentence, which was added in
>      draft7, I
>      > > > > > > don't like: "It is also necessary when an SG is
>      configured as an
>      STP
>      > > > > > > hosting multiple point codes, or wen configured as
>      multiple end
>      > > > > > > nodes within the same network, in which case each point
>      code is
>      a
>      > > > > > > separate network appearence between the SG and the ASP
>      over a
>      common
>      > > > > > > SCTP Association"
>      > > > > > >
>      > > > > > > This sentence is in line with Brian's idea (and not in
>      line with
>      my
>      > > > > > > idea ;))
>      > > > > > > I always tend to think NA as an identifier for separate
>      networks.
>      > > > > > >
>      > > > > > >    Regards,
>      > > > > > >    Tolga Asveren
>      > > > > > >
>      > > > > > >
>      > > > > > > -----Original Message-----
>      > > > > > > From: Brian F. G. Bidulock [
>      [5]mailto:[email-masked]
>      <[6]mailto:[email-masked]> ]
>      > > > > > > Sent: Monday, August 06, 2001 4:10 PM
>      > > > > > > To: sigtran
>      > > > > > > Subject: Re: M3UA07: Network Appearance
>      > > > > > >
>      > > > > > >
>      > > > > > > Hong,
>      > > > > > >
>      > > > > > > The conclusion is that the current situation is
>      unsatisfactory
>      for
>      > > > > > > the reasons cited.
>      > > > > > >
>      > > > > > > The ultimate fate of NA, however, does not appear to
>      have yet
>      been
>      > > > > > > decided for M3UA (it has, it seems for SUA).
>      > > > > > >
>      > > > > > > --Brian
>      > > > > > >
>      > > > > > > Hong Liu wrote:
>      (Mon, 06 Aug
>      > > > > > > 2001 22:27:57)
>      > > > > > > > Brian, and others,
>      > > > > > > >
>      > > > > > > > Sorry if I bring this long thread back to life. Have
>      we
>      reached
>      > > > > > > > any conclusion on this thread at all?
>      > > > > > > >
>      > > > > > > > Regards,
>      > > > > > > >
>      > > > > > > > --Hong
>      > > > > > > >
>      > > > >
>      > > > > --
>      > > > > Brian F. G. Bidulock
>      > > > > [email-masked]
>      > > > > [7]http://www.openss7.org/
>      > > >
>      > > > --
>      > > > Brian F. G. Bidulock
>      > > > [email-masked]
>      > > > [8]http://www.openss7.org/
>      > > >
>      > > >
>      > > > ---
>      > > > You are currently subscribed to sigtran as:
>      [email-masked]
>      > > > To unsubscribe send a blank email to
>      [email-masked]
>      > > >
>      > > >
>      > > > ---
>      > > > You are currently subscribed to sigtran as:
>      [email-masked]
>      > > > To unsubscribe send a blank email to
>      [email-masked]
>      > >
>      > > --
>      > > Brian F. G. Bidulock
>      > > [email-masked]
>      > > [9]http://www.openss7.org/
>      > >
>      > >
>      > > ---
>      > > You are currently subscribed to sigtran as:
>      [email-masked]
>      > > To unsubscribe send a blank email to
>      [email-masked]
>      > >
>      > >
>      > > ---
>      > > You are currently subscribed to sigtran as:
>      [email-masked]
>      > > To unsubscribe send a blank email to
>      [email-masked]
>      >
>      > --
>      > Brian F. G. Bidulock
>      > [email-masked]
>      > [10]http://www.openss7.org/
>      --
>      Brian F. G. Bidulock
>      [email-masked]
>      [11]http://www.openss7.org/
>      ---
>      You are currently subscribed to sigtran as: [email-masked]
>      To unsubscribe send a blank email to
>      [email-masked]
>      ---
>      You are currently subscribed to sigtran as: [email-masked]
>      To unsubscribe send a blank email to
>      [email-masked]
>      
>    ---
>    You are currently subscribed to sigtran as: [email-masked]
>    To unsubscribe send a blank email to
>    [email-masked]
> 
> References
> 
>    1. mailto:[email-masked]
>    2. mailto:[email-masked]
>    3. mailto:[email-masked]
>    4. mailto:[email-masked]
>    5. mailto:[email-masked]
>    6. mailto:[email-masked]
>    7. http://www.openss7.org/
>    8. http://www.openss7.org/
>    9. http://www.openss7.org/
>   10. http://www.openss7.org/
>   11. http://www.openss7.org/

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 8 Aug 2001 13:36:49 -0500

Hi John,

..........

--Brian

-- 
Brian F. G. Bidulock
[email-masked]
http://www.openss7.org/

---