Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt

From: [email-masked]
Date: Thu, 03 Jul 2003 11:32:42 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: Signalling Connection Control Part User Adaptation 
                          Layer (SUA)
	Author(s)	: J. Loughney, G. Sidebottom
	Filename	: draft-ietf-sigtran-sua-15.txt
	Pages		: 118
	Date		: 2003-7-3
	
This Internet Draft defines a protocol for the transport of any         Signalling Connection Control Part-User signalling over IP using the   Stream Control Transport Protocol. The protocol is designed to be 
modular and symmetric, to allow it to work in diverse architectures, 
such as a Signalling Gateway to IP Signalling Endpoint architecture 
as well as a peer-to-peer IP Signalling Endpoint architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sua-15.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-sua-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-sua-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Fri, 4 Jul 2003 15:54:23 +0530

Hi  John,
 Some comments and queries :-

 >>  Section 3.2.1  CLDT
                Sequence Control is set to 0 for class 0 messages.
 what is the intention behind setting this value to 0 ?

 >>  Section 3.4.4 SCON   says
   "Note 1:    When the SSN is included it must be equal to 1. If the
              SSN is included the SCON corresponds to the N-PCSTATE
              primitive used to convey the Restricted Importance Level
              (RIL) to the SCCP user. When the SSN is not included, the
              SCON message corresponds to the SCCP N-PCSTATE primitive
              reporting signalling point or network congestion status.   "

but the section 3.10.24  (congestion level parameter  description) still talks about the N-State primitive.
So Which is correct out of the two ? Please clarify

>>  All SSNM messages have a note stating "Affected Point Code Field can contain
 one point code when SSN is present in the message".  What about if SSNM
contains more than one affected point codes and SSN as well, then how should that
SSNM be handled ?
Is it a valid message ? if yes then how should it be handled ?
Please clarify on this point if I am missing something.

>>   In Section 3.10.24  size of congestion level field is written 8 bits but in figure it is shown as 32 bits
 Which one is correct?

>>   In Section 3.10.23  segmentation TLV, Length is 32 it should be 8.

>>  Section 4.3 and 4.3.1  are using M3UA term instead of SUA.

>>  Section 4.3.1  SCTP CDI and SCTP RI are described twice.

>>  Section 4.3.1 refers "Figure 4 ASP/ IPSP States per AS"   as Figure 3.

 Thanks and Regards
 Yogesh
 www.hssworld.com
 Hughes Software Systems

_______________________________________________
Sigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sigtran

---

From: "Zannin, Francois" <[email-masked]>
Date: Thu, 10 Jul 2003 21:32:06 +0200

Brian,

My understanding of the SE for M3UA (and I guess SUA) was that the single exchange of ASPTM (and others) request and acknowledgement was enough to Activate (or deactivate) Two AS identified by the same RC.
This do not remove the need to send the Notify to the service provider for an AS (the remote IPSP)!

Ex: If one IPSP can see one remote AS as Active, it sends the notify to all IPSP that offers the same AS. And this is true for all IPSP. 
Now, if we consider that in single exchange mode, one IPSP is playing the role of ASP and the other one the role of SG, the behavior is not the same! 

By reading the RFC, I can understand that the SE is just a shortcut to the DE where two AS uses the same RC on the same association, and one send the Active only if it is ready to handle  traffic and the second answer with the Active_Ack only if it is also ready to handle traffic. This is not the same thing as a simple SG/ASP emulation between two IPSP!!!

Can this point of the SE be more precisely detailed!!!

Regards,

Francois

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, July 10, 2003 9:09 PM
To: Anzile, Christophe
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt

Christophe,

IPSP SE is an ASP/SGP relationship and only the ASP side need send
ASP Id.

IPSP DE both send ASPAC and the ASP Id is not needed in ASPUP Ack.

So how would the IPSP use this?

You say to include it in some messages below, but not what the
receiver of the ASPUP Ack is expected (or able) to do with the value.

What would the SE IPSP receiving the ASPUp Ack (remember, acting in ASP
mode) do with it?  There are no procedures defined for an ASP to use
an "SGP Id" if you will...

So, I'm an SE IPSP acting in ASP mode.  I send you an ASPUP and you
send me an ASPUP Ack with an ASP Id in it.  What am I to do with it?
I never send Notify (you do), so what do I do with it?  What use is it?

--brian

Anzile, Christophe wrote:                                                          (Thu, 10 Jul 2003 17:35:08)
> My proposal would be :
> 
> The optional ASP Identifier parameter is specifically useful for IPSP 
> communication. In that case the IPSP answering the ASP Up message MAY 
> include its own ASP Identifier value, so that it can give back its ASP
> Identifier to the demanding IPSP in case of a single UP/UP-Ack exchange.
> For standard AS-SG communication, this parameter MUST NOT be used. 
> 
> 
> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: Thursday, July 10, 2003 3:45 PM
> To: [email-masked]
> Cc: Anzile, Christophe; [email-masked]
> Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> 
> 
> John,
> 
> We discussed this before an nobody had a real problem with it.
> 
> However, more than just adding the optional parameter to the
> ASP Up Ack, it also needs to be described how one should use it.
> Althoug a lot of uses were discussed, nobody put together a
> coherent proposal for its use.
> 
> Does someone have a simple proposal for it use?
> 
> --brian
> 
> John Loughney wrote:                                                                  (Thu, 10 Jul 2003 16:33:51)
> > Hi,
> > 
> > That could be reasonable - anyone have problems with this?
> > 
> > John
> > 
> > > -----Original Message-----
> > > From: ext Anzile, Christophe [mailto:[email-masked]]
> > > Sent: 10 July, 2003 12:26
> > > To: Loughney John (NRC/Helsinki)
> > > Cc: [email-masked]
> > > Subject: RE: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> > > 
> > > 
> > > 
> > > Hi John,
> > > 
> > > section 3.5.2 : 
> > > it would be judicious to add an optional ASP-ID parameter in 
> > > the UP-ACK message,
> > > especially for IPSP communication (think of single exchange).
> > > 
> > > Regards,
> > > Christophe.
> > > 
> > 
> -- 
> Brian F. G. Bidulock
> [email-masked]
> http://www.openss7.org/

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

---

From: "Anzile, Christophe" <[email-masked]>
Date: Thu, 10 Jul 2003 11:25:31 +0200

Hi John,

section 3.5.2 : 
it would be judicious to add an optional ASP-ID parameter in the UP-ACK message,
especially for IPSP communication (think of single exchange).

Regards,
Christophe.

---

From: "Anzile, Christophe" <[email-masked]>
Date: Fri, 11 Jul 2003 12:04:34 +0200

Brian,

You're right. AspId is no use in SGP/ASP exchange.

I'm just getting confused, because SUA draft says in terminology chapter:

   IP Server Process (IPSP) - A process instance of an IP-based 
   application.  An IPSP is essentially the same as an ASP, except that 
   it uses SUA in a peer-to-peer fashion.

It never says that IPSP could play the role of an SGP while being an ASP..
May be it would be nice to add such a note about this..

Christophe.

-----Original Message-----
From: Brian F. G. Bidulock [mailto:[email-masked]]
Sent: Thursday, July 10, 2003 9:09 PM
To: Anzile, Christophe
Cc: [email-masked]; [email-masked]
Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt

Christophe,

--brian

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

---

From: [email-masked]
Date: Tue, 29 Jul 2003 15:15:58 +0300

Hi Brian,

Thanks for the review, I will look at updating this as soon
as my vacation is over.

thanks,
John

> From: ext Brian F. G. Bidulock [mailto:[email-masked]]
> Sent: 26 July, 2003 17:02
> Actually, there are a lot of problems with the changes made from
> sua-14 to sua-15 as follows:
> 
> +   SCTP - Stream Control Transport Protocol. 
> 
> That would be Stream Control TRANSMISSION Protocol.  There are quite a
> few places in the document where this error is made.  Even in the
> references:
> 
> +   Signalling Connection Control Part-User signalling over 
> IP using the 
> +   Stream Control Transport Protocol. The protocol is designed to be 
> +   modular and symmetric, to allow it to work in diverse 
> architectures, 
> +   such as a Signalling Gateway to IP Signalling Endpoint 
> architecture 
> +   as well as a peer-to-peer IP Signalling Endpoint architecture.   
> 
> -   [2960]         RFC 2960 "Stream Control Transport Protocol" R. 
> +   [2960]         RFC 2960 "Stream Control Transport Protocol", R. 
>                    Stewart, et al, November 2000. 
> 
> Please use "Siganlling" instead of "Signaling".
> 
> +   PC - Signaling System no. 7 Point Code. 
> 
> Network Appearance:
> 
> +   Network Appearance - The Network Appearance is an SUA local 
> +   reference (typically an integer) shared by SG and AS that 
> together 
> +   with a Signalling Point Code or global title uniquely 
> identifies an 
> +   SS7 node by indicating the specific SS7 network it belongs to. 
> 
> Network appearance has no meaning in relationship to a Global Title.
> Global Titles are independent of signalling point code and are only
> meaningful to the node performing global title translation.  Strike
> global title from the definition.
> 
> +   code (PC) and sub-system number (SSN).  The subsystem 
> identified by 
> 
> That should be "subsystem number," no hyphen.
> 
>  1.4.1 Support for the transport of SCCP-User Messages 
>  
>     The SUA supports the transfer of SCCP-user messages. The 
> SUA layer 
> -   at the SG and at the ASP support the seamless transport the user 
> -   messages between the SG and the ASP. 
> +   at the signaling gateway and at the ASP support the seamless 
> +   transport the user messages between the signaling gateway and the 
> +   ASP. 
> 
> Above should be "transport of user messages" instead of "transport the
> user messages".
> 
>  1.4.2 SCCP Protocol Class Support 
>  
> -   Depending upon the SCCP-users supported, the SUA shall 
> support the 4 
> +   Depending upon the SCCP-users supported, the SUA supports the 4 
>     possible SCCP protocol classes transparently.  The SCCP protocol 
>     classes are defined as follows: 
> 
> Why the removal of SHALL?
> 
>  1.5.2 Address Mapping at the ASP 
> 
> -   An ASP routes responses to the SGP that it received 
> messages from; 
> -   within the routing context which it is currently active and 
> -   receiving traffic.  The routing context itself is used by 
> the ASP to 
> -   select the SGP. 
> +   An ASP routes all responses to the SGP that it received messages 
> +   from; within the routing context which it is currently active and 
> +   receiving traffic.  The ASP uses the routing context to 
> select the 
> +   SGP. 
> 
> The second sentence is clearer, but the first sure is not.
> 
>  1.5.4 SCTP Stream Mapping 
>  
> -   The SUA supports SCTP streams. The SG/AS needs to 
> maintain a list of 
> -   SCTP and SUA-users for mapping purposes.  SCCP-users requiring 
> -   sequenced message transfer need to be sent over a stream 
> supporting 
> -   sequenced delivery. 
> +   The SUA supports SCTP streams. Signaling Gateway SG and 
> Application 
> +   Servers need to maintain a list of SCTP and SUA-users for mapping 
> +   purposes.  SCCP-users requiring sequenced message 
> transfer need to 
> +   be sent over a stream supporting sequenced delivery. 
> 
> Above use "Signalling" instead of "Signaling".  Also, ALL SCTP streams
> support sequenced delivery.  Please say "stream with 
> sequenced delivery"
> instead of "stream supporting sequenced delivery".
> 
> +   The Reserved field is set to 0 in messages sent, is not 
> be examined 
> +   on reception. 
> +
> 
> Please make the above a proper sentence.  Something like: 
> "The Reserved
> field is set to 0 in messages sent and is not to be examined 
> in messages
> received."
> 
>     Implementation note: This message covers the following SCCP 
>     messages: unitdata (UDT), extended unitdata (XUDT), long unitdata 
> -   (LUDT). 
> +   (LUDT). Sequence Control is set to 0 for class 0 messages. 
> 
> This change is incorrect.  Please remove this addition.  We 
> discussed this
> long ago and Sequence Control is required in class 0 messages for some
> network configurations and for proper MTP relay accross a relay point.
> It might not be provided by the SCCP/SUA-User for class 0, 
> but then the
> SUA layer (at ASP, IPSP or SGP) must ultimately select a 
> loadsharing value.
> That is why we made the parameter MANDATORY for all protocol classes.
> 
>     Note 1:    When the SSN is included, the DUNA message 
> corresponds to 
> -              the SCCP N-STATE primitive. When SSN is not, the DUNA 
> -              message corresponds to the SCCP N-PCSTATE primitive.   
> +              the SCCP N-STATE primitive, and contains just 
> one point 
> +              code in the Affected Point Code parameter. When SSN is 
> +              not, the DUNA message corresponds to the SCCP 
> N-PCSTATE 
> +              primitive.   
> 
> The DUNA can contain multiple affected point codes even if the SSN is
> included.  This is particularly the case when the SG or IPSP supports
> the same subsystem on multiple point codes.  Please put it back the
> way it was.
> 
> -   Note 1:    When the SSN is included, the SCON message 
> corresponds to 
> -              the SCCP N-STATE primitive. When SSN is not 
> included, the 
> -              SCON message corresponds to the SCCP N-PCSTATE 
> primitive. 
> +   Note 1:    When the SSN is included it must be equal to 1. If the 
> +              SSN is included the SCON corresponds to the N-PCSTATE 
> +              primitive used to convey the Restricted 
> Importance Level 
> +              (RIL) to the SCCP user. When the SSN is not 
> included, the 
> +              SCON message corresponds to the SCCP N-PCSTATE 
> primitive 
> +              reporting signalling point or network 
> congestion status. 
> 
> No, the SSN doesn't have to be 1.  Where did you get that idea?
> 
> -   Note 1:    The DUPU corresponds to the SCCP N-PCSTATE primitive.  
> +   Note 1:    The DUPU corresponds to the SCCP N-PCSTATE 
> primitive, and 
> +               contains in the Affected Point Code parameter 
> just one 
> +              point code.  
> 
> Particularly as User/Cause is always the SCCP SI number, 
> multiple affected
> point codes can occur.  Please put it back the way it was.
> 
>  3.4.6 Destination Restricted (DRST) 
>  
>     The DRST message is optionally sent from the SG to all concerned 
>     ASPs to indicate that the SG has determined that one or more 
>     destinations are now restricted from the point of view of 
> the SG, or 
>     in response to a DAUD message if appropriate. The SUA 
> layer at the 
>     ASP is expected to send traffic to the affected 
> destination via an 
>     alternate SG of equal priority, but only if such an 
> alternate route 
> -   exists and is available. If the affected destination is currently 
> -   considered unavailable by the ASP, the peer should be 
> informed that 
> -   traffic to the affected destination can be resumed.  In 
> this case, 
> -   the SUA layer should route the traffic through the SG 
> initiating the 
> -   DRST message. 
> +   exists and is available. If the ASP currently considers 
> the affected 
> +   destination unavailable, the peer should be informed that 
> traffic to 
> +   the affected destination could be resumed.  In this case, the SUA 
> +   layer should route the traffic through the SG initiating the DRST 
> +   message. 
> 
> This is only true if the DRST corresponds to TFR.  Note also that the
> DRST cannot correspond to N-PCSTATE because there is no 
> N-PCSTATE primitive
> for PC restriction (it is an MTP concept only).  This message 
> corresponds to
> N-COORD that has little to do with the description above, no 
> matter how is is
> worded exactly.
> 
> -            0x17      Routing Key Change Refused 
> +            0x17      Not Used in SUA 
> 
> Good, but you forgot to remove the statement later:
> 
>    The "Routing Key Change Refused" error is sent when the SG 
> refuses a 
>    change in the Routing Key parameters.   
> 
> 
> -   User/Cause                           0x010C 
> +   Cause / User                         0x010C 
> 
> Everwhere else in the document it is referred to as 
> User/Cause, execpt here:
> 
>  3.10.12 Cause / User 
> 
> Change both of these to "User/Cause".
> 
>      0010     This is most commonly used in North American networks. 
>                The Translation Type implicitly determines Nature of 
>                Address and Numbering Plan. This data can be 
> configured 
>                in the SG. The number of digits is always even and 
>                determined by the SCCP address length.  
> -    0011                     Numbering Plan and Translation 
> Type are tak
> +    0011                     Numbering Plan and Translation 
> Type are taken over. It 
>                is implicitly assumed that the Nature of Address = 
>                Unknown.  
> -    0100                     This format is used in 
> international networ
> +    0100                     This format is used in 
> international networks and most 
>                commonly in networks outside North America. All 
>                information to populate the source address is 
> present in 
>                the SCCP Address. 
> 
> Above is text extending past 72 columns that was truncated in 
> sua-14.  Please
> shift the text over.
> 
>       0              Unknown 
>       1 - 63         International services 
>       64 - 127       Spare 
> -     128 > 254      National network specific 
> +     128 û 254      National network specific 
>       255            Reserved 
> 
> Non ASCII character, again.
> 
>            Value     Description  
>             0x0      No special options 
>             0x1      Return message on error 
>  
> -                    Bits 3-7 are spare and SHOULD be coded 
> zero, and MUS
> +                    Bits 3-7 are spare and SHOULD be coded 
> zero, and MUST be 
>           ignored by the receiver. 
> 
> Again text extending beyond 72 columns.
> 
>  4.3 AS and ASP State Maintenance 
>  
> -   The SUA layer on the SGP maintains the state of each 
> remote ASP, in 
> -   each Application Server that the ASP is configured to receive 
> +   The SUA layer on on the SGP maintains the state of each 
> remote ASP, 
> +   in each Application Server that the ASP is configured to receive 
>     traffic, as input to the SUA message distribution function.  
> 
> All this change did was introduce a typo: "on on".
> 
> +      1 IPSP Single Exchange (SE) model. Only a single exchange of 
> +        ASPTM or ASPSM messages is needed to change the IPSP state. 
> +        This means that a set of request from one end and 
> acknowledge 
> +        from the other will be enough. This configuration requires 
> +        static RK configuration.  
> +
> +      2 IPSP Double Exchange (DE) model. Both IPSPs have to send 
> +        request messages and both IPSPs have to acknowledge 
> the request 
> +        messages from the other end. This results in a 
> double exchange 
> +        of ASPTM and ASPSM message, one from each end. This 
> +        configuration supports dynamic routing key configuration by 
> +        using RKM messages in the same way as ASP-SGP scenario.  
> 
> Remove mention of RK configuration.  This has not been agreed.
> 
> +   In order to ensure interoperability, an M3UA implementation 
> +   supporting IPSP communication MUST support IPSP SE model and MAY 
> +   implement IPSP DE model.  
> 
> Change M3UA to SUA above.
> 
> +   * Reception of messages from the peer M3UA layer at the 
> ASP/IPSP;  
> +   * Reception of some messages from the peer M3UA layer at other 
> +   ASPs/IPSPs in the AS (e.g., ASP Active message indicating 
> 
> Change M3UA to SUA above.
> 
> +   ASP-DOWN: The remote M3UA peer at the ASP/IPSP is 
> unavailable and/or 
> +   the related SCTP association is down.  Initially all 
> ASPs/IPSPs will 
> +   be in this state. An ASP/IPSP in this state SHOULD NOT be 
> sent any 
> +   SUA messages, with the exception of Heartbeat, ASP Down 
> Ack and Error 
> 
> Change M3UA to SUA above.
> 
> +   ASP-INACTIVE: The remote M3UA peer at the ASP/IPSP is 
> available (and 
> +   the related SCTP association is up) but application traffic is 
> +   stopped. In this state the ASP/IPSP SHOULD NOT be sent 
> any DATA or 
> +   SSNM messages for the AS for which the ASP/IPSP is inactive.  
> +
> +   ASP-ACTIVE: The remote M3UA peer at the ASP/IPSP is available and 
> +   application traffic is active (for a particular Routing 
> Context or 
> +   set of Routing Contexts).  
> 
> Change M3UA to SUA above.
> 
> +   SCTP CDI: The SCTP CDI denotes the local SCTP layer's 
> Communication 
> +   Down Indication to the Upper Layer Protocol (M3UA) on an 
> SGP.  The 
> +   local SCTP layer will send this indication when it 
> detects the loss 
> +   of connectivity to the ASP's peer SCTP layer.  SCTP CDI 
> is understood 
> +   as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 
> +   notification from the SCTP layer.  
> +
> +   SCTP RI: The local SCTP layer's Restart indication to the 
> upper layer 
> +   protocol (M3UA) on an SG.  The local SCTP will send this 
> indication 
> +   when it detects a restart from the ASP's/IPSP's peer SCTP layer.  
> 
> You now have two SCTP CDI and SCTP RI paragraphs.  Those 
> above and these
> below:  Delete the ones above because they have M3UA instead of SUA.
> 
>    SCTP CDI: The SCTP CDI denotes the local SCTP layer's 
> Communication 
>    Down Indication to the Upper Layer Protocol (SUA) on an SGP. The 
>    local SCTP layer will send this indication when it detects 
> the loss 
>    of connectivity to the ASP's peer SCTP layer.  SCTP CDI is 
> understood 
>    as either a SHUTDOWN_COMPLETE notification or COMMUNICATION_LOST 
>    notification from the SCTP layer. 
> 
>    SCTP RI: The local SCTP layer's Restart indication to the 
> upper layer 
>    protocol (SUA) on an SG.  The local SCTP will send this indication 
>    when it detects a restart from the ASP's peer SCTP layer. 
> 
> The diagram now says "Other IPSP in AS Overrides".  Please say
> "Other ASP/IPSP in AS Overrides".
> 
>                 |      Other   +-------|              | 
> -               |   ASP in AS  |       +--------------+ 
> +               |   IPSP in AS |       +--------------+  
>                 |   Overrides  |           ^     | 
> 
>  4.3.4.2 ASP Down Procedures 
>  
>     The ASP will send an ASP Down message to an SGP when the 
> ASP wishes 
>     to be removed from service in all Application Servers 
> that it is a 
> -   member and no longer receive any DATA, SSNM or ASPTM 
> messages.  This 
> -   action MAY be initiated at the ASP by an M-ASP_DOWN 
> request primitive
> -   from Layer Management or MAY be initiated automatically by an SUA 
> -   management function.    
> +   member and no longer receive any Connectionless or Connection - 
> +   Oriented, SNM or ASPTM messages.  This action MAY be 
> initiated at the 
> +   ASP by an M-ASP_DOWN request primitive from Layer 
> Management or MAY 
> +   be initiated automatically by an SUA management function. 
> 
> Above change SNM to SSNM.
> 
>     When an ASP wishes to withdraw from receiving traffic 
> within an AS, 
> -   the ASP sends an ASP Inactive message to the SGP or IPSP.  This 
> -   action MAY be initiated at the ASP by an M-ASP_INACTIVE request 
> -   primitive from Layer Management or MAY be initiated 
> automatically by 
> -   an SUA management function.  In the case where an ASP is 
> processing 
> -   the traffic for more than one Application Server across a 
> common SCTP
> -   association, the ASP Inactive message contains one or 
> more Routing 
> -   Contexts to indicate for which Application Servers the 
> ASP Inactive 
> -   message applies.  In the case where an ASP Inactive 
> message does not 
> -   contain a Routing Context parameter, the receiver must know, via 
> -   configuration data, which Application Servers the ASP is 
> a member and
> -   move the ASP to the ASP-INACTIVE state in each all Application 
> -   Servers.  In the case of an Override mode AS, where 
> another ASP has 
> -   already taken over the traffic within the AS with an ASP Active 
> -   ("Override") message, the ASP that sends the ASP Inactive 
> message is 
> -   already considered by the SGP to be in state 
> ASP-INACTIVE.  An ASP 
> -   Inactive Ack message is sent to the ASP, after ensuring that all 
> -   traffic is stopped to the ASP.  
> +   or the ASP wants to initiate the process of activation, 
> the ASP sends 
> +   an ASP Inactive message to the SGP or IPSP.  
> 
> Change above to "initiate the process of deactivation" 
> instead of "initiate
> the process of activation".
> 
> Also, above you have delted the description of the ASP 
> Inactive procedure for
> Override mode.  Please put back:
> 
> -                     In the case where an ASP Inactive 
> message does not 
> -   contain a Routing Context parameter, the receiver must know, via 
> -   configuration data, which Application Servers the ASP is 
> a member and
> -   move the ASP to the ASP-INACTIVE state in each all Application 
> -   Servers.
> 
> and
> 
> -             In the case of an Override mode AS, where 
> another ASP has 
> -   already taken over the traffic within the AS with an ASP Active 
> -   ("Override") message, the ASP that sends the ASP Inactive 
> message is 
> -   already considered by the SGP to be in state 
> ASP-INACTIVE.  An ASP 
> -   Inactive Ack message is sent to the ASP, after ensuring that all 
> -   traffic is stopped to the ASP.  
> 
> The following addition:
> 
> +4.8 NIF Not Available on SGP  
> +
> +   If the SG (all the SGPs) is isolated from the NIF, then 
> all the users 
> +   are isolated from the SS7 network.  A DUNA(*) message 
> MUST be sent 
> +   from the SGPs to all the ASPs.   
> +
> +   If only one SGP in the SG is isolated entirely from the 
> NIF, the SGP 
> +   SHOULD abort its associations. An alternative would be 
> for the SGP to 
> +   send ASP Down Ack. 
> +
> +   If one or more SGP suffer a partial failure (where aborting the 
> +   association(s) would cause all active AS(es) to fail), 
> then the SGP 
> +   MUST send DUNA messages for the affected SPC(es).  This 
> is the case 
> +   where an SGP can continue to service one or more active 
> AS(es), but 
> +   due to a partial failure it is unable to service other(s) active 
> +   AS(es). 
> 
> Please remove the entire addition.  The M3UA IG has removed 
> this.  That is
> the problem with adding stuff from the M3UA IG.  The M3UA IG 
> has not gone
> through Last Call.
> 
> +   [SIGSEC]       J. Loughney, M. Tuexen, J. Pastor-Balbas, 
> "Security 
> +                  Considerations for SIGTRAN Protocols", Work in 
>                    Progress.  
> 
> There is a Work In Progress as a normative reference.  This 
> draft will be
> held until this reference becomes an RFC.
> 
> --brian
> 
> 
> John Loughney wrote:                                (Thu, 03 
> Jul 2003 19:29:23)
> > Hi all,
> > 
> > I have updated SUA, I have tried to incorporate some of the 
> major issues
> > from the M3UA Implementation Guide.  All interested parties, please
> > give the document a quick read, because I would like to 
> send this to the
> > IESG for final approval.
> > 
> > thanks,
> > John
> > 
> > > From: ext [email-masked] 
> [mailto:[email-masked]]
> > > Sent: 03 July, 2003 18:33
> > > Cc: [email-masked]
> > > Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> > > 
> > > 
> > > This Internet Draft defines a protocol for the transport of 
> > > any         Signalling Connection Control Part-User 
> > > signalling over IP using the   Stream Control Transport 
> > > Protocol. The protocol is designed to be