Subject: Re: M3UA07: Network Appearance

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 15:52:36 -0500

John,

Your view does appear to be consistent with the SIGTRAN
architecture.  Backhaul is not a special case in M3UA
nor the SIGTRAN architecture, in reality backhaul is the
predominant case in SIGTRAN UAs.

--brian

John Schantz wrote:                                          (Fri, 10 Aug 2001 13:32:57)
> Sorry, but NO.  In the non-backhaul case, M3UA peer-to-peer network
> management messages are REQUIRED.  MTP-user primitives are useless at this
> level.  I think these peer-to-peer messages are the DUNA, DAVA, etc.  Only
> in the special case of backhaul might they be used to convey information for
> the MTP-user primitives.
> 
> John
> 
> > -----Original Message-----
> > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > Sent: Friday, August 10, 2001 3:09 PM
> > To: sigtran
> > Subject: Re: M3UA07: Network Appearance
> > 
> > 
> > John,
> > 
> > M3UA provides the MTP-User interface even in the IPSP case,
> > it does not transport MTP Peer-to-Peer messages.  It transports
> > MTP-User primitives from one MTP-User interface to another.
> > 
> > --brian
> > 
> > John Schantz wrote:                                          
> > (Fri, 10 Aug 2001 12:54:08)
> > > If you are stating that M3UA still sends TFP, TFA, etc. in 
> > the non-backhaul
> > > cases and uses DUNA, DAVA, etc. ONLY in the backhaul case, 
> > then fine, I
> > > don't care what you do with them.
> > > 
> > > > -----Original Message-----
> > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > Sent: Friday, August 10, 2001 2:48 PM
> > > > To: sigtran
> > > > Subject: Re: M3UA07: Network Appearance
> > > > 
> > > > 
> > > > John,
> > > > 
> > > > DUNA, DAVA, etc are not peer to SS7 management messages
> > > > in the backhaul case: they are peers to the MTP/MTP-User
> > > > primitives.  This is clearly stated in the draft: M3UA
> > > > exports the MTP/MTP-User interface, it does not attempt
> > > > transport MTP to MTP Peers messages, not does it claim
> > > > to do so.
> > > > 
> > > > John Schantz wrote:                                          
> > > > (Fri, 10 Aug 2001 12:21:23)
> > > > > Tolga,
> > > > > 	You are correct.  The TFP, TFA, and TFR are on a point 
> > > > code level
> > > > > and apply only to the route between the two adjacent 
> > > > nodes/PCs (STP sending
> > > > > the message (OPC) and the receiving node (DPC) (could 
> > be SS7 node)).
> > > > > 
> > > > > This is another reason why the DUNA, DAVA, etc. were 
> > > > defined at the PC level
> > > > > so that they would be peers to the SS7 management 
> > messages.  This
> > > > > network/node management philosophy should not change.  If 
> > > > some SGs and ASs
> > > > > need to manage at the interface level (SGP/ASP), then 
> > > > separate management
> > > > > procedures and messages should be defined for their use.
> > > > > 
> > > > > Ultimately it will come down to whether networks will want 
> > > > to buy the
> > > > > limited SGs and ASs that can not support the single 
> > > > network/node management
> > > > > view.
> > > > 
> > > > The proposed changes do not preclude a single 
> > network/node management
> > > > view.  They merely permit other views as well.  So, 
> > ultimately it will
> > > > come down to whether networks will want to buy SG ASs which *only*
> > > > support the single network/node management view.
> > > > 
> > > > --brian
> > > > 
> > > > > 
> > > > > John
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Asveren, Tolga [mailto:[email-masked]]
> > > > > > Sent: Friday, August 10, 2001 1:17 PM
> > > > > > To: sigtran
> > > > > > Subject: RE: M3UA07: Network Appearance
> > > > > > 
> > > > > > 
> > > > > > Brian,
> > > > > > 
> > > > > > But from SS7 User Part point of view, aren't SNTM on point 
> > > > > > code granularity?
> > > > > > 
> > > > > >   Tolga
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > Sent: Friday, August 10, 2001 1:41 PM
> > > > > > To: sigtran
> > > > > > Subject: Re: M3UA07: Network Appearance
> > > > > > 
> > > > > > 
> > > > > > Tolga,
> > > > > > 
> > > > > > Please see comments below...
> > > > > > 
> > > > > > Asveren, Tolga wrote:                                    
> > > > > > (Fri, 10 Aug 2001 12:15:37)
> > > > > > > Please see comments and questions below:
> > > > > > > 
> > > > > > >> -----Original Message-----
> > > > > > >> From: Brian F. G. Bidulock [mailto:[email-masked]]
> > > > > > >> Sent: Thursday, August 09, 2001 2:28 PM
> > > > > > >> To: sigtran
> > > > > > >> Subject: Re: M3UA07: Network Appearance
> > > > > > >> 
> > > > > > >> 
> > > > > > >> Hong, and others,
> > > > > > >> 
> > > > > > >> There are a number of ways of getting around the problem
> > > > > > >> presented in the network configuration example.  I 
> > summarize
> > > > > > >> them here for discussion:
> > > > > > >> 
> > > > > > >>     A)	Restrict ASPs to serve no more than one 
> > Point Code.
> > > > > > >> 
> > > > > > >>     B)  Restrict SGs to no more than one network 
> > access to the
> > > > > > >> 	same network (i.e. point code address space).
> > > > > > >> 
> > > > > > >>     C)  Force the ASP in these situations to have one
> > > > > > >> 	association per set of ASs which form a uniquely
> > > > > > >> 	attached SPMC.
> > > > > > >> 
> > > > > > >>     D)	Let the definition of Network 
> > Appearance be expanded
> > > > > > >> 	from Network Id (i.e. point code address space) to
> > > > > > >> 	include Network Attachment (i.e. unique network
> > > > > > >> 	attachment/SPMC combination).
> > > > > > >> 
> > > > > > >>     E)  Place Concerned Point Code(s) information 
> > in all SNMM
> > > > > > >> 	messages to identify the SPMC(s) to which the SNMM
> > > > > > >> 	message applies.
> > > > > > >> 
> > > > > > >>     F)	Place Routing Context(s) in all SNMM messages to
> > > > > > >> 	identify the AS(s) to which the SNMM message applies.
> > > > > > >> 
> > > > > > >>     G)	Combined E) and F) approach.
> > > > > > >> 
> > > > > > >> Following is my technical consideration of the merits and
> > > > > > >> drawbacks of each approach:
> > > > > > >> 
> > > > > > >> Approach A): Restrict ASPs to serve no more than one 
> > > > Point Code.
> > > > > > >> 
> > > > > > >>    This restriction has been opposed in the past due to
> > > > > > >>    consideration of valid cases where an MGC can 
> > have multiple
> > > > > > >>    point codes.  Switches with multiple point 
> > codes has been
> > > > > > >>    supported in GR-137 GR-394 and Q.764/767 for some time.
> > > > > > >>    Multiple point codes in an MGC may be required for 
> > > > any of the
> > > > > > >>    reasons for which it is required in a switch today: CIC
> > > > > > >>    exhaustion, special routing, multiple network 
> > attachments,
> > > > > > >>    mediation, gateway switching between networks 
> > in the same
> > > > > > >>    point code address space (e.g. access tandems), etc.
> > > > > > >> 
> > > > > > >>    Approach A will limit the usable deployment of 
> > M3UA within
> > > > > > >>    the SS7 network.
> > > > > > >
> > > > > > > TOLGA>> In such a case, what is wrong defining more than 
> > > > > > one ASP, one per
> > > > > > > point code, for this MGC?
> > > > > > 
> > > > > > There is nothing wrong about it and it should be 
> > permitted.  If it
> > > > > > is the only solution in this case, then it places a 
> > restriction on
> > > > > > the architecture of the ASP which should be stated in 
> > the draft.
> > > > > > Currently the draft states that M3UA places no such 
> > architectural
> > > > > > restrictions on the SG/ASP configuration.
> > > > > > 
> > > > > > >> 
> > > > > > >> Approach B):  Restict SGs to no more than one 
> > network access to
> > > > > > >> 	      the same network (i.e, point code address space).
> > > > > > >> 
> > > > > > >>    This approach would require mixed fully associated and
> > > > > > >>    quasi-associated networks to have one SG per 
> > F-link which is
> > > > > > >>    attached to a node with the transfer function.  
> > > > This would be
> > > > > > >>    an administrative nightmare from two 
> > perspectives:  1) in
> > > > > > >>    some existing networks this will require 
> > hundreds of SGs per
> > > > > > >>    ASP, 2) addition (or activation) of the 
> > transfer function at
> > > > > > >>    the end of an F-link would mean that a separate 
> > SG must be
> > > > > > >>    split off from other F-Links.  The only way that
> > > > > > >>    adminstration would be possible in some 
> > prevalent network
> > > > > > >>    configurations would be if a separate SG were to be 
> > > > allocated
> > > > > > >>    to each F-Link.  This approach effectively 
> > turns M3UA into
> > > > > > >>    M2UA in these configurations.  In addition, M3UA cannot
> > > > > > >>    properly handle the case of multiple SGs yet, 
> > > > particularly as
> > > > > > >>    regards UPU handling across the SGs.
> > > > > > >> 
> > > > > > >>    Another, related, alternative which does not have the
> > > > > > >>    multiple-SG problem, is restricting SGPs to no 
> > more than one
> > > > > > >>    network access to the same network.  But then, this will
> > > > > > >>    require the ASP to keep track of routing on a 
> > per-SGP basis
> > > > > > >>    (part of the embroiled controversy over partitioning of
> > > > > > >>    SGPs).
> > > > > > >> 
> > > > > > >>    Approach B is not practical in mixed fully and
> > > > > > >>    quasi-associated networks, limiting M3UA's 
> > applicability to
> > > > > > >>    primarily the North American market in all but very
> > > > > > >>    restricted applications.
> > > > > > >> 
> > > > > > >> Approach C):  Force the ASP in these situations to have one
> > > > > > >> 	      association per set of ASs which form a uniquely
> > > > > > >> 	      attached SPMC.
> > > > > > >> 
> > > > > > > TOLGA>> I think, here what is meant is defining more than 
> > > > > > one ASP. Because,
> > > > > > > at least in my understanding, ASP is an SCTP endpoint, and 
> > > > > > between a SG and
> > > > > > > ASP, there can be only one association. So, this will again 
> > > > > > correspond to
> > > > > > > definign multiple ASPs. What is wrong with this? 
> > > > > > 
> > > > > > There is nothing in the draft stopping multiple associations
> > > > > > between the same ASP/SGP pair.  Nevertheless, I agree 
> > > > that multiple
> > > > > > ASPs with disjoint routing contexts is also a 
> > possibility here.
> > > > > > 
> > > > > > >> 
> > > > > > >>    The difficulty with this approach is that in 
> > mixed fully and
> > > > > > >>    quasi-associated networks, similar to Approach D, it is
> > > > > > >>    difficult for the ASP to know when a separate 
> > association is
> > > > > > >>    required.  Also, the requirement for a separate 
> > association
> > > > > > >>    may change depending upon changes made back in the SS7
> > > > > > >>    network over which the operator of the SG may have no
> > > > > > >>    control.  The only way around this is to 
> > allocate a separate
> > > > > > >>    association for each network attachment (e.g., 
> > > > F-link).  This
> > > > > > >>    could result in the associations being required 
> > > > numbering the
> > > > > > >>    product num(ASP) X num(SGP) X n(F-Links).  For 4 
> > > > ASPs, 4 SGPs
> > > > > > >>    and 100 F-links, this requires 1,600 associations.  
> > > > This does
> > > > > > >>    not scale well and may hit the limitations of 
> > the number of
> > > > > > >>    usable open system-wide or per-process file 
> > descriptors, not
> > > > > > >>    to mention the addressable space necessary and 
> > management
> > > > > > >>    nightmare to track 1,600 AS states at the SG.
> > > > > > >> 
> > > > > > >>    Approach C does not scale and is not practical in 
> > > > mixed fully
> > > > > > >>    and quasi-associated networks, limiting M3UA's 
> > applicability
> > > > > > >>    to prmiarily the North American market in all but very
> > > > > > >>    restricted applications.
> > > > > > >> 
> > > > > > >> 
> > > > > > >> Approach D):  Let the definition of Network Appearance be
> > > > > > >> 	      expanded to include Network Attachment where
> > > > > > >> 	      necessary.
> > > > > > >> 
> > > > > > >>    The difficulties in this approach are two-fold:
> > > > > > >> 
> > > > > > >>    It is not possible for the ASP to determine `a 
> > priori' the
> > > > > > >>    requirement for separate Network Appearance 
> > values.  This
> > > > > > >>    depends on SS7 network configuration and attachment 
> > > > at the SG
> > > > > > >>    which can change.  The requirements for separate Network
> > > > > > >>    Appearance values can change with a few 
> > keystrokes on a node
> > > > > > >>    back in the SS7 network over which the operator of 
> > > > the SG and
> > > > > > >>    ASP may have no control.  To provide additional 
> > attachments
> > > > > > >>    to the SS7 network which do not include the 
> > addition of new
> > > > > > >>    SPMCs or SPMC point codes could result in the 
> > need for new
> > > > > > >>    Network Appearance values which would have to 
> > be provisioned
> > > > > > >>    at both the SG and the ASP.
> > > > > > >> 
> > > > > > >>    This requires the ASP to have information 
> > pertaining to the
> > > > > > >>    attachment of the SG to the SS7 network.  In 
> > the backhaul
> > > > > > >>    case, there is absolutely no need for an 
> > MTP-User to have
> > > > > > >>    knowledge of the underlying network 
> > configuration.  This is
> > > > > > >>    information which is unnecessary at the ASP and 
> > provides an
> > > > > > >>    unnecessary administrative hassle.  It provides 
> > a necessity
> > > > > > >>    for coordination of SG attachment changes at 
> > the ASP which,
> > > > > > >>    where SG and ASP are separate operators, is completely
> > > > > > >>    impractical.
> > > > > > >> 
> > > > > > >>    In addition, this requires passive monitoring 
> > devices to be
> > > > > > >>    equipped with the same information which is 
> > provisioned at
> > > > > > >>    the SG and ASP to be able to interpret 
> > monitored messages
> > > > > > >>    between the two systems.
> > > > > > >> 
> > > > > > >>    Configurations can occur where multiple Network 
> > Appearances
> > > > > > >>    values have been assigned to the same network 
> > > > attachment/SPMC
> > > > > > >>    combination requiring the SG to send multiple 
> > SNMM for the
> > > > > > >>    same SPMC, including multiple NAs in one SNMM 
> > message, or
> > > > > > >>    performing complex logic at both the SG and ASP to 
> > > > reduce the
> > > > > > >>    redunancy between non-unique Network Appearance 
> > assignments.
> > > > > > >> 
> > > > > > >>    Approach D causes problems for configurations 
> > > > wishing dynamic
> > > > > > >>    allocation (because these shifting NA values must be
> > > > > > >>    statically provisioned before they can be used 
> > in REG REQ
> > > > > > >>    messages).
> > > > > > >> 
> > > > > > >>    Approach D is not practical at interconnect 
> > points.  As most
> > > > > > >>    MGC operators are expected to be interconnects (or 
> > > > treated as
> > > > > > >>    interconnects within a regulatory framework), Approach D
> > > > > > >>    would limit M3UA's usability to a single 
> > operator's network.
> > > > > > >> 
> > > > > > >> 
> > > > > > >> Approach E):  Place Concerned Point Code(s) 
> > information in all
> > > > > > >> 	      SNMM messages to identify the SPMC(s) to which the
> > > > > > >> 	      SNMM message applies.
> > > > > > >> 
> > > > > > >>    Approach E can be accomplished by putting SPMC 
> > Id (primary
> > > > > > >>    PC) in the NA as proposed originally by Joyce, 
> > or replacing
> > > > > > >>    or augmenting the NA with a Concerned Point 
> > Code parameter.
> > > > > > >> 
> > > > > > >>    Approach E has the advantage that it resolves the
> > > > > > >>    administrative hassles associated wtih Approach D, it is
> > > > > > >>    possible to statically provision a point code list 
> > > > at the ASP
> > > > > > >>    without regard to the explicit network 
> > attachment of the SG
> > > > > > >>    to the SS7 network.  It permits passive 
> > monitoring without
> > > > > > >>    provisioning of Approach D Network Appearance values.
> > > > > > >> 
> > > > > > >>    Approach E has the disadvantage that the ASP 
> > must perform
> > > > > > >>    more complicated logic and maintain additional 
> > mappings to
> > > > > > >>    determine to which active AS (MTP-User) the 
> > MTP-PAUSE/STATUS
> > > > > > >>    primitive must be indicated.  In addition, it 
> > requires the
> > > > > > >>    ASP to have knowledge of the provisioned routing keys to
> > > > > > >>    perform this mapping, meaning that routing keys must be
> > > > > > >>    provisioned at both the SG and the ASP.  This 
> > is because the
> > > > > > >>    ASP must map CPC to a routing key list which 
> > includes that
> > > > > > >>    CPC as a DPC, to an RC list, to a list of active ASs, to
> > > > > > >>    determine whether to issued the MTP-PAUSE/STATUS 
> > > > primitive to
> > > > > > >>    the MTP-User at the AS.
> > > > > > >> 
> > > > > > >>    Approach E also has the disadvantage that it is 
> > inconsistent
> > > > > > >>    with the approach taken by SUA.
> > > > > > >> 
> > > > > > >>    Approach E is workable in all network 
> > configurations, but
> > > > > > >>    places additional (and unnecessary) mapping and 
> > information
> > > > > > >>    requirements on the ASP and is inconsistent with 
> > > > the approach
> > > > > > >>    taken by SUA.
> > > > > > >> 
> > > > > > > TOLGA >> If something has to be added to the SNMM messages, 
> > > > > > then I am for
> > > > > > > CPC. This will mimic the situation in SS7 well, where also 
> > > > > > those messages
> > > > > > > are sent on point code granularity.
> > > > > > 
> > > > > > SS7 does not send SNTM on a point code granularity, 
> > it sends them
> > > > > > on a route (linkset) granularity.  TFP, for example, 
> > only applies
> > > > > > to the route (linkset) upon which it is received.  
> > Routing Context
> > > > > > better mimics SS7 granularity because it is at the 
> > level of the
> > > > > > route rather than the routeset.
> > > > > > 
> > > > > > > And I think, anyhow to have route keys
> > > > > > > on ASP side is something usefull, for purposes like giving 
> > > > > > user applications
> > > > > > > using ASP the opportunity to query the route keys, or when 
> > > > > > user applications
> > > > > > > want to register for a traffic range, to check that the 
> > > > > > desired trafic range
> > > > > > > is covered by a defined route key in ASP.
> > > > > > 
> > > > > > RK neutrality is not really the only reason to prefer 
> > RC over CPC.
> > > > > > RC simplifies demultiplexing of SNMM messages to AS just 
> > > > as it does
> > > > > > for the DATA case.
> > > > > > 
> > > > > > > Of course CPC is not enough, CPC +
> > > > > > > old style NA.
> > > > > > 
> > > > > > Or CPC == Network Id + PC as proposed by Joyce.
> > > > > > 
> > > > > > --brian
> > > > > > 
> > > > > > 
> > > > > > >> 
> > > > > > >> Approach F):  Place Routing Context(s) in all SNMM 
> > messages to
> > > > > > >> 	      identify the AS(s) to which the SNMM message
> > > > > > >> 	      applies.
> > > > > > >> 
> > > > > > >>    Approach F has all the advantages of Approach E (except
> > > > > > >>    passive monitoring) plus it reduces the information and
> > > > > > >>    mapping requirements at the ASP in the backhaul 
> > case.  When
> > > > > > >>    the ASP receives an SNMM message, it simply generates
> > > > > > >>    MTP-PAUSE/STATUS primtives to those MTP-Users 
> > at those AS
> > > > > > >>    which are indicated by the RC in the list.  The 
> > ASP does not
> > > > > > >>    need to maintain Routing Keys or Routing Key to Routing
> > > > > > >>    Context mappings.  This has the advantage in static
> > > > > > >>    configurations that the only information that 
> > an ASP need
> > > > > > >>    know is the Routing Context to provide full 
> > service to an
> > > > > > >>    Application Server.
> > > > > > >> 
> > > > > > >>    Approach F has the advantage that the approach 
> > is consistent
> > > > > > >>    with that taken by SUA.  It also has the advantage 
> > > > that it is
> > > > > > >>    consistent with the Routing Context 
> > demultiplexing approach
> > > > > > >>    taken for DATA messages.
> > > > > > >> 
> > > > > > >>    Approach F has the disadvantage that passive monitoring
> > > > > > >>    devices must either be statically provisioned 
> > or intercept
> > > > > > >>    REG REQ messages to determine the nature of the 
> > > > SNMM if there
> > > > > > >>    is no other information in the SNMM.
> > > > > > >> 
> > > > > > >>    Approach F is workable in all network 
> > configurations, but
> > > > > > >>    makes it difficult to perform passive monitoring.
> > > > > > >> 
> > > > > > >> Approach G):  Combined E) and F) approach.
> > > > > > >> 
> > > > > > >>    Approach G consists of placing Routing Context(s) 
> > > > in all SNMM
> > > > > > >>    messages which require them, and optionally placing a
> > > > > > >>    Concerned Point Code parameter in the message 
> > as well.  This
> > > > > > >>    is effectively Approach F with the extension of 
> > an optional
> > > > > > >>    Concerned Point Code parameter to be placed in 
> > the message
> > > > > > >>    when passive monitoring is required.
> > > > > > >> 
> > > > > > >>    Approach G has all the advatages and none of the
> > > > > > >>    disadvantages of the other approaches.
> > > > > > >> 
> > > > > > >> I propose Approach G.
> > > > > > >> 
> > > > > > [snip]
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > 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]
> > > > > > 
> > > > > > 
> > > > > > ---
> > > > > > 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]
> > > > 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]
> > 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]
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: Fri, 10 Aug 2001 15:59:18 -0500

Hey John,

If M3UA wished to support peer to peer MTP messaging it would need
to include the following MTP peer-to-perr messages:

	COO, COA, CBD, CBA, ECO, ECA, RCT, RSP, RSR, RCP, RCR,
	LIN, LUN, LIA, LUA, LID, LFU, LLI, LRI, TRA, TRW, DLC,
	CSS, CNS, CNP

M3UA only has MTP/MTP-User primitives covered.

--brian

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

---

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 10 Aug 2001 16:23:08 -0500

Hi John,

Guess what?  M3UA SNMM messages are not even required in the IPSP
case!  Each IPSP can derive the availability of point codes and user
parts directly off of AS state and association state for those
signalling points.  In the IPSP world, there is no STP transfer
functions, so equivalents of SNTM messages are not required.  The
only M3UA message other than ASPXM and RKM needed is DATA.  Congestion
is derived direclty from SCTP association congestion state.

The IPSP still needs, however, to faithfully present the MTP/MTP-User
interface on the upper boundary for MTP-Users to take advantage of.
So, the MTP-User Primitives still need to be supported, but none of
the MTP management peer-to-peer messages need to be supported.

So M3UA SNMM mesages are NOT REQUIRED.  They convey no information
not already provided for in ASPXM and RKM messages.

--brian

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

---