Re: RFC 4666 on Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)

A general comment on ASP failover cases,
M3UA does not have any method of doing retrieval /retranamission
Although SCTP does have the capability through multi homing,
the ULP should have the request in place to do the retrieval/retransmission
In the case of a single AS having only a single ASP configured, there is 
no chance of retrieval (but this is the most rare configuration as networks
are configured  not to go down with a single point of failure)
In case the AS is configured with two ASPs and each having a different 
SCTP assoc with a single path in  each of the assoc..
there is no chance of message retrieval... as per the current rfc.

No idea if this was not felt important in a telecom network!!

[email protected] wrote:

>A new Request for Comments is now available in online RFC libraries.
>
>        
>        RFC 4666
>
>        Title:      Signaling System 7 (SS7) Message 
>                    Transfer Part 3 (MTP3) - User 
>                    Adaptation Layer (M3UA) 
>        Author:     K. Morneault, Ed.,
>                    J. Pastor-Balbas, Ed.
>        Status:     Standards Track
>        Date:       September 2006
>        Mailbox:    [email protected], 
>                    [email protected]
>        Pages:      124
>        Characters: 292991
>        Obsoletes:  RFC3332
>        See-Also:   
>
>        I-D Tag:    draft-ietf-sigtran-rfc3332bis-06.txt
>
>        URL:        http://www.rfc-editor.org/rfc/rfc4666.txt
>
>This memo defines a protocol for supporting the transport of any SS7
>MTP3-User signalling (e.g., ISUP and SCCP messages) over IP using the
>services of the Stream Control Transmission Protocol.  Also,
>provision is made for protocol elements that enable a seamless
>operation of the MTP3-User peers in the SS7 and IP domains.  This
>protocol would be used between a Signalling Gateway (SG) and a Media
>Gateway Controller (MGC) or IP-resident Database, or between two
>IP-based applications.  It is assumed that the SG receives SS7
>signalling over a standard SS7 interface using the SS7 Message
>Transfer Part (MTP) to provide transport.  This document obsoletes
>RFC 3332.  [STANDARDS TRACK]
>
>This document is a product of the Signaling Transport
>Working Group of the IETF.
>
>This is now a Proposed Standard Protocol.
>
>STANDARDS TRACK: This document specifies an Internet standards track
>protocol for the Internet community,and requests discussion and 
>suggestions for improvements.Please refer to the current edition of the 
>Internet Official Protocol Standards (STD 1) for the standardization 
>state and status of this protocol.  Distribution of this memo is 
>unlimited.
>
>This announcement is sent to the IETF list and the RFC-DIST list.
>Requests to be added to or deleted from the IETF distribution list
>should be sent to [email protected].  Requests to be
>added to or deleted from the RFC-DIST distribution list should
>be sent to [email protected].
>
>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>an EMAIL message to [email protected] with the message body 
>
>help: ways_to_get_rfcs. For example:
>
>        To: [email protected]
>        Subject: getting rfcs
>
>        help: ways_to_get_rfcs
>
>Requests for special distribution should be addressed to either the
>author of the RFC in question, or to [email protected].  Unless
>specifically noted otherwise on the RFC itself, all RFCs are for
>unlimited distribution.
>
>Submissions for Requests for Comments should be sent to
>[email protected].  Please consult RFC 2223, Instructions to RFC
>Authors, for further information.
>
>
>Joyce K. Reynolds and Sandy Ginoza
>USC/Information Sciences Institute
>
>...
>
>
>
>_______________________________________________
>Sigtran mailing list
>[email protected]
>https://www1.ietf.org/mailman/listinfo/sigtran
>
>
>  
>