| draft-ietf-sigtran-m3ua-implementors-guide-07Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-m3ua-implementors-guide-07.txt. Network Working Group Javier Pastor-Balbas INTERNET-DRAFT Ericsson Expires: August 2004 Ken Morneault Cisco Systems February, 2004 M3UA Implementor's Guide <draft-ietf-sigtran-m3ua-implementors-guide-07.txt> Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document contains a compilation of all defects found up until the publication date for M3UA [RFC3332]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M3UA to clarify errors in the original M3UA document. This document updates RFC3332 and text within this document supersedes the text found in RFC3332. Pastor, Morneault [Page 1] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 TABLE OF CONTENTS 1. Introduction.......................................................3 1.1 Abbreviations.....................................................3 2. Conventions........................................................3 3. Corrections to RFC3332.............................................3 3.1 Parameter Containing Subparameters with Padding Bytes..............3 3.2 Dynamic Registration Not Supported.................................4 3.3 Contents of User Protocol Data.....................................6 3.4 Scope of Network Appearance........................................7 3.5 Conditional RC and NA parameters...................................9 3.6 Receiving REG for a RK already registered.........................11 3.7 Dynamic Registration Support for Alias Point Code.................15 3.8 Auditing procedure and congestion state...........................16 3.9 Response to an ASPIA message......................................18 3.10 INFO and DIAG parameter length...................................20 3.11 IPSP stuff.......................................................21 3.12 Messages and Streams.............................................28 3.13 ASP Id for IPSP communication....................................28 3.14 n+k redundancy...................................................30 3.15 Multiple Parameters of the Same Type in a Message................35 3.16 Registered Routing Key State After Unexpected ASP Up Message.....35 3.17 Location of Network Appearance...................................36 3.18 Determination of Congestion Abatement When ASP Sends SCON........37 3.19 Removing CIC and SSN from RK.....................................38 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45 3.21 NOTIFY messages are missing in Examples section..................47 3.22 Sending NTFY after sending ASP-UP-ACK............................56 3.23 Re-registration after failure....................................57 3.24 No Configured AS Error...........................................58 3.25 NIF not available on SGP.........................................60 3.26 Notify(ASP-Failure) usage clarification..........................61 3.27 Alignment of ASP Active message with ASP Inactive message........62 3.28 Invalid Version parameter explanation............................64 4. Acknowledgements..................................................66 5. Authors' Addresses................................................66 6. References........................................................66 7. Changes Control...................................................67 7.1 Changes from v00 to v01...........................................67 7.2 Changes from v01 to v02...........................................67 7.3 Changes from v02 to v03...........................................67 7.4 Changes from v03 to v04...........................................67 7.5 Changes from v04 to v05...........................................68 7.6 Changes from v05 to v06...........................................68 7.7 Changes from v06 to v07...........................................69 Pastor, Morneault [Page 2] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 1. Introduction This document contains a compilation of all defects found up until the publication date for the MTP3 User Adaptation Layer (M3UA) [RFC3332]. These defects may be of an editorial or technical nature. This document may be thought of as a companion document to be used in the implementation of M3UA to clarify errors in the original M3UA document. This document updates RFC3332 and text within this document, where noted, supersedes the text found in RFC3332. Each error will be detailed within this document in the form of: - The problem description, - The text quoted from RFC3332, - The replacement text, - A description of the solution. 1.1 Abbreviations SPC Signalling Point Code 2. Conventions The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119]. 3. Corrections to RFC3332 3.1 Parameter Containing Subparameters with Padding Bytes 3.1.1 Description of the problem If a parameter contains subparameters with padding bytes, should the parameter length include the subparameter padding bytes or not. 3.1.2 Text changes to the document --------- Old text: (Section 3.2) --------- Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. Pastor, Morneault [Page 3] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- New text: (Section 3.2) --------- Parameter Length: 16 bits (unsigned integer) The Parameter Length field contains the size of the parameter in bytes, including the Parameter Tag, Parameter Length, and Parameter Value fields. Thus, a parameter with a zero-length Parameter Value field would have a Length field of 4. The Parameter Length does not include any padding bytes. If the parameter contains subparameters, the Parameter Length field will include all the bytes of each subparameter including subparameter padding bytes (if any). 3.1.3 Solution description When calculating the length of a parameter that contains subparameters, include the padding bytes of the subparameters. 3.2 Dynamic Registration Not Supported 3.2.1 Description of the problem There is a need to be able to correlate a Dynamic Registration not supported error to a Registration Request. 3.2.2 Text changes to the document --------- Old text: (Section 4.4.1) --------- If the SGP does not support the registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Type". --------- New text: (Section 4.4.1) --------- If the SGP does not support the registration procedure, the SGP returns an Error message to the ASP, with an error code of "Unsupported Message Class". Pastor, Morneault [Page 4] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 3.8.1) --------- The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received. --------- New text: (Section 3.8.1) --------- The "Unsupported Message Class" error is sent if a message with an unexpected or unsupported Message Class is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 bytes of the offending message. The "Unsupported Message Type" error is sent if a message with an unexpected or unsupported Message Type is received. For this error, the Diagnostic Information parameter MUST be included with the first 40 bytes of the offending message. --------- Old text: --------- The Error message contains the following parameters: Error Code Mandatory Routing Context Mandatory* Network Appearance Mandatory* Affected Point Code Mandatory* Diagnostic Information Optional (*) Only mandatory for specific Error Codes --------- New text: --------- The Error message contains the following parameters: Error Code Mandatory Routing Context Mandatory* Network Appearance Mandatory* Affected Point Code Mandatory* Diagnostic Information Conditional Pastor, Morneault [Page 5] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 (*) Only mandatory for specific Error Codes 3.2.3 Solution description A SGP that does not support registration must return an Error (Unsupported Message Class) message with the first 40 bytes of the offending message (i.e. any Routing Key Management message sent by the ASP) so that the ASP can correlate this error to the Registration Request message. Note that the changes to the "Unsupported Message Class" and "Unsupported Message Type" text make this a general solution that allows the ASP or SG side to correlate these error responses with the offending message. 3.3 Contents of User Protocol Data 3.3.1 Description of the problem There is a need to add a reference that contains the different SS7 message label types to ensure implementations take into account the differences among these labels. 3.3.2 Text changes to the document --------- Old text: (Section 3.3.1) --------- Protocol Data: (variable) The Protocol Data field contains a byte string of MTP-User information from the original SS7 message starting with the first byte of the original SS7 message following the Routing Label. --------- New text: (Section 3.3.1) --------- Protocol Data: (variable) The Protocol Data field contains a byte string of MTP-User information from the original SS7 message starting with the first byte of the original SS7 message following the Routing Label [7][8][29]. Pastor, Morneault [Page 6] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 9.1) --------- [7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP --------- New text: (Section 9.1) --------- [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 (SS7) - Message Transfer Part (MTP)" 3.3.3 Solution description A proper reference was required for the different SS7 message label types. 3.4 Scope of Network Appearance 3.4.1 Description of the problem A problem was found with the scope of the NA parameter. It was not clear whether it should be unique across SG-AS or unique across SCTP associations 3.4.2 Text changes to the document --------- Old text: (Section 3.3.1) --------- Network Appearance: 32-bits (unsigned integer) The Network Appearance parameter identifies the SS7 network context for the message and implicitly identifies the SS7 Point Code format used, the SS7 Network Indicator value, and the MTP3 and possibly the MTP3-User protocol type/variant/version used within the specific SS7 network. Where an SG operates in the context of a single SS7 network, or individual SCTP associations are dedicated to each SS7 network context, the Network Appearance parameter is not required. In other cases the parameter may be configured to be present for the use of the receiver. The Network Appearance parameter value is of local significance only, coordinated between the SGP and ASP. Therefore, in the case where an Pastor, Morneault [Page 7] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 ASP is connected to more than one SGP, the same SS7 network context may be identified by different Network Appearance values depending over which SGP a message is being transmitted/received. Where the optional Network Appearance parameter is present, it must be the first parameter in the message as it defines the format of the Protocol Data field. IMPLEMENTATION NOTE: For simplicity of configuration it may be desirable to use the same NA value across all nodes sharing a particular network context. --------- New text: (Section 3.3.1) --------- Network Appearance: 32-bits (unsigned integer) The Network Appearance parameter identifies the SS7 network context for the message and implicitly identifies the used SS7 Point Code format, the SS7 Network Indicator value, and the MTP3 and possibly the MTP3-User protocol type/variant/version used within the specific SS7 network. Where a SG operates in the context of a single SS7 network, or individual SCTP associations are dedicated to each SS7 network context, the Network Appearance parameter is not required. In other cases the parameter may be configured to be present for the use of the receiver. The Network Appearance parameter value is of local significance only, coordinated between the SG and AS. Therefore, in the case where an AS is connected to more than one SG, the same SS7 network context may be identified by different Network Appearance values depending over which SG a message is being transmitted/received. Where the optional Network Appearance parameter is present, it must be the first parameter in the message as it defines the format of the Protocol Data field. IMPLEMENTATION NOTE: For simplicity of configuration it may be desirable to use the same NA value across all nodes sharing a particular network context. 3.4.3 Solution description The text is modified to show that NA has to be coordinated between AS to SG. This correction also aligns this text with the NA definition in section 1.2 of the RFC. Pastor, Morneault [Page 8] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.5 Conditional RC and NA parameters 3.5.1 Description of the problem Some optional parameters are not always optional. The text should be clear and set a new label to differentiate the behavior of these parameters. 3.5.2 Text changes to the document --------- Old text: (Section 3.3.1) --------- 3.3.1 Payload Data Message (DATA) The DATA message contains the SS7 MTP3-User protocol data, which is an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The DATA message contains the following variable length parameters: Network Appearance Optional Routing Context Optional Protocol Data Mandatory Correlation Id Optional --------- New text: (Section 3.3.1) --------- 3.3.1 Payload Data Message (DATA) The DATA message contains the SS7 MTP3-User protocol data, which is an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. The DATA message contains the following variable length parameters: Network Appearance Conditional Routing Context Conditional Protocol Data Mandatory Correlation Id Optional --------- Old text: (Section 3.4.1) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.1) --------- Pastor, Morneault [Page 9] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Network Appearance Conditional Routing Context Conditional --------- Old text: (Section 3.4.2) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.2) --------- Network Appearance Conditional Routing Context Conditional --------- Old text: (Section 3.4.3) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.3) --------- Network Appearance Conditional Routing Context Conditional --------- Old text: (Section 3.4.4) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.4) --------- Network Appearance Conditional Routing Context Conditional Pastor, Morneault [Page 10] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 3.4.5) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.5) --------- Network Appearance Conditional Routing Context Conditional --------- Old text: (Section 3.4.6) --------- Network Appearance Optional Routing Context Optional --------- New text: (Section 3.4.6) --------- Network Appearance Conditional Routing Context Conditional 3.5.3 Solution description Stating that these parameters are conditional implies that they are not either optional or mandatory. In the parameter description, the text explains when Routing Context and Network Appearance are mandatory and when optional. 3.6 Receiving REG for a RK already registered 3.6.1 Description of the problem The RFC does not clearly specify what the SG should do when it receives a Registration Request for a Routing Key that has already been registered. There are two scenarios to consider: the registration request is a duplicate or it overlaps partially an already registered RK. Also there is a desire to include the possibility of modifying a registered Routing Key. Pastor, Morneault [Page 11] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 The RFC does not clearly specify what the SG should do when it receives a Registration Request for a Routing Key that has already been registered. There are 3 scenarios to consider: 1. The registration request is an exact duplicate of a registered RK. 2. The registration request partially overlaps a registered RK. 3. The ASP is requesting to modify a registered RK. 3.6.2 Text changes to the document --------- Old text: (Section 3.6.1) --------- The format of the Routing Key parameter is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local-RK-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- New text: (Section 3.6.1) --------- Pastor, Morneault [Page 12] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 The format of the Routing Key parameter is as follows. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Local-RK-Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routing Context (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Traffic Mode Type (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- Old text: (Section 3.6.2) --------- Registration Status: 32-bit integer The Registration Result Status field indicates the success or the reason for failure of a registration request. Its values may be: 0 Successfully Registered 1 Error - Unknown 2 Error - Invalid DPC 3 Error - Invalid Network Appearance 4 Error - Invalid Routing Key 5 Error - Permission Denied 6 Error - Cannot Support Unique Routing Pastor, Morneault [Page 13] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 7 Error - Routing Key not Currently Provisioned 8 Error - Insufficient Resources 9 Error - Unsupported RK parameter Field 10 Error - Unsupported/Invalid Traffic Handling Mode --------- New text: (Section 3.6.2) --------- Registration Status: 32-bit integer The Registration Result Status field indicates the success or the reason for failure of a registration request. Its values may be: 0 Successfully Registered 1 Error - Unknown 2 Error - Invalid DPC 3 Error - Invalid Network Appearance 4 Error - Invalid Routing Key 5 Error - Permission Denied 6 Error - Cannot Support Unique Routing 7 Error - Routing Key not Currently Provisioned 8 Error - Insufficient Resources 9 Error - Unsupported RK parameter Field 10 Error - Unsupported/Invalid Traffic Handling Mode 11 Error - Routing Key Change Refused 12 Error - Routing Key Already Registered --------- Old text: (Section 4.4.1) --------- If the SGP determines that a unique Routing Key cannot be created, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing" An incoming signalling message received at an SGP should not match against more than one Routing Key. -------- New text: (Section 4.4.1) --------- If the SGP determines that the requested RK partially, but not exactly, matches an existing RK, and that an incoming signalling message received at an SGP could possibly match both the requested and the existing RK, the SGP returns a Registration Response message to the ASP, with a Registration Status of "Error - "Cannot Support Unique Routing. An incoming signalling message received at an SGP should not match against more than one Routing Key. Pastor, Morneault [Page 14] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 If the SGP determines that the received RK was already registered, fully and exactly, either statically or dynamically, by the sending ASP, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Routing Key Already Registered ". This error applies whether the Routing Key is Active or Inactive. For this error code, RC field in Registration Response message MUST be populated with the actual value of RC in SGP corresponding to the specified RK in Registration Request message. An ASP MAY modify an existing Routing Key by including a Routing Context parameter in the REG REQ. If the SGP determines that the Routing Context applies to an existing Routing Key the SG MAY adjust the existing Routing Key to match the new information provided in the Routing Key parameter. A Registration Response "ERR - Routing Key Change Refused" is returned if the SGP does not accept the modification of the Routing Key due to either it does not support the re-registration procedure or the specific RC does not exist. Otherwise if the change is accepted, a Registration Response "Successfully Registered" is returned. 3.6.3 Solution description The two cases, RK overlap and RK duplication, have been differentiated and explained in detail. The latter will use a new specific Error Code as defined above. Also the possibility of modification to a Routing Key is included with the addition of a new parameter in the REG REQ message and the corresponding explanation in the procedures section. 3.7 Dynamic Registration Support for Alias Point Code 3.7.1 Description of the problem There is no text regarding the support of an Alias Point Code configuration in the dynamic registration of Routing Keys. 3.7.2 Text changes to the document --------- Old text: (Section 3.6.1) --------- Destination Point Code: The Destination Point Code parameter is mandatory, and Identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. The format is the same as described for the Affected Destination parameter in the DUNA Pastor, Morneault [Page 15] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 message (See Section 3.4.1). Its format is: --------- New text: (Section 3.6.1) --------- Destination Point Code: The Destination Point Code parameter is mandatory, and Identifies the Destination Point Code of incoming SS7 traffic for which the ASP is registering. For an alias point code configuration, the DPC parameter would be repeated for each point code. The format is the same as described for the Affected Destination parameter in the DUNA message (See Section 3.4.1). Its format is: 3.7.3 Solution description The solution was to add some text to describe how an alias point code configuration could be supported with dynamic registration. 3.8 Auditing procedure and congestion state 3.8.1 Description of the problem The current description of the AUDIT procedure in regards to congestion state is not clear enough. When to send SCON is not completely specified. 3.8.2 Text changes to the document --------- Old text: (Section 3.3.1) --------- [...]. Where the SGP maintains the congestion status of the SS7 destination, and the SS7 destination is congested, the SGP MUST additionally respond with an SCON message before the DAVA or DRST message. If the SS7 destination is available and congested, the SGP MUST respond with an SCON message and then a DAVA message. If the SS7 destination is restricted and congested, the SGP MUST respond with an SCON message immediately followed by a DRST message. If the SGP has no information on the availability status of the SS7 destination, the SGP responds with a DUNA message, as it has no routing information to allow it to route traffic to this destination. --------- Pastor, Morneault [Page 16] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 New text: (Section 3.3.1) --------- [...]. Where the SGP maintains the congestion status of the SS7 destination, the SGP MUST additionally respond with an SCON message before the DAVA or DRST message. If the SS7 destination is available, the SGP MUST respond with an SCON message (indicating the appropriate congestion level) and then a DAVA message. If the SS7 destination is restricted, the SGP MUST respond with an SCON message (with the appropriate congestion level) immediately followed by a DRST message. If the SGP has no information on the availability status of the SS7 destination, the SGP responds with a DUNA message, as it has no routing information to allow it to route traffic to this destination. Where the SGP does not maintain the congestion status of the SS7 destination, the response to a DAUD message should always be only a DAVA, DRST or DUNA message as appropriate. --------- Old text: (Section 5.4) --------- 5.4 M3UA/MTP3-User Boundary Examples --------- New text: (Section 5.4, 5.5) --------- 5.4 Auditing examples 5.4.1 SG State: Uncongested / Available ASP SGP --- --- | -------- DAUD ---------> | | <------ SCON(0) -------- | | <------- DAVA ---------- | 5.4.2 SG state: Congested (Congestion Level=2) / Available ASP SGP --- --- | -------- DAUD ---------> | | <------ SCON(2) -------- | | <------- DAVA ---------- | Pastor, Morneault [Page 17] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 5.4.3 SG state: Unknown / Available ASP SGP --- --- | -------- DAUD ---------> | | <------- DAVA ---------- | 5.4.4 SG state: Unavailable ASP SGP --- --- | -------- DAUD ---------> | | <------- DUNA ---------- | 5.5 M3UA/MTP3-User Boundary Examples 3.8.3 Solution description Whenever a DAUD is received, it has to be responded with DAVA/DUNA/DRST message depending on the peer node's state. If the SGP has congestion control (i.e. no ITU international networks) an SCON message with the appropriate congestion level should precede to the DAVA/DRST messages upon a DAUD arrival. A new examples section has been added to show this behavior. 3.9 Response to an ASPIA message 3.9.1 Description of the problem It was not clear how to act in the following scenario: ASP SGP --- --- | ------ ASPIA (RC1)-----> | | <---- ASPIA Ack ------- | | -----DEREG REQ (RC1)---> | | <----DEREG RSP (RC1)---- | | -------ASPIA (RC1)-----> | Pastor, Morneault [Page 18] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 What should SG do? 3.9.2 Text changes to the document --------- Old text: (Section 4.3.4.4) --------- 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 M3UA 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. --------- New text: (Section 4.3.4.4) --------- When an ASP wishes to withdraw from receiving traffic within an AS, or the ASP wants to initiate the process of deactivation, the ASP sends an ASP Inactive message to the SGP or IPSP. An ASP Inactive message MUST be always responded by the peer (although other messages may be sent in the middle) in the following way: - If the ASP Inactive message contains a RC parameter and the corresponding RK is defined (by either static configuration or dynamic registration), the peer MUST respond with an ASP Inactive Ack message. - If the ASP Inactive message contains a RC parameter that is not defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with Error Code = "Invalid Routing Context". - If the ASP Inactive message does not contain a RC parameter and the RK is defined (by either static configuration or dynamic registration), the peer must turn the ASP/IPSP to ASP-INACTIVE state in all the ASes it serves and MUST respond with an ASP Inactive Ack message. - If the ASP Inactive message does not contain a RC parameter and the RK is not defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with Error Code = "No configured AS for ASP". Pastor, Morneault [Page 19] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 The action of sending the ASP Inactive message MAY be initiated at the ASP by an M-ASP_INACTIVE request primitive from Layer Management or MAY be initiated automatically by an M3UA 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. 3.9.3 Solution description A more detailed specification of the messages to be sent upon the reception of an ASPIA has been added to the Inactive Procedures Section. In response to the original question and according with the new text, the SG should send Error("Invalid Routing Context"). 3.10 INFO and DIAG parameter length 3.10.1 Description of the problem At the second interop a question was raised about accepting a length of 4 bytes for DIAG and INFO parameters. 3.10.2 Text changes to the document --------- Old text: (Section 3.4.1) --------- INFO String: variable length The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes. --------- New text: (Section 3.4.1) --------- INFO String: variable length The optional INFO String parameter can carry any meaningful UTF-8 [10] character string along with the message. Length of the INFO String parameter is from 0 to 255 octets. This means that No procedures are presently identified for its use but the INFO String MAY be used for debugging purposes. An INFO String with a zero length Pastor, Morneault [Page 20] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 parameter is not considered as an error (this means that the Length field in the TLV will be set to 4). --------- Old text: (Section 3.8.1) --------- Diagnostic Information: variable length When included, the optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. The Diagnostic information SHOULD contain the offending message. --------- New text: (Section 3.8.1) --------- Diagnostic Information: variable length When included, the optional Diagnostic information can be any information germane to the error condition, to assist in identification of the error condition. The Diagnostic information SHOULD contain the offending message. TheDiagnostic Information parameter with a zero length parameter is not considered as an error (this means that the Length field in the TLV will be set to 4). 3.10.3 Solution description It has been explicitly included the fact that a parameter with length zero is allowed. 3.11 IPSP stuff 3.11.1 Description of the problem At the 2nd M3UA Plugtest several concerns were raised about the non- interoperability of the two different IPSP exchanges defined in M3UA. 3.11.2 Text changes to the document --------- Old text: (Section 4.3) --------- Pastor, Morneault [Page 21] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 4.3 AS and ASP State Maintenance The M3UA layer 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 M3UA message distribution function. Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP maintains the state of remote IPSPs. For the purposes of the following procedures, only the SGP/ASP case is described but the SGP side of the procedures also apply to an IPSP sending traffic to an AS consisting of a set of remote IPSPs. --------- New text: (Section 4.3) --------- 4.3 AS and ASP/IPSP State Maintenance The M3UA layer 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 M3UA message distribution function. Similarly, where IPSPs use M3UA in a point-to-point fashion, the M3UA layer in an IPSP maintains the state of remote IPSPs. Two IPSP models are defined with regards to the number of messages that are needed to a IPSP state change. They are defined as follows: 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. In order to ensure interoperability, an M3UA implementation supporting IPSP communication MUST support IPSP SE model and MAY implement IPSP DE model. In section 4.3.1: ASP/IPSP States, only the SGP-ASP and the IPSP SE scenarios are described. For the IPSP DE model, both IPSPs MUST follow the SGP side of the SGP-ASP procedures. In section 4.3.2, only the SGP-ASP scenario is described. All of the procedures referring to an AS served by ASPs are also applicable to ASes served by IPSPs. Pastor, Morneault [Page 22] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 In section 4.3.3, only the Management procedures for the SGP-ASP scenario are described. The corresponding Management procedures for IPSPs are directly inferred. The remaining sections contain specific IPSP Considerations sub- sections. --------- Old text: (Section 4.3.1) --------- 4.3.1 ASP States The state of each remote ASP, in each AS that it is configured to operate, is maintained in the M3UA layer in the SGP. The state of a particular ASP in a particular AS changes due to events. The events include: * Reception of messages from the peer M3UA layer at the ASP; * Reception of some messages from the peer M3UA layer at other ASPs in the AS (e.g., ASP Active message indicating "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. The ASP state transition diagram is shown in Figure 3. The possible states of an ASP are: ASP-DOWN: The remote M3UA peer at the ASP is unavailable and/or the related SCTP association is down. Initially all ASPs will be in this state. An ASP in this state SHOULD NOT be sent any M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error messages. ASP-INACTIVE: The remote M3UA peer at the ASP is available (and the related SCTP association is up) but application traffic is stopped. In this state the ASP SHOULD NOT be sent any DATA or SSNM messages for the AS for which the ASP is inactive. ASP-ACTIVE: The remote M3UA peer at the ASP is available and application traffic is active (for a particular Routing Context or set of Routing Contexts). 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. Pastor, Morneault [Page 23] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 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 peer SCTP layer. --------- New text: (Section 4.3.1) --------- 4.3.1 ASP States The state of each remote ASP/IPSP, in each AS that it is configured to operate, is maintained in the peer M3UA layer (i.e. in the SGP or peer IPSP, respectively). The state of a particular ASP/IPSP in a particular AS changes due to events. The events include: * 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 "Override"); * Reception of indications from the SCTP layer; or * Local Management intervention. The ASP/IPSP state transition diagram is shown in Figure 3. The possible states of an ASP/IPSP are: 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 M3UA messages, with the exception of Heartbeat, ASP Down Ack and Error messages. 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). 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. Pastor, Morneault [Page 24] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 4.3.1) --------- Figure 4: ASP State Transition Diagram, per AS +--------------+ | | +----------------------| ASP-ACTIVE | | Other +-------| | | ASP in AS | +--------------+ | Overrides | ^ | | | ASP | | ASP | | Active | | Inactive | | | v | | +--------------+ | | | | | +------>| ASP-INACTIVE | | +--------------+ | ^ | ASP Down/ | ASP | | ASP Down / SCTP CDI/ | Up | | SCTP CDI/ SCTP RI | | v SCTP RI | +--------------+ | | | +--------------------->| ASP-DOWN | | | +--------------+ --------- New text: (Section 4.3.1) --------- The figure below shows the transitions for the ASP and IPSP cases. Figure 5: ASP/IPSP State Transition Diagram, per AS +--------------+ | | +----------------------| ASP-ACTIVE | | Other +-------| | | IPSP in AS | +--------------+ | Overrides | ^ | | | ASPAC/ | | ASPIA/ | |[ASPAC-Ack]| | [ASPIA-Ack] | | | v | | +--------------+ | | | | Pastor, Morneault [Page 25] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | +------>| ASP-INACTIVE | | | | | +--------------+ | ^ | ASPDN/ | | | ASPDN / [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ SCTP RI | | | SCTP RI | | v | +--------------+ | | | +--------------------->| ASP-DOWN | | | +--------------+ The transitions in brackets are just valid for the IPSP SE model communication while the rest are valid for both ASPs and IPSPs. --------- Old text: (Section 4.3.4.1.2) --------- Alternatively, an interchange of ASP Up messages from each end can be performed. This option follows the ASP state transition diagram. It would need four messages for completion. --------- New text: (Section 4.3.4.1.2) --------- Alternatively, when using IPSP DE model, an interchange of ASP Up messages from each end MUST be performed. Four messages are needed for completion. --------- Old text: (Section 4.3.4.3.1) --------- Alternatively, an interchange of ASP Active messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be activated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. --------- New text: (Section 4.3.4.3.1) Pastor, Morneault [Page 26] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Alternatively, when using IPSP DE model, an interchange of ASP Active messages from each end MUST be performed. Four messages are needed for completion. --------- Old text: (Section 4.3.4.4.1) --------- Alternatively, an interchange of ASP Inactive messages from each end can be performed. This option follows the ASP state transition diagram and gives the additional advantage of selecting a particular AS to be deactivated from each end. It is especially useful when an IPSP is serving more than one AS. It would need four messages for completion. --------- New text: (Section 4.3.4.4.1) --------- Alternatively, when using IPSP DE model, an interchange of ASP Inactive messages from each end MUST be performed. Four messages are needed for completion. --------- Old text: (Section 4.4.3) --------- The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered. --------- New text: (Section 4.4.3) --------- The Registration/Deregistration procedures work in the IPSP cases in the same way as in AS-SG cases. An IPSP may register an RK in the remote IPSP. An IPSP is responsible for deregistering the RKs that it has registered. For the IPSP SE model, it MAY be used one common RK for both IPSP participating in the communication using the Signaling Point Code granularity. It would basically consist of <OPC,DPC>. In the case of RC use, RCs SHOULD be previously agreed between both peers. Pastor, Morneault [Page 27] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.11.3 Solution description Text regarding procedures has been modified to explicitely include IPSP communication. A clear definition of both IPSP models has been included. Modifications in the ASP state machine have been done to also include the IPSP model. For interoperability purposes, IPSP SE model is mandated while DE model is allowed. 3.12 Messages and Streams 3.12.1 Description of the problem The relation between messages and what stream to use in order to send them is diffuse and spread all along the document. 3.12.2 Text changes to the document --------- Old text: (Section 1.4.7) --------- None. --------- New text: (Section 1.4.7) --------- The following rules MUST to be followed (see section 3.1.2): 1. DATA message is never sent on stream 0. 2. ASPSM, MGMT, RKM classes should be sent on stream 0 (Other than BEAT, BEAT ACK and NTFY messages) 3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be sent on any stream. 3.12.3 Solution description A clear specification of how messages should be sent is included in the corresponding section. 3.13 ASP Id for IPSP communication 3.13.1 Description of the problem When using the IPSP communication there is no way to dynamically exchange the ASP Identifier in both directions. Pastor, Morneault [Page 28] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.13.2 Text changes to the document --------- Old text: (Section 3.5.2) --------- The ASP Up Ack message contains the following parameters: INFO String (optional) The format for ASP Up Ack message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag =0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- New text: (Section 3.5.2) --------- The ASP Up Ack message contains the following parameters: ASP Identifier Optional INFO String Optional The format for ASP Up Ack message parameters is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x0011 | Length = 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASP Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag =0x0004 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / INFO String / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The optional ASP Identifier parameter is specifically useful for IPSP communication. In that case the IPSP answering the ASP Up message MAY Pastor, Morneault [Page 29] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 include its own ASP Identifier value. For AS-SG communication this parameter MUST NOT be used. 3.13.3 Solution Description By including the optional ASP Identifier in ASP Up message this can be achieved. In the AS-SG communication this optional parameter is not needed 3.14 n+k redundancy 3.14.1 Description of the problem The n+k redundancy is explained as a general model to use but there is no reference in the current AS state diagram and sometimes it is not clear when to use it. Also n+k as defined in the introduction is subject to multiple interpretations. 3.14.2 Text changes to the document --------- Old text: (Section 1.4.4.1) --------- The failover model supports an "n+k" redundancy model, where "n" ASPs is the minimum number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. A "1+1" active/backup redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no ASP redundancy. --------- New text: (Section 1.4.4.1) --------- The failover model supports an "n+k" redundancy model, where "n" ASPs is the number of redundant ASPs required to handle traffic and "k" ASPs are available to take over for a failed or unavailable ASP. Traffic SHOULD be sent after "n" ASPs are active. "k" ASPs MAY be either active at the same time as "n" or kept inactive until needed due to a failed or unavailable ASP. A "1+1" active/backup redundancy is a subset of this model. A simplex "1+0" model is also supported as a subset, with no ASP redundancy. Pastor, Morneault [Page 30] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 4.3.2) --------- AS-DOWN: The Application Server is unavailable. This state implies that all related ASPs are in the ASP-DOWN state for this AS. Initially the AS will be in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active (i.e., one or more related ASPs are in the ASP- INACTIVE state, but none in the ASP-ACTIVE state). The recovery timer T(r) is not running or has expired. AS-ACTIVE: The Application Server is available and application traffic is active. This state implies that at least one ASP is in the ASP-ACTIVE state. AS-PENDING: An active ASP has transitioned to ASP-INACTIVE or ASP- DOWN and it was the last remaining active ASP in the AS. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP. If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no alternative, the SGP may stops queuing messages and discards all previously queued messages. The AS will move to the AS-INACTIVE state if at least one ASP is in ASP-INACTIVE state, otherwise it will move to AS-DOWN state. Figure 5 shows an example AS state machine for the case where the AS/ASP data is preconfigured. For other cases where the AS/ASP configuration data is created dynamically, there would be differences in the state machine, especially at creation of the AS. Figure 5: AS State Transition Diagram +----------+ one ASP trans to ACTIVE +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<--- | | +----------+ \ +-------------+ ^ | \ Tr Expiry, ^ | | | \ at least one | | | | \ ASP in ASP-INACTIVE | | | | \ | | | | \ | | | | \ | | Pastor, Morneault [Page 31] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 one ASP | | all ASP \ one ASP | | Last ACTIVE trans | | trans to \ trans to | | ASP trans to to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE ASP- | | \ ACTIVE | | or ASP-DOWN INACTIVE| | \ | | (start Tr) | | \ | | | | \ | | | v \ | v +----------+ \ +-------------+ | | --| | | AS-DOWN | | AS-PENDING | | | | (queueing) | | |<----------------------------| | +----------+ Tr Expiry and no ASP +-------------+ in ASP-INACTIVE state) Tr = Recovery Timer For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the first successful REG REQ from an ASP. Another example is where the AS/ASP configuration data is not created until the first ASP successfully enters the ASP-ACTIVE state. In this case the AS-ACTIVE state is entered directly. --------- New text: (Section 4.3.2) --------- AS-DOWN: The Application Server is unavailable. This state implies that all the ASPs are in ASP-DOWN state. Initially the AS will be in this state. An Application Server is in the AS-DOWN state when it is removed from a configuration. AS-INACTIVE: The Application Server is available but no application traffic is active. One or more ASPs are in ASP-INACTIVE state and/or the number of ASPs in ASP-ACTIVE state has not reached n. The recovery timer T(r) is not running or has expired. AS-ACTIVE: The Application Server is available and application traffic is active. The AS moves to this state after being in AS- INACTIVE and getting n ASPs in ASP-ACTIVE state or, after reaching AS-ACTIVE and keeping one or more ASPs in ASP-ACTIVE state. When it is considered that one ASP is enough to handle traffic (smooth start), the AS in AS-INACTIVE MAY reach the AS-ACTIVE as soon as the first ASP moves to the ASP-ACTIVE state. Pastor, Morneault [Page 32] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to ASP-INACTIVE or ASP-DOWN. A recovery timer T(r) SHOULD be started and all incoming signalling messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the AS-ACTIVE state and all the queued messages will be sent to the ASP. If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP MAY stop queuing messages and discards all previously queued messages. The AS will move to the AS-INACTIVE state if at least the number of ASPs in ASP-INACTIVE sum n, otherwise it will move to AS-DOWN state. Figure 5 shows an example AS state machine for the case where the AS/ASP data is preconfigured and an n+k redundancy model. Figure 5: AS State Transition Diagram +----------+ IA2AC +-------------+ | AS- |---------------------------->| AS- | | INACTIVE | | ACTIVE | | |<----------- | | +----------+ \ +-------------+ ^ | \ ^ | | | IA2DN \ PN2IA | | AC2PN | | \ | | DN2IA | | \ PN2AC | | | v \ | v +----------+ \ +-------------+ | | ----------| | | AS-DOWN | | AS-PENDING | | | PN2DN | (queueing) | | |<----------------------------| | +----------+ +-------------+ DN2IA: One ASP moves from ASP-DOWN to ASP-INACTIVE state. IA2DN: The last ASP in ASP-INACTIVE moves to ASP-DOWN causing that the all the ASPs are in ASP-DOWN state. IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the ASP-ACTIVE state to be n. In a special case of smooth start, this transition MAY be done when the first ASP moves to ASP-ACTIVE state. AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP- DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1. Pastor, Morneault [Page 33] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 PN2AC: One ASP moves to ASP-ACTIVE. PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE. PN2DN: T(r) Expiry, all the ASPs are in ASP-DOWN state. An AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE state during the start-up phase (except for smooth start). Once the traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP turns to another state different to ASP-ACTIVE, avoiding unnecessary traffic disturbances as long as there are ASPs available, in the assumption that the system will not always be exposed to the maximum load. There are other cases where the AS/ASP configuration data is created dynamically. In those cases there would be differences in the state machine, especially at creation of the AS. For example, where the AS/ASP configuration data is not created until Registration of the first ASP, the AS-INACTIVE state is entered directly upon the nth successful REG REQ from an ASP belonging to that AS. Another example is where the AS/ASP configuration data is not created until the nth ASP successfully enters the ASP-ACTIVE state. In this latter case the AS-ACTIVE state is entered directly. --------- Old text: (Section 4.3.4.3, for both loadsharing and broadcast) --------- An SGP or IPSP, upon reception of an ASP Active message for the first ASP in a Loadshare AS, MAY choose not to direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. --------- New text: (Section 4.3.4.3, for both loadsharing and broadcast) --------- At start-up or re-start phases, an SGP or IPSP, upon reception of an ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active ASP until it determines that there are sufficient resources to handle the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are sufficient resources. Pastor, Morneault [Page 34] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.14.3 Solution description The AS state machine reflects the state changes as a function of the "n" number from the n+k redundancy configuration. This solution is compliance with the previous one: 1+0 model. The change from MAY to SHOULD NOT makes it recommendable to send traffic only when the require ASPs number are in ASP-ACTIVE state. 3.15 Multiple Parameters of the Same Type in a Message 3.15.1 Description of the problem There was some confusion about whether or not multiple parameters of same type were allowed in a message. 3.15.2 Text changes to the document --------- Old text: (Section 3.2) --------- Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. --------- New text: (Section 3.2) --------- Where more than one parameter is included in a message, the parameters may be in any order, except where explicitly mandated. A receiver SHOULD accept the parameters in any order. Unless explicitly stated or shown in a message format diagram, only one parameter of the same type is allowed in a message. 3.15.3 Solution Description Added a statement to clarify that multiple parameters of the same type are forbidden in messages unless explicitly allowed. 3.16 Registered Routing Key State After Unexpected ASP Up Message Received 3.16.1 Description of the problem Pastor, Morneault [Page 35] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 If the ASP unexpectedly sends an ASP Up message while in the ASP-ACTIVE state, it is not clear what the peer should do with registered Routing Keys. Should these Routing Keys be maintained as registered or should they be considered deregistered? 3.16.2 Text changes to the document --------- Old text: (Section 4.3.4.1) --------- If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as an Error message ("Unexpected Message), and the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers. --------- New text: (Section 4.3.4.1) --------- If an ASP Up message is received and internally the remote ASP is in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as, an Error message ("Unexpected Message). In addition, the remote ASP state is changed to ASP-INACTIVE in all relevant Application Servers and all registered Routing Keys are considered deregistered. 3.16.3 Solution Description Added a statement to clarify that registered Routing Keys will be considered deregistered if an unexpected ASP Up message is received while the ASP is in the ASP-ACTIVE state. This clarification ensures the two peers remain synchronized. 3.17 Location of Network Appearance 3.17.1 Description of the problem For the Payload Data message, it is clear that the Network Appearance, if included, MUST be the first parameter in the message. For the other messages that may contain Network Appearance, it is not so clear. 3.17.2 Text changes to the document --------- Old text: (Section 3.4.1) Pastor, Morneault [Page 36] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Network Appearance: 32-bit unsigned integer See Section 3.3.1 --------- New text: (Section 3.4.1) --------- Network Appearance: 32-bit unsigned integer The description of Network Appearance in Section 3.3.1 applies with the exception that Network Appearance does not have to be the first parameter in this message. --------- Old text: (Section 3.6.1) --------- Network Appearance: The optional Network Appearance parameter field identifies the SS7 network context for the Routing Key, and has the same format as in the DATA message (See Section 3.3.1). The absence of the Network Appearance parameter in the Routing Key indicates the use of any Network Appearance value. Its format is: --------- New text: (Section 3.6.1) --------- Network Appearance: The optional Network Appearance parameter field identifies the SS7 network context for the Routing Key, and has the same format as in the DATA message (See Section 3.3.1) with the exception that it does not have to be the first parameter in the message. The absence of the Network Appearance parameter in the Routing Key indicates the use of any Network Appearance value. Its format is: 3.17.3 Solution Description Add statements to clarify that Network Appearance, if present, does not have to be the first parameter in the message with the exception of the Payload Data message. 3.18 Determination of Congestion Abatement When ASP Sends SCON Pastor, Morneault [Page 37] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.18.1 Description of the problem Currently, there is no text in the RFC indicating that the ASP indicates when congestion has abated. 3.18.2 Text changes to the document --------- Old text: (Section 3.4.4) --------- The SCON message can be sent from an SGP to all concerned ASPs to indicate that an SG has determined that there is congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message as appropriate. For some MTP protocol variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 congestion level changes. The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA peer indicating that the M3UA layer or the ASP is congested. --------- New text: (Section 3.4.1) --------- The SCON message can be sent from an SGP to all concerned ASPs to indicate that an SG has determined that there is congestion in the SS7 network to one or more destinations, or to an ASP in response to a DATA or DAUD message as appropriate. For some MTP protocol variants (e.g., ANSI MTP) the SCON message may be sent when the SS7 congestion level changes. The SCON message MAY also be sent from the M3UA layer of an ASP to an M3UA peer indicating that the congestion level of the M3UA layer or the ASP has changed. IMPLEMENTATION NOTE: an M3UA node may maintain a timer to control congestion notification validity, if desired. This timer will be useful in those cases where the peer node fails to indicate congestion abatement. 3.18.3 Solution Description Clarify that the ASP needs to indicate when the congestion level has changed (including abatement). Further, the ASP peer can maintain a timer, if desired, in case the ASP fails to indicate congestion abatement. 3.19 Removing CIC and SSN from RK 3.19.1 Description of the problem Pastor, Morneault [Page 38] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Use of SSN and CIC Routing Keys is inadequately defined in RFC3332 leading to non-interoperable solutions. 3.19.2 Text changes to the document --------- Old text: (Section 1.4.2.1) --------- Possible SS7 address/routing information that comprise a Routing Key entry includes, for example, the OPC, DPC, SIO found in the MTP3 routing label, or MTP3-User specific fields (such as the ISUP CIC, SCCP subsystem number). Some example Routing Keys are: the DPC alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the DPC/SSN combination. The particular information used to define an M3UA Routing Key is application and network dependent, and none of the above examples are mandated. --------- New text: (Section 1.4.2.1) --------- Possible SS7 address/routing information that comprise a Routing Key entry includes, for example, the OPC, DPC, SIO found in the MTP3 routing label. Some example Routing Keys are: the DPC alone, the DPC/OPC combination, or the DPC/OPC/SI combination. The particular information used to define an M3UA Routing Key is application and network dependent, and none of the above examples are mandated. --------- Old text: (Section 1.4.2.2) --------- Routing Keys SHOULD be unique in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result. It is not necessary for the parameter range values within a particular Routing Key to be contiguous. For example, an AS should be configured to support call processing for multiple ranges of PSTN trunks that are not represented by contiguous CIC values. --------- New text: (Section 1.4.2.2) --------- Routing Keys SHOULD be unique in the sense that each received SS7 signalling message SHOULD have a full or partial match to a single routing result. It is not necessary for the parameter range values within a particular Routing Key to be contiguous. Pastor, Morneault [Page 39] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 1.4.7) --------- The M3UA layer at both the SGP and ASP also supports the assignment of signalling traffic into streams within an SCTP association. Traffic that requires sequencing SHOULD be assigned to the same stream. To accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 Routing Label or the ISUP CIC assignment, subject of course to the maximum number of streams supported by the underlying SCTP association. --------- New text: (Section 1.4.7) --------- The M3UA layer at both the SGP and ASP also supports the assignment of signalling traffic into streams within an SCTP association. Traffic that requires sequencing SHOULD be assigned to the same stream. To accomplish this, MTP3-User traffic may be assigned to individual streams based on, for example, the SLS value in the MTP3 Routing Label, subject of course to the maximum number of streams supported by the underlying SCTP association. --------- Old text: (Section 1.5.3) --------- For internal SGP modeling purposes, this may be accomplished with the use of an implementation-dependent nodal interworking function within the SGP that effectively sits below the SCCP and routes MTP-TRANSFER request/indication messages to/from both the MTP3 and the M3UA layer, based on the SS7 DPC or DPC/SSN address information. This nodal interworking function has no visible peer protocol with either the ASP or SEP. --------- New text: (Section 1.5.3) --------- For internal SGP modeling purposes, this may be accomplished with the use of an implementation-dependent nodal interworking function within the SGP that effectively sits below the SCCP and routes MTP-TRANSFER request/indication messages to/from both the MTP3 and the M3UA layer, based on the SS7 DPC or DPC/SI address information. This nodal interworking function has no visible peer protocol with either the ASP or SEP. Pastor, Morneault [Page 40] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 3.2) --------- Congestion Indications 0x0205 Concerned Destination 0x0206 Routing Key 0x0207 Registration Result 0x0208 Deregistration Result 0x0209 Local_Routing Key Identifier 0x020a Destination Point Code 0x020b Service Indicators 0x020c Reserved 0x020d Originating Point Code List 0x020e Circuit Range 0x020f Protocol Data 0x0210 Reserved 0x0211 Registration Status 0x0212 Deregistration Status 0x0213 --------- New text: (Section 3.2) --------- Congestion Indications 0x0205 Concerned Destination 0x0206 Routing Key 0x0207 Registration Result 0x0208 Deregistration Result 0x0209 Local_Routing Key Identifier 0x020a Destination Point Code 0x020b Service Indicators 0x020c Reserved 0x020d Originating Point Code List 0x020e Reserved 0x020f Protocol Data 0x0210 Reserved 0x0211 Registration Status 0x0212 Deregistration Status 0x0213 --------- Old text: (Section 3.6.1) --------- | Traffic Mode Type (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pastor, Morneault [Page 41] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | Network Appearance (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Range List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note: The Destination Point Code, Service Indicators, Originating Point Code List and Circuit Range List parameters MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above. --------- New text: (Section 3.6.1) --------- | Traffic Mode Type (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Appearance (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ \ / ... / \ \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Point Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Indicators (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originating Point Code List (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pastor, Morneault [Page 42] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Note: The Destination Point Code, Service Indicators, and Originating Point Code List parameters MAY be repeated as a grouping within the Routing Key parameter, in the structure shown above. --------- Old text: (Section 3.6.1) --------- Circuit Range: An ISUP controlled circuit is uniquely identified by the SS7 OPC, DPC and CIC value. For the purposes of identifying Circuit Ranges in an M3UA Routing Key, the optional Circuit Range parameter includes one or more circuit ranges, each identified by an OPC and Upper/Lower CIC value. The DPC is implicit as it is mandatory and already included in the DPC parameter of the Routing Key. The absence of the Circuit Range parameter in the Routing Key indicates the use of any Circuit Range values, in the case of ISUP/TUP traffic. The Origination Point Code is encoded the same as the Destination Point Code parameter, while the CIC values are 16-bit integers. --------- New text: (Section 3.6.1) --------- (none) --------- Old text: (Section 3.6.1) --------- The Circuit Range format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag = 0x020f | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask = 0 | Origination Point Code #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower CIC Value #1 | Upper CIC Value #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mask = 0 | Origination Point Code #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower CIC Value #2 | Upper CIC Value #2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ... / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pastor, Morneault [Page 43] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | Mask = 0 | Origination Point Code #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower CIC Value #n | Upper CIC Value #n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------- New text: (Section 3.6.1) --------- (none) --------- Old text: (Section 3.7.1) --------- An Application Server Process may be configured to process traffic for more than one logical Application Server. From the perspective of an ASP, a Routing Context defines a range of signalling traffic that the ASP is currently configured to receive from the SGP. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signalling traffic, identified by separate SS7 DPC/OPC/CIC ranges. --------- New text: (Section 3.7.1) --------- An Application Server Process may be configured to process traffic for more than one logical Application Server. From the perspective of an ASP, a Routing Context defines a range of signalling traffic that the ASP is currently configured to receive from the SGP. For example, an ASP could be configured to support call processing for multiple ranges of PSTN trunks and therefore receive related signalling traffic, identified by separate SS7 DPC/OPC/SI ranges. --------- Old text: (Section 4.4.1) --------- If an SGP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Unsupported RK parameter field". This result MAY be used if, for example, the SGP does not Pastor, Morneault [Page 44] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 support RK Circuit Range Lists in a Routing Key because the SGP does not support ISUP traffic, or does not provide CIC range granularity. --------- New text: (Section 4.4.1) --------- If an SGP determines that one or more of the Routing Key parameters are not supported for the purpose of creating new Routing Key entries, the SGP returns a Registration Response message to the ASP, containing a Registration Result "Error - Unsupported RK parameter field". --------- Old text: (Section A.2.1) --------- For example, where Application Servers are defined using ranges of ISUP CIC values, the Operator is implicitly splitting up control of the related circuit groups. Some CIC value range assignments may interfere with ISUP circuit group management procedures. --------- New text: (Section A.2.1) --------- (none) 3.19.3 Solution Description The removal of reference to SSN and CIC used in Routing Keys as well as removal of Circuit Range from the Routing Key parameter removes the unclear text from the specification. 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity 3.20.1 Description of the problem There is not explicit text explaining how the protocol should work for the case when an ASP comes to ASP-ACTIVE state and there exist some problems in the SS7 network that prevent it to have full connectivity. 3.20.2 Text changes to the document Pastor, Morneault [Page 45] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- Old text: (Section 4.5.1) --------- The SGP M3UA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular network appearance are informed. If the SGP operates within a single SS7 network appearance, then all ASPs are informed. DUNA, DAVA, SCON, and DRST messages may be sent sequentially and processed at the receiver in the order sent. --------- New text: (Section 4.5.1) --------- The SGP M3UA layer determines the set of concerned ASPs to be informed based on the specific SS7 network for which the primitive indication is relevant. In this way, all ASPs configured to send/receive traffic within a particular network appearance are informed. If the SGP operates within a single SS7 network appearance, then all ASPs are informed. For the particular case that an ASP becomes active for an AS and destinations normally accessible to the AS are inaccessible, restricted or congested, the SG MAY send DUNA, DRST or SCON messages for the inaccessible, restricted or congested destinations to the ASP newly active for the AS to prevent the ASP from sending traffic for destinations that it might otherwise not know that are inaccessible, restricted or congested. DUNA, DAVA, SCON, and DRST messages may be sent sequentially and processed at the receiver in the order sent. --------- Old text: (Section 4.6) --------- Pastor, Morneault [Page 46] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. This would be for example the case when an AS becomes active at an ASP and does not have current destination statuses. If MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it received an indication that the destination became available or restricted. In the IPSP case, MTP restart could be considered if the IPSP also has connection to an SS7 network. [...] --------- New text: (Section 4.6) --------- The ASP MAY choose to audit the availability of unavailable destinations by sending DAUD messages. This would be for example the case when an AS becomes active at an ASP and does not have current destination statuses. If MTP restart is in progress at the SG, the SGP returns a DUNA message for that destination, even if it received an indication that the destination became available or restricted. When an ASP becomes active for an AS and the SG is experiencing SS7 network isolation or is performing the MTP Restart procedure for the AS, the SG MAY send a DUNA message for the concerned destinations to the newly active ASP to prevent the ASP from sending traffic. In the IPSP case, MTP restart could be considered if the IPSP also has connection to an SS7 network. [...] 3.20.3 Solution Description By specifying how send SSNM messages in that scenario the problem is solved. 3.21 NOTIFY messages are missing in Examples section 3.21.1 Description of the problem There are some mandatory NOTIFY messages missing in section 5 in the RFC. 3.21.2 Text changes to the document --------- Old text: (Section 5) Pastor, Morneault [Page 47] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- NOTE: Not all the Notify messages that are appropriate per the Notify procedures are shown in these examples. --------- New text: (Section 5) --------- - --------- Old text: (Section 5.1.1.1) --------- SGP ASP1 | | |<-------------ASP Up-----------| |-----------ASP Up Ack--------->| | | |<------- ASP Active(RCn)-------| RC: Routing Context |-----ASP Active Ack (RCn)----->| (optional) | | |-----NTFY(AS-ACTIVE)(RCn)----->| | | --------- New text: (Section 5.1.1.1) --------- SGP ASP1 | | |<-------------ASP Up-----------| |-----------ASP Up Ack--------->| | | |-----NTFY(AS-INACTIVE)(RCn)--->| | | |<------- ASP Active(RCn)-------| RC: Routing Context |-----ASP Active Ack (RCn)----->| (optional) | | |-----NTFY(AS-ACTIVE)(RCn)----->| | | --------- Old text: (Section 5.1.1.2) --------- Pastor, Morneault [Page 48] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing | | Context |----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key | | RC: Routing Context | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | |-----NTFY(AS-ACTIVE)(RCn)----->| | | --------- New text: (Section 5.1.1.2) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | | | |<----REGISTER REQ(LRCn,RKn)----| LRC: Local Routing | | Key Id |----REGISTER RESP(LRCn,RCn)--->| RK: Routing Key | | RC: Routing Context |----NTFY(AS-INACTIVE)(RCn)---->| | | | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | |-----NTFY(AS-ACTIVE)(RCn)----->| | | --------- Old text: (Section 5.1.1.3) --------- SGP ASP1 Pastor, Morneault [Page 49] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing | | Context |----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key | | RC: Routing Context | | |<------- ASP Active(RC1)-------| |-----ASP Active Ack (RC1)----->| | | | | |<----REGISTER REQ(LRCn,RKn)----| | | |----REGISTER RESP(LRCn,RCn)--->| | | | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | --------- New text: (Section 5.1.1.3) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<----REGISTER REQ(LRC1,RK1)----| LRC: Local Routing | | Key Id |----REGISTER RESP(LRC1,RC1)--->| RK: Routing Key | | RC: Routing Context |---NOTIFY(AS-INACTIVE)(RC1)--->| | | | | |<------- ASP Active(RC1)-------| |-----ASP Active Ack (RC1)----->| | | |----NOTIFY(AS-ACTIVE)(RC1)---->| | | ~ ~ | | |<----REGISTER REQ(LRCn,RKn)----| | | |----REGISTER RESP(LRCn,RCn)--->| Pastor, Morneault [Page 50] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | | | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | |----NOTIFY(AS-ACTIVE)(RCn)---->| | | --------- Old text: (Section 5.1.1.4) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | |<---REGISTER REQ({LRC1,RK1},---| | ..., | | {LRCn,RKn}),--| | | |---REGISTER RESP({LRC1,RC1},-->| | ..., | | (LRCn,RCn}) | | | |<------- ASP Active(RC1)-------| |-----ASP Active Ack (RC1)----->| | | : : : : | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | --------- New text: (Section 5.1.1.4) --------- SGP ASP1 | | |<------------ASP Up------------| |----------ASP Up Ack---------->| | | | | |<---REGISTER REQ({LRC1,RK1}, | | ..., | Pastor, Morneault [Page 51] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 | {LRCn,RKn}),--| | | |---REGISTER RESP({LRC1,RC1},-->| | ..., | | (LRCn,RCn}) | | | |--NTFY(AS-INACTIVE)(RC1..RCn)->| | | | | |<------- ASP Active(RC1)-------| |-----ASP Active Ack (RC1)----->| | | |----NOTIFY(AS-ACTIVE)(RC1)---->| | | : : : : | | |<------- ASP Active(RCn)-------| |-----ASP Active Ack (RCn)----->| | | |----NOTIFY(AS-ACTIVE)(RCn)---->| | | --------- Old text: (Section 5.1.2) --------- SGP ASP1 ASP2 | | | |<--------ASP Up---------| | |-------ASP Up Ack------>| | | | | |<----------------------------ASP Up----------------| |----------------------------ASP Up Ack------------>| | | | | | | |<-------ASP Active------| | |------ASP Active Ack--->| | | | | --------- New text: (Section 5.1.2) --------- Pastor, Morneault [Page 52] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 SGP ASP1 ASP2 | | | |<--------ASP Up---------| | |-------ASP Up Ack------>| | | | | |--NOTIFY(AS-INACTIVE)-->| | | | | |<----------------------------ASP Up----------------| |----------------------------ASP Up Ack------------>| | | | | | | |<-------ASP Active------| | |------ASP Active Ack--->| | | | | |---NOTIFY(AS-ACTIVE)--->| | |--------------------------NOTIFY(AS-ACTIVE)------->| | | | --------- Old text: (Section 5.1.3) --------- OLD: SGP ASP1 ASP2 | | | |<---------ASP Up--------| | |--------ASP Up Ack----->| | | | | |<-----------------------------ASP Up---------------| |----------------------------ASP Up Ack------------>| | | | | | | |<--ASP Active (Ldshr)---| | |-----ASP-Active Ack---->| | | | | |---------------------------NOTIFY (AS-ACTIVE------>| | | | |<---------------------------ASP Active (Ldshr)-----| |------------------------------ASP Active Ack------>| | | | --------- New text: (Section 5.1.3) --------- Pastor, Morneault [Page 53] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 SGP ASP1 ASP2 | | | |<---------ASP Up--------| | |--------ASP Up Ack----->| | | | | |--NOTIFY(AS-INACTIVE)-->| | | | | |<-----------------------------ASP Up---------------| |----------------------------ASP Up Ack------------>| | | | |<--ASP Active (Ldshr)---| | |-----ASP-Active Ack---->| | | | | |---NOTIFY (AS-ACTIVE)-->| | |-----------------------------NOTIFY(AS-ACTIVE)---->| | | | |<---------------------------ASP Active (Ldshr)-----| |------------------------------ASP Active Ack------>| | | | --------- Old text: (Section 5.1.4) --------- SGP ASP1 ASP2 ASP3 | | | | |<------ASP Up------| | | |-----ASP Up Ack--->| | | | | | | |<-------------------------ASP Up-------| | |------------------------ASP Up Ack---->| | | | | | |<--------------------------------------------ASP Up--------| |--------------------------------------------ASP Up Ack---->| | | | | | | | | |<--ASP Act (Ldshr)-| | | |----ASP Act Ack--->| | | | | | | | | | | |<-------------------ASP Act. (Ldshr)---| | |----------------------ASP Act Ack----->| | | | | | |---------Notify (AS-ACTIVE)----------->| | |----------------------Notify (AS-ACTIVE)------------------>| Pastor, Morneault [Page 54] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- New text: (Section 5.1.4) --------- SGP ASP1 ASP2 ASP3 | | | | |<------ASP Up------| | | |-----ASP Up Ack--->| | | | | | | |<-------------------------ASP Up-------| | |------------------------ASP Up Ack---->| | | | | | |NTFY(AS-INACTIVE)->| | | |------------------NOTIFY(AS-INACTIVE)->| | | | | | |<--------------------------------------------ASP Up--------| |--------------------------------------------ASP Up Ack---->| | | | | | | | | |<--ASP Act (Ldshr)-| | | |----ASP Act Ack--->| | | | | | | | | | | |<-------------------ASP Act. (Ldshr)---| | |----------------------ASP Act Ack----->| | | | | | |--NTFY(AS-ACTIVE)->| | | |--------------------NOTIFY(AS-ACTIVE)->| | |----------------------------------------NOTIFY(AS-ACTIVE)->| | | | | | | | | --------- Old text: (Section 5.2.3) --------- SGP ASP1 ASP2 ASP3 | | | | |<----ASP Inact.----| | | |---ASP Inact Ack-->| | | | | | | |--------------------------------NTFY(Ins. ASPs)----------->| | | | | |<----------------------------------------ASP Act (Ldshr)---| |------------------------------------------ASP Act (Ack)--->| | | | | Pastor, Morneault [Page 55] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- New text: (Section 5.2.3) --------- SGP ASP1 ASP2 ASP3 | | | | |<----ASP Inact.----| | | |---ASP Inact Ack-->| | | | | | | |--NTFY(Ins. ASPs)->| | | |---------------------------------------NOTIFY(Ins. ASPs)-->| | | | | | | | | |<----------------------------------------ASP Act (Ldshr)---| |------------------------------------------ASP Act (Ack)--->| | | | | |-NTFY(AS-ACTIVE)-->| | | |-------------------NOTIFY(AS-ACTIVE)-->| | |---------------------------------------NOTIFY(AS-ACTIVE)-->| | | | | | | | | 3.21.3 Solution Description By specifying all the mandatory NOTIFY messages in the drawing, we solve the problem. 3.22 Sending NTFY after sending ASP-UP-ACK 3.22.1 Description of the problem When an ASP comes from ASP-DOWN to ASP-INACTIVE for a particular AS, the ASP does not know anything about the state of the AS. 3.22.2 Text changes to the document --------- Old text: (Section 4.3.4.5) --------- Pastor, Morneault [Page 56] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). --------- New text: (Section 4.3.4.5) --------- A Notify message reflecting a change in the AS state MUST be sent to all ASPs in the AS, except those in the ASP-DOWN state, with appropriate Status Information and any ASP Identifier of the failed ASP. At the ASP, Layer Management is informed with an M-NOTIFY indication primitive. The Notify message must be sent whether the AS state change was a result of an ASP failure or reception of an ASP State management (ASPSM) / ASP Traffic Management (ASPTM) message. In the second case, the Notify message MUST be sent after any related acknowledgement messages (e.g., ASP Up Ack, ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). When an ASP moves from ASP-DOWN to ASP-INACTIVE within a particular AS, a Notify message SHOULD be sent, by the ASP-UP receptor, after sending the ASP-UP-ACK, in order to inform the ASP of the current AS state. 3.22.3 Solution Description By specifying how to update the AS state in an ASP when it moves from ASP-DOWN to ASP-INACTIVE, the problem is solved. 3.23 Re-registration after failure 3.23.1 Description of the problem Given the following scenario: ASP SG -------- ---------- REG REQ (RK1) ---------> <--------- REG RSP (success, rc=2) Pastor, Morneault [Page 57] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 [ASP goes down, then comes back up] REG REQ (RK1) ---------> <--------- REG RSP (error - routing key already reg, rc=2) It is important to note that the REG RSP (error-routing key already registered) MUST contain the Routing Context to ensure both sides are in-sync. 3.23.2 Text changes to the document --------- Old text: (Section 4.4.1) --------- None. --------- New text: (Section 4.4.1) --------- If an SGP determines that a received Routing Key is already registered, the SG returns a Registration Response message to the ASP, containing a Registration Result "Error - - routing key already registered" and also the RC value previously assigned. 3.23.3 Solution Description By specifying that RC must be present in the response message when the routing key is registered, the problem is solved. 3.24 No Configured AS Error 3.24.1 Description of the problem During the third M3UA Plugtest there was a stated preference to allow the SG to return Error ("no AS configured") in response to ASP Active (RC) when RC is not configured. 3.24.2 Text changes to the document --------- Pastor, Morneault [Page 58] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Old text: (Section 3.8.1) --------- The "Invalid Routing Context" error is sent if a message is received from a peer with an invalid (unconfigured) Routing Context value. For this error, the invalid Routing Context(s) MUST be included in the Error message. The "No Configured AS for ASP" error is sent if a message is received from a peer without a Routing Context parameter and it is not known by configuration data which Application Servers are referenced. --------- New text: (Section 3.8.1) --------- The "Invalid Routing Context" error is sent if a message, other than ASP-Active, is received from a peer with an invalid Routing Context value. The invalid Routing Context(s) MUST be included in the Error message. The "No Configured AS for ASP" error is sent if a message is received from a peer without a Routing Context parameter and it is not known by configuration data which Application Servers are referenced. This error is also sent when an ASP-Active message is received with an unconfigured RC and the invalid Routing Context(s) MUST be then included in the Error message. --------- Old text: (Section 4.3.4.3) --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. The SGP or IPSP MUST send an Error message ("Invalid Routing Context") for each Routing Context value that the ASP cannot be successfully activated . --------- New text: (Section 4.3.4.3) --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. The SGP or IPSP MUST send an Pastor, Morneault [Page 59] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Error message ("No Configured AS for ASP ") for each Routing Context value that the ASP cannot be successfully activated . 3.24.3 Solution Description Specifying how to use the specific error codes with the ASP-Active message solves the problem. 3.25 NIF not available on SGP 3.25.1 Description of the problem How to handle NIF Unavailable was removed from IGv05. There is a suggestion that we specify how to handle this situation in the IG 3.25.2 Text changes to the document --------- New text: (Section 4.7) --------- IMPLEMENTATION NOTE: Although the NIF is decided to be an implementation dependent function, here there are some guidelines that may be useful to follow: - If the SG (all the SGPs) is isolated from the NIF, then all the users are isolated from the SS7 network. A DUNA(*) message may be sent from the SGPs to all the ASPs. - If only one SGP in the SG is isolated entirely from the NIF, the SGP may 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 may 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). 3.25.3 Solution Description As it is agreed that the NIF is an implementation dependent function, the new text can be included in an IMPLEMENTATION NOTE clause. The Pastor, Morneault [Page 60] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 text included is from the conclusions of the mailing list discussions. In this way it is not normative text, but it may be used as a guideline. 3.26 Notify(ASP-Failure) usage clarification 3.26.1 Description of the problem Clarify text as to when Notify (ASP Failure) must be sent. Is it upon failure (SCTP association fails) or any transition to ASP-DOWN state? 3.26.2 Text changes to the document --------- Old text: (3.8.2) --------- These notifications are not based on the SGP reporting the state change of an ASP or AS. In the Insufficient ASP Resources case, the SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is required to handle the load of the AS (Loadsharing or Broadcast mode). For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has transitioned to ASP-DOWN. The ASP Identifier (if available) of the failed ASP MUST be placed in the message. --------- New text: (3.8.2) --------- These notifications are not based on the SGP reporting the state change of an ASP or AS. - In the Insufficient ASP Resources case, the SGP is indicating to an ASP_INACTIVE ASP in the AS that another ASP is required to handle the load of the AS (Loadsharing or Broadcast mode). - For the Alternate ASP Active case, an ASP is informed when an alternate ASP transitions to the ASP-ACTIVE state in Override mode. The ASP Identifier (if available) of the Alternate ASP MUST be placed in the message. - For the ASP Failure case, the SGP is indicating to ASP(s) in the AS that one of the ASPs has failed. The ASP Identifier (if available) of the failed ASP MUST be placed in the message. Pastor, Morneault [Page 61] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 3.26.3 Solution description It has been changed the sentence "transitioned to ASP-DOWN" to "failed" to stress that the ASP failure is the reason of this notification. 3.27 Alignment of ASP Active message with ASP Inactive message 3.27.1 Description of the problem It is suggested to align the wording in these two sections to avoid misunderstandings and specify the response to these messages in all cases. 3.27.2 Text changes to the document --------- Old text: (Section 4.3.4.3) --------- In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member. --------- New text: (Section 4.3.4.3) --------- In the case where an ASP Active message does not contain a Routing Context parameter, the receiver must know, via configuration data, which Application Server(s) the ASP is a member and move the ASP to the ASP-ACTIVE state in all Application Servers. --------- Old text: (Section 4.3.4.3) --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. The SGP or IPSP MUST send an Error message ("Invalid Routing Context") for each Routing Context value that the ASP cannot be successfully activated . In the case where an "out-of-the-blue" ASP Active message is received (i.e., the ASP has not registered with the SG or the SG has no static configuration data for the ASP), the message MAY be silently Pastor, Morneault [Page 62] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 discarded. The SGP MUST send an ASP Active Ack message in response to a received ASP Active message from the ASP, if the ASP is already marked in the ASP-ACTIVE state at the SGP. --------- New text: (Section 4.3.4.3) --------- Multiple ASP Active Ack messages MAY be used in response to an ASP Active message containing multiple Routing Contexts, allowing the SGP or IPSP to independently acknowledge the ASP Active message for different (sets of) Routing Contexts. The ASP Active message will be responded in the following way as a function of the presence/need of the RC parameter: - If the RC parameter is included in the ASP Active message and the corresponding RK has been previously defined (by either static configuration or dynamic registration), the peer node MUST respond with an ASP Active Ack message if it is ready to handle traffic; otherwise it will not respond (meaning that it is not ready to become active). This is valid for either: ASP was in ASP-ACTIVE or ASP-INACTIVE states. - If the RC parameter is included in the ASP Active message and a corresponding RK has not been previously defined (by either static configuration or dynamic registration), the peer MUST respond with an ERROR message with Error Code = "No configured AS for ASP". - If the RC parameter is not included in the ASP Active message, there are RKs defined (by either static configuration or dynamic registration) and RC is not mandatory, the peer node SHOULD respond with an ASP Active Ack message and activate all the RKs it has defined for that specific ASP. - If the RC parameter is not included in the ASP Active message, there are RKs defined (by either static configuration or dynamic registration) and RC is mandatory, the peer node MUST respond with and ERROR message with the Error Code = "Missing Parameter". - If the RC parameter is not included in the ASP Active message, there are RKs defined (by either static configuration or dynamic registration) and RC is not mandatory, the peer node MUST respond with an ASP Active Ack message if it is ready to handle traffic; otherwise it will not respond (meaning that it is not ready to become active). Pastor, Morneault [Page 63] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 - If the RC parameter is not included in the ASP Active message and there are no RKs defined, the peer node SHOULD respond with and ERROR message with the Error Code = "No configured AS for ASP". 3.27.3 Solution Description The text changes include similar wording in both sections. 3.28 Invalid Version parameter explanation 3.28.1 Description of the problem There is a typo in the current RFC within the ERROR message sub- section. "Invalid Stream identifier" parameter is explained twice while the "Invalid Version" is not even mentioned. 3.28.2 Text changes to the document --------- Old text: (Section 3.8.1) --------- The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid. --------- New text: (Section 3.8.1) --------- The Error message is used to notify a peer of an error event associated with an incoming message. For example, the message type might be unexpected given the current state, or a parameter value might be invalid. Error messages MUST NOT be generated in response to other Error messages. --------- Old text: (Section 3.8.1) --------- The "Invalid Stream Identifier" error is sent if a message is received on an unexpected SCTP stream (e.g., a MGMT message was received on a stream other than "0"). Error messages MUST NOT be generated in response to other Error messages. --------- New text: (Section 3.8.1) Pastor, Morneault [Page 64] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 --------- The "Invalid Version" error is sent if a message with an unsupported version is received, the receiving end responds with an Error message, indicating the version the receiving node supports and notifies layer management. 3.28.3 Solution Description The duplicated text has been substituted by an explanation of the missing parameter "Invalid Version". Also, the last sentence next to the duplicated text has been moved to the beginning of the section 3.8.1. Pastor, Morneault [Page 65] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 4. Acknowledgements The authors would like to thank Lyndon Ong, Tolga Asveren, Brian Bidulock, Umesh Vats, Barry Nagelberg, Samuel Dur D. Jeyaseelan, Antonio Canete, Kamesh Kaul, Vivek Toky and many others for their valuable comments and suggestions. 5. Authors' Addresses Javier Pastor-Balbas Ericsson Espana S.A. Via de los Poblados 13 28033 Madrid Spain Phone: +34-91-339-1397 Email: j.javier.pastor@ericsson.com Ken Morneault Cisco Systems Inc. 13615 Dulles Technology Drive Herndon, VA. 20171 USA Phone: +1-703-484-3323 EMail: kmorneau@cisco.com 6. References [RFC3332] "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) - User Adaptation Layer (M3UA)". G. Sidebotton, K. Morneault, J. Pastor-Balbas. Pastor, Morneault [Page 66] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 7. Changes Control 7.1 Changes from v00 to v01 - Typos. - Update all the RC references to show it is a semi-optional parameter. - DUNA(*) substituted for ASPIA-ACK when NIF is not available. - New sections added: - IPSP stuff - Messages and Streams - ASP Id for IPSP communication - n+k redundancy 7.2 Changes from v01 to v02 - ASPIA-ACK substituted for DUNA when NIF is not available since it also allows inter-ASP routing. - Changed REGREQ's parameter from "Origination Point Code" to "Destination Point Code". 7.3 Changes from v02 to v03 - Changed from "semi-optional" to "conditional"- Section 3.7 reworded - Updated Section 3.8 to correctly explain how the alias point code configuration can be supported with dynamically registered Routing Keys - Changes in "messages and streams" section - IPSP DE model is allowed. But IPSP SE MUST be supported. - New sections added: - Multiple Parameters of the Same Type in a Message - Registration Routing Key State After Unexpected ASP Up Message - Location of Network Appearance - Determination of Congestion Abatement When ASP Sends SCON - Removing CIC and SSN from RK - ASP comes to ASP-ACTIVE state without full SS7 connectivity 7.4 Changes from v03 to v04 Pastor, Morneault [Page 67] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 - Removed NIF section and left it as implementation dependant. There is now plenty of discussion in the email archive to make an informed decision on how to handle NIF isolation. - Section 3.15 updated (now it is section 3.14) - Current section 3.19 about removing CIC and SSN from the RK: "Reserved 0x020f" Parameter Tag Code has been added (that was the CIC Code) - New Section to fix lack of NOTIFY messages in Examples section. It is section 3.21. 7.5 Changes from v04 to v05 - In section 3.8: Fix of example 5.4.1 - In section 3.9: Answer the problem in the Solution section in a explicitly way - In section 3.6: Add new error code that covers the case for Routing Key already registered - In section 3.14 the requirement to get "n" ASPs is only applicable when the AS moves from AS-INACTIVE to AS-ACTIVE - In section 3.18: Add Implementation note to regarding the timer - In section 3.20: Add Implementation note to regarding the timer - In section 3.21: Modify the example 5.2.3 to show the conclusions from section 3.14 in this IG. - New section 3.22: Include the recommendation of sending NTFY message after an ASP moves from ASP-DOWN to ASP-INACTIVE for a particular AS to inform it of the current state of the AS. 7.6 Changes from v05 to v06 - In section 3.9: reworked for clarification. All possible cases included. Also the section where the changes are, has been corrected. - In section 3.22: typos corrected - New section 3.27: Alignment of ASP Active message with ASP Inactive message detailing what response to send in all possible cases. Pastor, Morneault [Page 68] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Output from the plugtest: - New section 3.23: For re-registration after failure the REG RSP (error-routing key already registered) MUST contain the Routing Context to ensure both sides are in-sync. - New section 3.24: there is a stated preference to allow the SG to return Error ("no AS configured") in response to ASP Active (RC) when RC is not configured - New section 3.25: NIF section removed with the change to version 4 is included again but as an implementation note instead of normative text. - New section 3.26: Clarifies the Notify(ASP-Failure) usage. 7.7 Changes from v06 to v07 - In section 3.5: NA parameter is labeled as conditional. - In section 3.6: reworked for clarification. Stating clearly the difference of registering a duplicate RK versus an overlapping RK. - New section 3.6: Solves a typo in the RFC removing a duplicated paragraph and including the "invalid version" parameter explanation in the ERROR message. Pastor, Morneault [Page 69] INTERNET-DRAFT M3UA IMPLEMENTORĘS GUIDE February, 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pastor, Morneault [Page 70] | ||||||||||||||||
Last modified: Mon, 26 Aug 2024 23:50:04 GMT Copyright Ā© 2014 OpenSS7 Corporation All Rights Reserved. |