draft-ietf-sigtran-m3ua-implementors-guide-02.txt   draft-ietf-sigtran-m3ua-implementors-guide-03.txt 
Network Working Group Javier Pastor-Balbas Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: April 2003 Expires: August 2003
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
October, 2002 February, 2003
M3UA Implementor's Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-02.txt> <draft-ietf-sigtran-m3ua-implementors-guide-03.txt>
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments This document is an individual submission to the IETF. Comments
should be directed to the authors. should be directed to the authors.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
October 2002 for M3UA [RFC3332]. These defects may be of an editorial October 2002 for M3UA [RFC3332]. These defects may be of an editorial
or technical nature. This document may be thought of as a companion or technical nature. This document may be thought of as a companion
document to be used in the implementation of M3UA to clarify errors document to be used in the implementation of M3UA to clarify errors
in the original M3UA document. This document updates RFC3332 and text in the original M3UA document. This document updates RFC3332 and text
within this document supersedes the text found in RFC3332. within this document supersedes the text found in RFC3332.
TABLE OF CONTENTS TABLE OF CONTENTS
1.Introduction........................................................3 1. Introduction.......................................................3
2.Conventions.........................................................3 1.1 Abbreviations.....................................................3
3.Corrections to RFC-M3UA.............................................3 2. Conventions........................................................3
3. Corrections to RFC3332.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes..............3 3.1 Parameter Containing Subparameters with Padding Bytes..............3
3.2 Dynamic Registration Not Supported.................................4 3.2 Dynamic Registration Not Supported.................................4
3.3 Contents of User Protocol Data.....................................6 3.3 Contents of User Protocol Data.....................................6
3.4 NIF Not Available on SGP...........................................7 3.4 NIF Not Available on SGP...........................................7
3.5 Scope of Network Appearance........................................8 3.5 Scope of Network Appearance........................................8
3.6 Semi-optional RC parameter.........................................9 3.6 Conditional RC parameter...........................................9
3.7 Receiving REG for a RK already registered.........................12 3.7 Receiving REG for a RK already registered.........................12
3.8 OPC list in the Registration Request Message......................13 3.8 Dynamic Registration Support for Alias Point Code.................15
3.9 Auditing procedure and congestion state...........................14 3.9 Auditing procedure and congestion state...........................16
3.10 Response to an ASPIA message.....................................16 3.10 Response to an ASPIA message.....................................18
3.11 INFO and DIAG parameter length...................................18 3.11 INFO and DIAG parameter length...................................20
3.12 IPSP stuff.......................................................19 3.12 IPSP stuff.......................................................21
3.13 Messages and Streams.............................................24 3.13 Messages and Streams.............................................28
3.14 ASP Id for IPSP communication....................................25 3.14 ASP Id for IPSP communication....................................28
3.15 n+k redundancy...................................................26 3.15 n+k redundancy...................................................30
4.Acknowledgements...................................................31 3.16 Multiple Parameters of the Same Type in a Message................34
5.Authors' Addresses.................................................31 3.17 Registered Routing Key State After Unexpected ASP Up Message.....34
6.References.........................................................31 3.18 Location of Network Appearance...................................35
7.Changes Control....................................................33 3.19 Determination of Congestion Abatement When ASP Sends SCON........37
3.20 Removing CIC and SSN from RK.....................................37
3.21 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
4. Acknowledgements..................................................47
5. Authors' Addresses................................................47
6. References........................................................47
7. Changes Control...................................................47
7.1 Changes from v00 to v01...........................................47
7.2 Changes from v01 to v02...........................................48
7.3 Changes from v02 to v03...........................................48
1. Introduction 1. Introduction
This document contains a compilation of all defects found up until This document contains a compilation of all defects found up until
March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFC3332]. These March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFC3332]. These
defects may be of an editorial or technical nature. This document may defects may be of an editorial or technical nature. This document may
be thought of as a companion document to be used in the be thought of as a companion document to be used in the
implementation of M3UA to clarify errors in the original M3UA implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFC3332 and text within this document. This document updates RFC3332 and text within this
document, where noted, supersedes the text found in RFC3332. Each document, where noted, supersedes the text found in RFC3332. Each
error will be detailed within this document in the form of: error will be detailed within this document in the form of:
skipping to change at page 3, line 31 skipping to change at page 3, line 31
SPC Signalling Point Code SPC Signalling Point Code
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Corrections to RFC-M3UA 3. Corrections to RFC3332
3.1 Parameter Containing Subparameters with Padding Bytes 3.1 Parameter Containing Subparameters with Padding Bytes
3.1.1 Description of the problem 3.1.1 Description of the problem
If a parameter contains subparameters with padding bytes, should the If a parameter contains subparameters with padding bytes, should the
parameter length include the subparameter padding bytes or not. parameter length include the subparameter padding bytes or not.
3.1.2 Text changes to the document 3.1.2 Text changes to the document
skipping to change at page 5, line 51 skipping to change at page 6, line 4
--------- ---------
New text: New text:
--------- ---------
The Error message contains the following parameters: The Error message contains the following parameters:
Error Code Mandatory Error Code Mandatory
Routing Context Mandatory* Routing Context Mandatory*
Network Appearance Mandatory* Network Appearance Mandatory*
Affected Point Code Mandatory* Affected Point Code Mandatory*
Diagnostic Information Semi-Optional Diagnostic Information Conditional
(*) Only mandatory for specific Error Codes (*) Only mandatory for specific Error Codes
3.2.3 Solution description 3.2.3 Solution description
A SGP that does not support registration must return an Error A SGP that does not support registration must return an Error
(Unsupported Message Class) message with the first 40 bytes of the (Unsupported Message Class) message with the first 40 bytes of the
offending message (i.e. any Routing Key Management message sent by offending message (i.e. any Routing Key Management message sent by
the ASP) so that the ASP can correlate this error to the Registration the ASP) so that the ASP can correlate this error to the Registration
Request message. Request message.
skipping to change at page 6, line 49 skipping to change at page 6, line 51
--------- ---------
New text: (Section 3.3.1) New text: (Section 3.3.1)
--------- ---------
Protocol Data: (variable) Protocol Data: (variable)
The Protocol Data field contains a byte string of MTP-User The Protocol Data field contains a byte string of MTP-User
information from the original SS7 message starting with the information from the original SS7 message starting with the
first byte of the original SS7 message following the Routing first byte of the original SS7 message following the Routing
Label [7]. Label [7][8][29].
--------- ---------
Old text: (Section 9.1) Old text: (Section 9.1)
--------- ---------
[7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7 [7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP (SS7) - Message Transfer Part (MTP
--------- ---------
New text: (Section 9.1) New text: (Section 9.1)
--------- ---------
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7 [7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)" (SS7) - Message Transfer Part (MTP)"
3.3.3 Solution description 3.3.3 Solution description
A proper reference to the different SS7 message label types was A proper reference was required for the different SS7 message label
required. types.
3.4 NIF Not Available on SGP 3.4 NIF Not Available on SGP
3.4.1 Description of the problem 3.4.1 Description of the problem
The text is not clear about how the SGP/SG should handle the case of The text is not clear about how the SGP/SG should handle the case of
the NIF becoming unavailable on a SGP or all SGPs (SG). the NIF becoming unavailable on a SGP or all SGPs (SG).
3.4.2 Text changes to the document 3.4.2 Text changes to the document
skipping to change at page 8, line 11 skipping to change at page 8, line 14
If one or more SGP suffer a partial failure (where aborting the 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 association(s) would cause all active AS(es) to fail), then the SGP
MUST send DUNA messages for the affected SPC(es). This is the case MUST send DUNA messages for the affected SPC(es). This is the case
where an SGP can continue to service one or more active AS(es), but 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 due to a partial failure it is unable to service other(s) active
AS(es). AS(es).
3.4.3 Solution description 3.4.3 Solution description
The addition of this text specifies the SGP/SG behavoir for the The addition of this text specifies the SGP/SG behavior for the
different scenarios of the NIF becoming unavailable on the SGP/SG. different scenarios of the NIF becoming unavailable on the SGP/SG.
3.5 Scope of Network Appearance 3.5 Scope of Network Appearance
3.5.1 Description of the problem 3.5.1 Description of the problem
A problem was found with the scope of the NA parameter. It was not 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 clear whether it should be unique across SG-AS or unique across SCTP
associations associations
skipping to change at page 9, line 41 skipping to change at page 9, line 41
IMPLEMENTATION NOTE: For simplicity of configuration it may be IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a desirable to use the same NA value across all nodes sharing a
particular network context. particular network context.
3.5.3 Solution description 3.5.3 Solution description
The text is modified to show that NA has to be coordinated between AS 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 to SG. This correction also aligns this text with the NA definition
in section 1.2 of the RFC. in section 1.2 of the RFC.
3.6 Semi-optional RC parameter 3.6 Conditional RC parameter
3.6.1 Description of the problem 3.6.1 Description of the problem
Some optional parameters are not always optional. The text should be Some optional parameters are not always optional. The text should be
clear when optional parameters are not optional. clear when conditionally optional parameters are mandatory.
3.6.2 Text changes to the document 3.6.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.1) Old text: (Section 3.3.1)
--------- ---------
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
skipping to change at page 10, line 31 skipping to change at page 10, line 31
--------- ---------
New text: (Section 3.3.1) New text: (Section 3.3.1)
--------- ---------
3.3.1 Payload Data Message (DATA) 3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label. an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters: The DATA message contains the following variable length parameters:
Network Appearance Optional Network Appearance Optional
Routing Context Semi-Optional Routing Context Conditional
Protocol Data Mandatory Protocol Data Mandatory
Correlation Id Optional Correlation Id Optional
--------- ---------
Old text: (Section 3.4.1) Old text: (Section 3.4.1)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.1) New text: (Section 3.4.1)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.2) Old text: (Section 3.4.2)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.2) New text: (Section 3.4.2)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.3) Old text: (Section 3.4.3)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.3) New text: (Section 3.4.3)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.4) Old text: (Section 3.4.4)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.4) New text: (Section 3.4.4)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.5) Old text: (Section 3.4.5)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.5) New text: (Section 3.4.5)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
--------- ---------
Old text: (Section 3.4.6) Old text: (Section 3.4.6)
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.6) New text: (Section 3.4.6)
--------- ---------
Routing Context Semi-Optional Routing Context Conditional
3.6.3 Solution description 3.6.3 Solution description
Stating that the parameter is semi-optional, implies that it not Stating that the parameter is conditional implies that it is not
either optional or mandatory. In the parameter description the text either optional or mandatory. In the parameter description, the text
explains when it is mandatory and when optional. explains when Routing Context is mandatory and when optional.
3.7 Receiving REG for a RK already registered 3.7 Receiving REG for a RK already registered
3.7.1 Description of the problem 3.7.1 Description of the problem
The RFC does not clearly specify what to do in this case. 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 the registration request
indicates a desire to modify the Routing Key
3.7.2 Text changes to the document 3.7.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)
---------
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 4.4.1)
---------
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
---------
New text: (Section 4.4.1)
---------
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
---------
Old text: (Section 4.4.1) Old text: (Section 4.4.1)
--------- ---------
None. None.
-------- --------
New text: (Section 4.4.1) New text: (Section 4.4.1)
--------- ---------
If the SG determines that the received RK was already registered, the If the SGP determines that the received RK was already registered,
SGP returns a Registration Response message to the ASP, containing a the SGP returns a Registration Response message to the ASP,
Registration Result "Error - Cannot Support Unique Routing". containing a Registration Result "Error - Cannot Support Unique
Routing". This error applies whether the Routing Key is Active or
Inactive.
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.
If the change is accepted, a Registration Response "Successfully
Registered" is returned.
3.7.3 Solution description 3.7.3 Solution description
By specifying the error code, the general problem of re-registering a By specifying the error code and this new text, the cases of
RK is solved. This error response applies whether the Routing Key is receiving a duplicate registration request or modification to a
Active or Inactive. Routing Key are resolved.
3.8 OPC list in the Registration Request Message 3.8 Dynamic Registration Support for Alias Point Code
3.8.1 Description of the problem 3.8.1 Description of the problem
It is not clear the reason of having an OPC list in the Registration There is no text regarding the support of an Alias Point Code
Request message. What is it valid for? configuration in the dynamic registration of Routing Keys.
3.8.2 Text changes to the document 3.8.2 Text changes to the document
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
OPC List: Destination Point Code:
The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point Code
parameter. The absence of the OPC List parameter in the Routing Key
indicates the use of any OPC value,
0 1 2 3 The Destination Point Code parameter is mandatory, and
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 Identifies the Destination Point Code of incoming SS7 traffic
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for which the ASP is registering. The format is the same as
| Tag = 0x020e | Length | described for the Affected Destination parameter in the DUNA
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ message (See Section 3.4.1). Its format is:
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------- ---------
New text: (Section 3.6.1) New text: (Section 3.6.1)
--------- ---------
DPC List: Destination Point Code:
The Destination Point Code List parameter contains one or more SS7
DPC entries, and its format is the same as the Destination Point Code
parameter. Multiple DPC values will only be valid in the case of
Alias Point Code configuration. The absence of the DPC List parameter
in the Routing Key indicates the use of the DPC value as the only
posible DPC for the AS.
0 1 2 3 The Destination Point Code parameter is mandatory, and
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 Identifies the Destination Point Code of incoming SS7 traffic
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ for which the ASP is registering. For an alias point code
| Tag = 0x020e | Length | configuration, the DPC parameter would be repeated for each
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ point code. The format is the same as described for the
| Mask = 0 | Destination Point Code #1 | Affected Destination parameter in the DUNA message (See Section
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.4.1). Its format is:
| Mask = 0 | Destination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.3 Solution description 3.8.3 Solution description
Including the scenario where this parameter is used (Alias point code The solution was to add some text to describe how an alias point code
configurations), the problem is solved. The parameter name has also configuration could be supported with dynamic registration.
be changed to "Destination" since it is the way that the SG sees it.
3.9 Auditing procedure and congestion state 3.9 Auditing procedure and congestion state
3.9.1 Description of the problem 3.9.1 Description of the problem
The current description of the AUDIT procedure in regards to The current description of the AUDIT procedure in regards to
congestion state is not clear enough. When to send SCON is not congestion state is not clear enough. When to send SCON is not
completely specified. completely specified.
3.9.2 Text changes to the document 3.9.2 Text changes to the document
skipping to change at page 16, line 25 skipping to change at page 18, line 29
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------- DUNA ---------- | | <------- DUNA ---------- |
5.5 M3UA/MTP3-User Boundary Examples 5.5 M3UA/MTP3-User Boundary Examples
3.9.3 Solution description 3.9.3 Solution description
Whenever a DAUD is received, it has to be responded with 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 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 has congestion control (i.e. no ITU international networks) an SCON
message with the appropiate congestion level should precede to the message with the appropriate congestion level should precede to the
DAVA/DRST messages upon a DAUD arrival. DAVA/DRST messages upon a DAUD arrival.
A new examples section has been added to show this behavior. A new examples section has been added to show this behavior.
3.10 Response to an ASPIA message 3.10 Response to an ASPIA message
3.10.1 Description of the problem 3.10.1 Description of the problem
It was not clear how to act in the following scenario: It was not clear how to act in the following scenario:
skipping to change at page 17, line 35 skipping to change at page 19, line 39
When an ASP wishes to withdraw from receiving traffic within an AS,or When an ASP wishes to withdraw from receiving traffic within an AS,or
the ASP wants to initiate the process of activation, the ASP sends an the ASP wants to initiate the process of activation, the ASP sends an
ASP Inactive message to the SGP or IPSP. ASP Inactive message to the SGP or IPSP.
An ASP Inactive message MUST be always responded by the peer An ASP Inactive message MUST be always responded by the peer
(although other messages may be sent in the middle): (although other messages may be sent in the middle):
- If the corresponding RK is registered (statically or - If the corresponding RK is registered (statically or
dynamically), the peer should respond with an ASP Inactive Ack dynamically), the peer should respond with an ASP Inactive Ack
message. message.
- If the RK is not registered, or the RC information is not valid, -
If the RK is not registered, or the RC information is not valid,
the peer must respond with an ERROR message with Error Code = the peer must respond with an ERROR message with Error Code =
"Invalid Routing Context". "Invalid Routing Context".
- If the RC is missing and its specification is needed according - If the RC is missing and its specification is needed according
to the used configuration, the peer must respond with an ERROR to the used configuration, the peer must respond with an ERROR
message with Error Code = "No Configured AS for ASP". message with Error Code = "No Configured AS for ASP".
The action of sending the ASP Inactive message MAY be initiated at The action of sending the ASP Inactive message MAY be initiated at
the ASP by an M-ASP_INACTIVE request primitive from Layer Management the ASP by an M-ASP_INACTIVE request primitive from Layer Management
or MAY be initiated automatically by an M3UA management function. In or MAY be initiated automatically by an M3UA management function. In
the case where an ASP is processing the traffic for more than one the case where an ASP is processing the traffic for more than one
skipping to change at page 18, line 4 skipping to change at page 20, line 6
The action of sending the ASP Inactive message MAY be initiated at The action of sending the ASP Inactive message MAY be initiated at
the ASP by an M-ASP_INACTIVE request primitive from Layer Management the ASP by an M-ASP_INACTIVE request primitive from Layer Management
or MAY be initiated automatically by an M3UA management function. In or MAY be initiated automatically by an M3UA management function. In
the case where an ASP is processing the traffic for more than one the case where an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive Application Server across a common SCTP association, the ASP Inactive
message contains one or more Routing Contexts to indicate for which message contains one or more Routing Contexts to indicate for which
Application Servers the ASP Inactive message applies. Application Servers the ASP Inactive message applies.
3.10.3 Solution description 3.10.3 Solution description
A more detailed specification of the messages to be sent upon the A more detailed specification of the messages to be sent upon the
reception of an ASPIA has been added to the Inactive Procedures reception of an ASPIA has been added to the Inactive Procedures
Section. Section.
3.11 INFO and DIAG parameter length 3.11 INFO and DIAG parameter length
3.11.1 Description of the problem 3.11.1 Description of the problem
At the 2nd interop a question was raised about accepting length of 4 At the second interop a question was raised about accepting a length
bytes for DIAG and INFO parameters. of 4 bytes for DIAG and INFO parameters.
3.11.2 Text changes to the document 3.11.2 Text changes to the document
--------- ---------
Old text: (Section 3.4.1) Old text: (Section 3.4.1)
--------- ---------
INFO String: variable length INFO String: variable length
The optional INFO String parameter can carry any meaningful UTF-8 The optional INFO String parameter can carry any meaningful UTF-8
skipping to change at page 19, line 16 skipping to change at page 21, line 18
--------- ---------
New text: (Section 3.8.1) New text: (Section 3.8.1)
--------- ---------
Diagnostic Information: variable length Diagnostic Information: variable length
When included, the optional Diagnostic information can be any When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in information germane to the error condition, to assist in
identification of the error condition. The Diagnostic information identification of the error condition. The Diagnostic information
SHOULD contain the offending message. A Diagnostic Information with a SHOULD contain the offending message. TheDiagnostic Information
zero length parameter is not considered as an error (this means that parameter with a zero length parameter is not considered as an error
the Length field in the TLV will be set to 4). (this means that the Length field in the TLV will be set to 4).
3.11.3 Solution description 3.11.3 Solution description
It has been explicitly included the fact that a parameter with legth It has been explicitly included the fact that a parameter with length
zero is allowed. zero is allowed.
3.12 IPSP stuff 3.12 IPSP stuff
3.12.1 Description of the problem 3.12.1 Description of the problem
At the 2nd M3UA Plugtest several concerns were raised about the non- At the 2nd M3UA Plugtest several concerns were raised about the non-
interoperability of the two different IPSP exchanges defined in M3UA. interoperability of the two different IPSP exchanges defined in M3UA.
3.12.2 Text changes to the document 3.12.2 Text changes to the document
--------- ---------
Old text: (Section 4.3)
---------
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.
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.
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.
---------
Old text: (Section 4.3.1) Old text: (Section 4.3.1)
--------- ---------
Figure 4: ASP State Transition Diagram, per AS Figure 4: ASP State Transition Diagram, per AS
+--------------+ +--------------+
| | | |
+----------------------| ASP-ACTIVE | +----------------------| ASP-ACTIVE |
| Other +-------| | | Other +-------| |
| ASP in AS | +--------------+ | ASP in AS | +--------------+
skipping to change at page 20, line 23 skipping to change at page 25, line 32
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
--------- ---------
New text: (Section 4.3.1) New text: (Section 4.3.1)
--------- ---------
The figure below shows the transitions for the ASP and IPSP cases. The figure below shows the transitions for the ASP and IPSP cases.
Figure 5: IPSP State Transition Diagram, per AS Figure 5: ASP/IPSP State Transition Diagram, per AS
+--------------+ +--------------+
| | | |
+----------------------| ASP-ACTIVE | +----------------------| ASP-ACTIVE |
| Other +-------| | | Other +-------| |
| IPSP in AS | +--------------+ | IPSP in AS | +--------------+
| Overrides | ^ | | Overrides | ^ |
| | ASPAC/ | | ASPIA/ | | ASPAC/ | | ASPIA/
| |[ASPAC-Ack]| | [ASPIA-Ack] | |[ASPAC-Ack]| | [ASPIA-Ack]
| | | v | | | v
skipping to change at page 20, line 51 skipping to change at page 26, line 9
[ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /] [ASPDN-Ack/]| ASPUP/ | | [ASPDN-Ack /]
SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/ SCTP CDI/ | [ASPUP-Ack] | | SCTP CDI/
SCTP RI | | | SCTP RI SCTP RI | | | SCTP RI
| | v | | v
| +--------------+ | +--------------+
| | | | | |
+--------------------->| ASP-DOWN | +--------------------->| ASP-DOWN |
| | | |
+--------------+ +--------------+
The transitions in brackets are just valid for the IPSP communication The transitions in brackets are just valid for the IPSP SE model
while the rest are valid for both ASPs and IPSPs. communication while the rest are valid for both ASPs and IPSPs.
--------- ---------
Old text: (Section 4.3.4.1.2) Old text: (Section 4.3.4.1.2)
--------- ---------
Alternatively, an interchange of ASP Up messages from each end can be Alternatively, an interchange of ASP Up messages from each end can be
performed. This option follows the ASP state transition diagram. It performed. This option follows the ASP state transition diagram. It
would need four messages for completion. would need four messages for completion.
--------- ---------
New text: (Section 4.3.4.1.2) New text: (Section 4.3.4.1.2)
--------- ---------
None. 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) Old text: (Section 4.3.4.3.1)
--------- ---------
Alternatively, an interchange of ASP Active messages from each end Alternatively, an interchange of ASP Active messages from each end
can be performed. This option follows the ASP state transition can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular diagram and gives the additional advantage of selecting a particular
AS to be activated from each end. It is especially useful when an 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 IPSP is serving more than one AS. It would need four messages for
completion. completion.
--------- ---------
New text: (Section 4.3.4.3.1) New text: (Section 4.3.4.3.1)
--------- ---------
None. 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) Old text: (Section 4.3.4.4.1)
--------- ---------
Alternatively, an interchange of ASP Inactive messages from each end Alternatively, an interchange of ASP Inactive messages from each end
can be performed. This option follows the ASP state transition can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular diagram and gives the additional advantage of selecting a particular
AS to be deactivated from each end. It is especially useful when an 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 IPSP is serving more than one AS. It would need four messages for
completion. completion.
--------- ---------
New text: (Section 4.3.4.4.1) New text: (Section 4.3.4.4.1)
--------- ---------
skipping to change at page 21, line 51 skipping to change at page 27, line 15
can be performed. This option follows the ASP state transition can be performed. This option follows the ASP state transition
diagram and gives the additional advantage of selecting a particular diagram and gives the additional advantage of selecting a particular
AS to be deactivated from each end. It is especially useful when an 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 IPSP is serving more than one AS. It would need four messages for
completion. completion.
--------- ---------
New text: (Section 4.3.4.4.1) New text: (Section 4.3.4.4.1)
--------- ---------
None. 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) Old text: (Section 4.4.3)
--------- ---------
The Registration/Deregistration procedures work in the IPSP cases in 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 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 remote IPSP. An IPSP is responsible for deregistering the RKs that
it has registered. it has registered.
--------- ---------
New text: (Section 4.4.3) New text: (Section 4.4.3)
--------- ---------
The Registration/Deregistration procedures work in the IPSP cases in 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 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 remote IPSP. An IPSP is responsible for deregistering the RKs that
it has registered. it has registered.
It MAY be used one common RK for both IPSP participating in the For the IPSP SE model, it MAY be used one common RK for both IPSP
communication using the Signaling Point Code granularity. It would participating in the communication using the Signaling Point Code
basically consist of <OPC,DPC>. granularity. It would basically consist of <OPC,DPC>. In the case of
RC use, RCs SHOULD be previously agreed between both peers.
In the case of RC use, RCs SHOULD be previously agreed between both
peers.
---------
Old text: (Section 5.5)
---------
These scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already
set up. Both single exchange and double exchange behavior are
included for illustrative purposes.
5.5.1 Single exchange:
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
5.5.2 Double exchange:
IPSP-A IPSP-B
| |
|<-------------ASP Up------------|
|-----------ASP Up Ack---------->|
| |
|-------------ASP Up------------>| (optional)
|<----------ASP Up Ack-----------| (optional)
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
|------- ASP Active(RCa)-------->| RC: Routing Context
|<-----ASP Active Ack (RCa)------| (optional)
| |
|<========= DATA (RCa) =========|
|========== DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->|
| |
|------ASP Inactive (RCa)------->| RC: Routing Context
|<----ASP Inactive Ack (RCa)-----|
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
|------------ASP Down----------->| (optional)
|<--------ASP Down Ack-----------| (optional)
| |
In this approach, only one single exchange of ASP Up message can be
considered as enough since the response by the other peer can be
considered as a notice that it is in ASP_UP state.
For the same reason, only one ASP Down message is needed since once
that an IPSP receives ASP_Down ack message it is itself considered as
being in the ASP_Down state and not allowed to receive ASPSM
messages.
---------
New text: (Section 5.5)
---------
This scenarios show a basic example for IPSP communication for the
three phases of the connection (establishment, data exchange,
disconnection). It is assumed that the SCTP association is already
set up.
IPSP-A IPSP-B
| |
|-------------ASP Up------------>|
|<----------ASP Up Ack-----------|
| |
|<------- ASP Active(RCb)--------| RC: Routing Context
|-----ASP Active Ack (RCb)------>| (optional)
| |
| |
|<========= DATA (RCb) ========>|
| |
|<-----ASP Inactive (RCb)--------| RC: Routing Context
|----ASP Inactive Ack (RCb)----->| (optional)
| |
|<-----------ASP Down------------|
|---------ASP Down Ack---------->|
| |
Routing Context are previously agreed to be the same in both
directions.
3.12.3 Solution description 3.12.3 Solution description
All the references to the "double exchange" (a.k.a. symmetric IPSP Text regarding procedures has been modified to explicitely include
method) has been removed. Modifications in the ASP state machine has IPSP communication. A clear definition of both IPSP models has been
been done to include the IPSP model. 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.13 Messages and Streams 3.13 Messages and Streams
3.13.1 Description of the problem 3.13.1 Description of the problem
The relation between messages and what stream to use in order to send The relation between messages and what stream to use in order to send
them is diffuse and spread all along the document. them is diffuse and spread all along the document.
3.13.2 Text changes to the document 3.13.2 Text changes to the document
skipping to change at page 25, line 14 skipping to change at page 28, line 26
--------- ---------
None. None.
--------- ---------
New text: (Section 1.4.7) New text: (Section 1.4.7)
--------- ---------
The following rules MUST to be followed (see section 3.1.2): The following rules MUST to be followed (see section 3.1.2):
1. DATA is never sent on stream 0. 1. DATA message is never sent on stream 0.
2. ASPSM, MGMT, RKM should be sent on stream 0 (Other than BEAT and 2. ASPSM, MGMT, RKM classes should be sent on stream 0 (Other than
BEAT ACK) BEAT, BEAT ACK and NTFY messages)
3. SSNM , ASPTM , BEAT and BEAT ACK can be sent on any stream. 3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be
sent on any stream.
3.13.3 Solution description 3.13.3 Solution description
A clear specification of how messages should be sent is included in A clear specification of how messages should be sent is included in
the corresponding section. the corresponding section.
3.14 ASP Id for IPSP communication 3.14 ASP Id for IPSP communication
3.14.1 Description of the problem 3.14.1 Description of the problem
When using the IPSP communication it is no way of dynamically When using the IPSP communication there is no way to dynamically
exchange the ASP Identifier in both directions. exchange the ASP Identifier in both directions.
3.14.2 Text changes to the document 3.14.2 Text changes to the document
--------- ---------
Old text: (Section 3.5.2) Old text: (Section 3.5.2)
--------- ---------
The ASP Up Ack message contains the following parameters: The ASP Up Ack message contains the following parameters:
INFO String (optional) INFO String (optional)
skipping to change at page 26, line 28 skipping to change at page 29, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ASP Identifier | | ASP Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag =0x0004 | Length | | Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specially useful for IPSP The optional ASP Identifier parameter is specifically useful for IPSP
communication. In that case the IPSP answering the ASP Up message MAY communication. In that case the IPSP answering the ASP Up message MAY
include its own ASP Identifier value. For AS-SG communication this include its own ASP Identifier value. For AS-SG communication this
parameter MUST NOT be used. parameter MUST NOT be used.
3.14.3 Solution Description 3.14.3 Solution Description
By including the optional ASP Identifier in ASP Up message this can By including the optional ASP Identifier in ASP Up message this can
be achieved. In the AS-SG communication this optional parameter is be achieved. In the AS-SG communication this optional parameter is
not needed not needed
3.15 n+k redundancy 3.15 n+k redundancy
3.15.1 Description of the problem 3.15.1 Description of the problem
The n+k redundancy is explained as a general model to use but there The n+k redundancy is explained as a general model to use but there
is no reference in the AS state and sometimes it is not clear when to is no reference in the AS state diagram and sometimes it is not clear
use it. when to use it.
3.15.2 Text changes to the document 3.15.2 Text changes to the document
--------- ---------
Old text: (Section 4.3.2) Old text: (Section 4.3.2)
--------- ---------
AS-DOWN: The Application Server is unavailable. This state implies AS-DOWN: The Application Server is unavailable. This state implies
that all related ASPs are in the ASP-DOWN state for this AS. 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 Initially the AS will be in this state. An Application Server is in
the AS-DOWN state when it is removed from a configuration. the AS-DOWN state when it is removed from a configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
skipping to change at page 31, line 5 skipping to change at page 34, line 13
(AS-ACTIVE) until there are sufficient resources. (AS-ACTIVE) until there are sufficient resources.
3.15.3 Solution description 3.15.3 Solution description
The AS state machine reflects the state changes as a function of the The AS state machine reflects the state changes as a function of the
"n" number from the n+k redundancy configuration. This solution is "n" number from the n+k redundancy configuration. This solution is
compliance with the previous one: 1+0 model. The change from MAY to compliance with the previous one: 1+0 model. The change from MAY to
SHOULD NOT makes it recommendable to send traffic only when the SHOULD NOT makes it recommendable to send traffic only when the
require ASPs number are in ASP-ACTIVE state. require ASPs number are in ASP-ACTIVE state.
3.16 Multiple Parameters of the Same Type in a Message
3.16.1 Description of the problem
There was some confusion about whether or not multiple parameters
of same type were allowed in a message.
3.16.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.16.3 Solution Description
Added a statement to clarify that multiple parameters of the same
type are forbidden in messages unless explicitly allowed.
3.17 Registered Routing Key State After Unexpected ASP Up Message
Received
3.17.1 Description of the problem
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.17.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.17.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.18 Location of Network Appearance
3.18.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.18.2 Text changes to the document
---------
Old text: (Section 3.4.1)
---------
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.18.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.19 Determination of Congestion Abatement When ASP Sends SCON
3.19.1 Description of the problem
Currently, there is no text in the RFC indicating that the ASP
indicates when congestion has abated.
3.19.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.
3.19.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.20 Removing CIC and SSN from RK
3.20.1 Description of the problem
Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
leading to non-interoperable solutions.
3.20.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.
---------
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)
---------
In this example, the SGP contains an instance of the SS7 SCCP
protocol layer that may, for example, perform the SCCP Global Title
Translation (GTT) function for messages logically addressed to the SG
SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC
or DPC/SSN address of an SCCP peer located in the IP domain, the
resulting MTP-TRANSFER request primitive is sent to the local M3UA-
resident network address translation and mapping function for ongoing
routing to the final IP destination.
---------
New text: (Section 1.5.3)
---------
In this example, the SGP contains an instance of the SS7 SCCP
protocol layer that may, for example, perform the SCCP Global Title
Translation (GTT) function for messages logically addressed to the SG
SCCP. If the result of a GTT for an SCCP message yields an SS7 DPC
or DPC/SI address of an SCCP peer located in the IP domain, the
resulting MTP-TRANSFER request primitive is sent to the local M3UA-
resident network address translation and mapping function for ongoing
routing to the final IP destination.
---------
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.
---------
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
Protocol Data 0x0210
Reserved 0x0211
Registration Status 0x0212
Deregistration Status 0x0213
---------
Old text: (Section 3.6.1)
---------
| 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
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.20.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.21 ASP comes to ASP-ACTIVE state without full SS7 connectivity
3.21.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.21.2 Text changes to the document
---------
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)
---------
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 SHOULD send a DUNA(*) 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.21.3 Solution Description
By specifying how send SSNM messages in that scenario the problem is
solved.
4. Acknowledgements 4. Acknowledgements
The authors would like to thank Lyndon Ong, Tolga Asveren, Brian The authors would like to thank Lyndon Ong, Tolga Asveren, Brian
Bidulock, Umesh Vats, Barry Nagelberg and many others for their Bidulock, Umesh Vats, Barry Nagelberg and many others for their
valuable comments and suggestions. valuable comments and suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
skipping to change at page 32, line 17 skipping to change at page 48, line 20
- ASP Id for IPSP communication - ASP Id for IPSP communication
- n+k redundancy - n+k redundancy
7.2 Changes from v01 to v02 7.2 Changes from v01 to v02
- ASPIA-ACK substituted for DUNA when NIF is not available since - ASPIA-ACK substituted for DUNA when NIF is not available since
it also allows inter-ASP routing. it also allows inter-ASP routing.
- Changed REGREQ's parameter from "Origination Point Code" to - Changed REGREQ's parameter from "Origination Point Code" to
"Destination Point Code". "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 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
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/