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

["Brian F. G. Bidulock" <[e-mail]>]

John,

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
> 
> > -----Original Message-----
> > From: ext [e-mail] [mailto:[e-mail]]
> > Sent: 03 July, 2003 18:33
> > Cc: [e-mail]
> > Subject: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> > 
> > 
> > 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:
> > 	[e-mail].
> > 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.
> > 
> 
> _______________________________________________
> Sigtran mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/sigtran

-- 
Brian F. G. Bidulock
[e-mail]
http://www.openss7.org/

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