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

[[e-mail]]

Hi Brian,

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

thanks,
John

> -----Original Message-----
> From: ext Brian F. G. Bidulock [mailto:[e-mail]]
> Sent: 26 July, 2003 17:02
> To: Loughney John (NRC/Helsinki)
> Cc: [e-mail]
> Subject: Re: [Sigtran] I-D ACTION:draft-ietf-sigtran-sua-15.txt
> 
> 
> 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