draft-ietf-sigtran-m3ua-implementors-guide-03.txt   draft-ietf-sigtran-m3ua-implementors-guide-04.txt 
Network Working Group Javier Pastor-Balbas Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: August 2003 Expires: December 2003
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
February, 2003 June, 2003
M3UA Implementor's Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-03.txt> <draft-ietf-sigtran-m3ua-implementors-guide-04.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 44 skipping to change at page 1, line 44
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 Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. 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 the publication date for M3UA [RFC3332]. These defects may be of an
or technical nature. This document may be thought of as a companion editorial or technical nature. This document may be thought of as a
document to be used in the implementation of M3UA to clarify errors companion document to be used in the implementation of M3UA to
in the original M3UA document. This document updates RFC3332 and text clarify errors in the original M3UA document. This document updates
within this document supersedes the text found in RFC3332. RFC3332 and text within this document supersedes the text found in
RFC3332.
TABLE OF CONTENTS TABLE OF CONTENTS
1. Introduction.......................................................3 1. Introduction.......................................................3
1.1 Abbreviations.....................................................3 1.1 Abbreviations.....................................................3
2. Conventions........................................................3 2. Conventions........................................................3
3. Corrections to RFC3332.............................................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 Scope of Network Appearance........................................7
3.5 Scope of Network Appearance........................................8 3.5 Conditional RC parameter...........................................9
3.6 Conditional RC parameter...........................................9 3.6 Receiving REG for a RK already registered.........................11
3.7 Receiving REG for a RK already registered.........................12 3.7 Dynamic Registration Support for Alias Point Code.................15
3.8 Dynamic Registration Support for Alias Point Code.................15 3.8 Auditing procedure and congestion state...........................15
3.9 Auditing procedure and congestion state...........................16 3.9 Response to an ASPIA message......................................18
3.10 Response to an ASPIA message.....................................18 3.10 INFO and DIAG parameter length...................................19
3.11 INFO and DIAG parameter length...................................20 3.11 IPSP stuff.......................................................20
3.12 IPSP stuff.......................................................21 3.12 Messages and Streams.............................................27
3.13 Messages and Streams.............................................28 3.13 ASP Id for IPSP communication....................................28
3.14 ASP Id for IPSP communication....................................28 3.14 n+k redundancy...................................................29
3.15 n+k redundancy...................................................30 3.15 Multiple Parameters of the Same Type in a Message................34
3.16 Multiple Parameters of the Same Type in a Message................34 3.16 Registered Routing Key State After Unexpected ASP Up Message.....35
3.17 Registered Routing Key State After Unexpected ASP Up Message.....34 3.17 Location of Network Appearance...................................36
3.18 Location of Network Appearance...................................35 3.18 Determination of Congestion Abatement When ASP Sends SCON........37
3.19 Determination of Congestion Abatement When ASP Sends SCON........37 3.19 Removing CIC and SSN from RK.....................................38
3.20 Removing CIC and SSN from RK.....................................37 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45
3.21 ASP comes to ASP-ACTIVE state without full SS7 connectivity......45 3.21 NOTIFY messages are missing in Examples section..................46
4. Acknowledgements..................................................47 4. Acknowledgements..................................................56
5. Authors' Addresses................................................47 5. Authors' Addresses................................................56
6. References........................................................47 6. References........................................................56
7. Changes Control...................................................47 7. Changes Control...................................................56
7.1 Changes from v00 to v01...........................................47 7.1 Changes from v00 to v01...........................................56
7.2 Changes from v01 to v02...........................................48 7.2 Changes from v01 to v02...........................................57
7.3 Changes from v02 to v03...........................................48 7.3 Changes from v02 to v03...........................................57
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 the publication date for the MTP3 User Adaptation Layer (M3UA)
defects may be of an editorial or technical nature. This document may [RFC3332]. These defects may be of an editorial or technical nature.
be thought of as a companion document to be used in the This document may be thought of as a companion document to be used in
implementation of M3UA to clarify errors in the original M3UA the 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:
- The problem description, - The problem description,
- The text quoted from RFC3332, - The text quoted from RFC3332,
- The replacement text, - The replacement text,
- A description of the solution. - A description of the solution.
1.1 Abbreviations 1.1 Abbreviations
skipping to change at page 7, line 24 skipping to change at page 7, line 28
--------- ---------
[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 was required for the different SS7 message label A proper reference was required for the different SS7 message label
types. types.
3.4 NIF Not Available on SGP 3.4 Scope of Network Appearance
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 NIF becoming unavailable on a SGP or all SGPs (SG).
3.4.2 Text changes to the document
---------
Old text: (None)
---------
None.
---------
New text: (Section 4.7)
---------
If the SG (all the SGPs) is isolated from the NIF, then all the users
are isolated from the SS7 network. A DUNA(*) message MUST be sent
from the SGPs to all the ASPs.
If only one SGP in the SG is isolated entirely from the NIF, the SGP
SHOULD abort its associations. An alternative would be for the SGP to
send ASP Down Ack.
If one or more SGP suffer a partial failure (where aborting the
association(s) would cause all active AS(es) to fail), then the SGP
MUST send DUNA messages for the affected SPC(es). This is the case
where an SGP can continue to service one or more active AS(es), but
due to a partial failure it is unable to service other(s) active
AS(es).
3.4.3 Solution description
The addition of this text specifies the SGP/SG behavior for the
different scenarios of the NIF becoming unavailable on the SGP/SG.
3.5 Scope of Network Appearance
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
3.5.2 Text changes to the document 3.4.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.1) Old text: (Section 3.3.1)
--------- ---------
Network Appearance: 32-bits (unsigned integer) Network Appearance: 32-bits (unsigned integer)
The Network Appearance parameter identifies the SS7 network context The Network Appearance parameter identifies the SS7 network context
for the message and implicitly identifies the SS7 Point Code format for the message and implicitly identifies the SS7 Point Code format
used, the SS7 Network Indicator value, and the MTP3 and possibly the used, the SS7 Network Indicator value, and the MTP3 and possibly the
MTP3-User protocol type/variant/version used within the specific SS7 MTP3-User protocol type/variant/version used within the specific SS7
skipping to change at page 9, line 35 skipping to change at page 9, line 5
which SG a message is being transmitted/received. which SG a message is being transmitted/received.
Where the optional Network Appearance parameter is present, it must Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of the be the first parameter in the message as it defines the format of the
Protocol Data field. Protocol Data field.
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.4.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 Conditional RC parameter 3.5 Conditional RC parameter
3.6.1 Description of the problem 3.5.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 conditionally optional parameters are mandatory. clear when conditionally optional parameters are mandatory.
3.6.2 Text changes to the document 3.5.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
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:
skipping to change at page 12, line 15 skipping to change at page 11, line 30
--------- ---------
Routing Context Optional Routing Context Optional
--------- ---------
New text: (Section 3.4.6) New text: (Section 3.4.6)
--------- ---------
Routing Context Conditional Routing Context Conditional
3.6.3 Solution description 3.5.3 Solution description
Stating that the parameter is conditional implies that it is 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 Routing Context is mandatory and when optional. explains when Routing Context is mandatory and when optional.
3.7 Receiving REG for a RK already registered 3.6 Receiving REG for a RK already registered
3.7.1 Description of the problem 3.6.1 Description of the problem
The RFC does not clearly specify what the SG should do when it The RFC does not clearly specify what the SG should do when it
receives a Registration Request for a Routing Key that has already receives a Registration Request for a Routing Key that has already
been registered. There are two scenarios to consider: the been registered. There are two scenarios to consider: the
registration request is a duplicate or the registration request registration request is a duplicate or the registration request
indicates a desire to modify the Routing Key indicates a desire to modify the Routing Key
3.7.2 Text changes to the document 3.6.2 Text changes to the document
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
The format of the Routing Key parameter is as follows. The format of the Routing Key parameter is as follows.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 15, line 30 skipping to change at page 14, line 47
Routing Context applies to an existing Routing Key, the SG MAY adjust Routing Context applies to an existing Routing Key, the SG MAY adjust
the existing Routing Key to match the new information provided in the the existing Routing Key to match the new information provided in the
Routing Key parameter. A Registration Response "ERR - Routing Key Routing Key parameter. A Registration Response "ERR - Routing Key
Change Refused" is returned if the SGP does not accept the Change Refused" is returned if the SGP does not accept the
modification of the Routing Key due to either it does not support the modification of the Routing Key due to either it does not support the
re-registration procedure or the specific RC does not exist. re-registration procedure or the specific RC does not exist.
If the change is accepted, a Registration Response "Successfully If the change is accepted, a Registration Response "Successfully
Registered" is returned. Registered" is returned.
3.7.3 Solution description 3.6.3 Solution description
By specifying the error code and this new text, the cases of By specifying the error code and this new text, the cases of
receiving a duplicate registration request or modification to a receiving a duplicate registration request or modification to a
Routing Key are resolved. Routing Key are resolved.
3.8 Dynamic Registration Support for Alias Point Code 3.7 Dynamic Registration Support for Alias Point Code
3.8.1 Description of the problem 3.7.1 Description of the problem
There is no text regarding the support of an Alias Point Code There is no text regarding the support of an Alias Point Code
configuration in the dynamic registration of Routing Keys. configuration in the dynamic registration of Routing Keys.
3.8.2 Text changes to the document 3.7.2 Text changes to the document
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
Destination Point Code: Destination Point Code:
The Destination Point Code parameter is mandatory, and The Destination Point Code parameter is mandatory, and
Identifies the Destination Point Code of incoming SS7 traffic Identifies the Destination Point Code of incoming SS7 traffic
for which the ASP is registering. The format is the same as for which the ASP is registering. The format is the same as
skipping to change at page 16, line 23 skipping to change at page 15, line 40
Destination Point Code: Destination Point Code:
The Destination Point Code parameter is mandatory, and The Destination Point Code parameter is mandatory, and
Identifies the Destination Point Code of incoming SS7 traffic Identifies the Destination Point Code of incoming SS7 traffic
for which the ASP is registering. For an alias point code for which the ASP is registering. For an alias point code
configuration, the DPC parameter would be repeated for each configuration, the DPC parameter would be repeated for each
point code. The format is the same as described for the point code. The format is the same as described for the
Affected Destination parameter in the DUNA message (See Section Affected Destination parameter in the DUNA message (See Section
3.4.1). Its format is: 3.4.1). Its format is:
3.8.3 Solution description 3.7.3 Solution description
The solution was to add some text to describe how an alias point code The solution was to add some text to describe how an alias point code
configuration could be supported with dynamic registration. configuration could be supported with dynamic registration.
3.9 Auditing procedure and congestion state 3.8 Auditing procedure and congestion state
3.9.1 Description of the problem 3.8.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.8.2 Text changes to the document
--------- ---------
Old text: (Section 3.3.1) Old text: (Section 3.3.1)
--------- ---------
[...]. Where the SGP maintains the congestion status of the SS7 [...]. Where the SGP maintains the congestion status of the SS7
destination, and the SS7 destination is congested, the SGP MUST destination, and the SS7 destination is congested, the SGP MUST
additionally respond with an SCON message before the DAVA or DRST additionally respond with an SCON message before the DAVA or DRST
message. If the SS7 destination is available and congested, the SGP message. If the SS7 destination is available and congested, the SGP
MUST respond with an SCON message and then a DAVA message. If the MUST respond with an SCON message and then a DAVA message. If the
skipping to change at page 18, line 24 skipping to change at page 17, line 38
5.4.4 SG state: Uncongested / Unavailable 5.4.4 SG state: Uncongested / Unavailable
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------- DUNA ---------- | | <------- DUNA ---------- |
5.5 M3UA/MTP3-User Boundary Examples 5.5 M3UA/MTP3-User Boundary Examples
3.9.3 Solution description 3.8.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 appropriate 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.9 Response to an ASPIA message
3.10.1 Description of the problem 3.9.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:
ASP SGP ASP SGP
--- --- --- ---
| ------ ASPIA (RC1)-----> | | ------ ASPIA (RC1)-----> |
| <---- ASPIA Ack ------- | | <---- ASPIA Ack ------- |
| -----DEREG REQ (RC1)---> | | -----DEREG REQ (RC1)---> |
| <----DEREG RSP (RC1)---- | | <----DEREG RSP (RC1)---- |
| -------ASPIA (RC1)-----> | | -------ASPIA (RC1)-----> |
What should SG do? What should SG do?
3.10.2 Text changes to the document 3.9.2 Text changes to the document
--------- ---------
Old text: (Section 4.5.3) Old text: (Section 4.5.3)
--------- ---------
When an ASP wishes to withdraw from receiving traffic within an AS, 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 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 action MAY be initiated at the ASP by an M-ASP_INACTIVE request
primitive from Layer Management or MAY be initiated automatically by primitive from Layer Management or MAY be initiated automatically by
an M3UA management function. In the case where an ASP is processing an M3UA management function. In the case where an ASP is processing
skipping to change at page 19, line 36 skipping to change at page 19, line 4
--------- ---------
New text: (Section 4.5.3) New text: (Section 4.5.3)
--------- ---------
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
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.9.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.10 INFO and DIAG parameter length
3.11.1 Description of the problem 3.10.1 Description of the problem
At the second interop a question was raised about accepting a length At the second interop a question was raised about accepting a length
of 4 bytes for DIAG and INFO parameters. of 4 bytes for DIAG and INFO parameters.
3.11.2 Text changes to the document 3.10.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
[10] character string along with the message. Length of the INFO [10] character string along with the message. Length of the INFO
String parameter is from 0 to 255 octets. No procedures are presently String parameter is from 0 to 255 octets. No procedures are presently
skipping to change at page 21, line 22 skipping to change at page 20, line 38
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. TheDiagnostic Information SHOULD contain the offending message. TheDiagnostic Information
parameter with a zero length parameter is not considered as an error 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). (this means that the Length field in the TLV will be set to 4).
3.11.3 Solution description 3.10.3 Solution description
It has been explicitly included the fact that a parameter with length It has been explicitly included the fact that a parameter with length
zero is allowed. zero is allowed.
3.12 IPSP stuff 3.11 IPSP stuff
3.12.1 Description of the problem 3.11.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.11.2 Text changes to the document
--------- ---------
Old text: (Section 4.3) Old text: (Section 4.3)
--------- ---------
4.3 AS and ASP State Maintenance 4.3 AS and ASP State Maintenance
The M3UA layer on the SGP maintains the state of each remote ASP, in The M3UA layer on the SGP maintains the state of each remote ASP, in
each Application Server that the ASP is configured to receive each Application Server that the ASP is configured to receive
traffic, as input to the M3UA message distribution function. traffic, as input to the M3UA message distribution function.
skipping to change at page 27, line 42 skipping to change at page 27, line 12
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.
For the IPSP SE model, it MAY be used one common RK for both IPSP For the IPSP SE model, it MAY be used one common RK for both IPSP
participating in the communication using the Signaling Point Code participating in the communication using the Signaling Point Code
granularity. It would basically consist of <OPC,DPC>. In the case of granularity. It would basically consist of <OPC,DPC>. In the case of
RC use, RCs SHOULD be previously agreed between both peers. RC use, RCs SHOULD be previously agreed between both peers.
3.12.3 Solution description 3.11.3 Solution description
Text regarding procedures has been modified to explicitely include Text regarding procedures has been modified to explicitely include
IPSP communication. A clear definition of both IPSP models has been IPSP communication. A clear definition of both IPSP models has been
included. Modifications in the ASP state machine have been done to included. Modifications in the ASP state machine have been done to
also include the IPSP model. For interoperability purposes, IPSP SE also include the IPSP model. For interoperability purposes, IPSP SE
model is mandated while DE model is allowed. model is mandated while DE model is allowed.
3.13 Messages and Streams 3.12 Messages and Streams
3.13.1 Description of the problem 3.12.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.12.2 Text changes to the document
--------- ---------
Old text: (Section 1.4.7) Old text: (Section 1.4.7)
--------- ---------
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 message is never sent on stream 0. 1. DATA message is never sent on stream 0.
2. ASPSM, MGMT, RKM classes should be sent on stream 0 (Other than 2. ASPSM, MGMT, RKM classes should be sent on stream 0 (Other than
BEAT, BEAT ACK and NTFY messages) BEAT, BEAT ACK and NTFY messages)
3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be 3. SSNM, ASPTM classes and BEAT, BEAT ACK and NTFY messages can be
sent on any stream. sent on any stream.
3.13.3 Solution description 3.12.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.13 ASP Id for IPSP communication
3.14.1 Description of the problem 3.13.1 Description of the problem
When using the IPSP communication there is no way to 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.13.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)
The format for ASP Up Ack message parameters is as follows: The format for ASP Up Ack message parameters is as follows:
0 1 2 3 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 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 | | Tag =0x0004 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 44 skipping to change at page 29, line 15
\ \ \ \
/ INFO String / / INFO String /
\ \ \ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The optional ASP Identifier parameter is specifically 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.13.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.1 Description of the problem 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 The n+k redundancy is explained as a general model to use but there
is no reference in the AS state diagram and sometimes it is not clear is no reference in the current AS state diagram and sometimes it is
when to use it. not clear when to use it. Also n+k as defined in the introduction is
subject to multiple interpretations.
3.15.2 Text changes to the document 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.
--------- ---------
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.
skipping to change at page 31, line 44 skipping to change at page 31, line 43
directly upon the first successful REG REQ from an ASP. Another directly upon the first successful REG REQ from an ASP. Another
example is where the AS/ASP configuration data is not created until 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 first ASP successfully enters the ASP-ACTIVE state. In this case
the AS-ACTIVE state is entered directly. the AS-ACTIVE state is entered directly.
--------- ---------
New text: (Section 4.3.2) New 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 the number of ASPs being in ASP-INACTIVE or ASP-DOWN is less that the number of ASPs being in ASP-INACTIVE or ASP-ACTIVE is less
than "n". Initially the AS will be in this state. An Application than "n". Initially the AS will be in this state. An Application
Server is in the AS-DOWN state when it is removed from a Server is in the AS-DOWN state when it is removed from a
configuration. configuration.
AS-INACTIVE: The Application Server is available but no application AS-INACTIVE: The Application Server is available but no application
traffic is active. This implies that there are at least n ASPs in traffic is active. This implies that there are at least n ASPs in
either ASP-INACTIVE or ASP-ACTIVE but the total number of ASPs in either ASP-INACTIVE or ASP-ACTIVE but the total number of ASPs in
ASP-ACTIVE state has not reach n. The recovery timer T(r) is not ASP-ACTIVE state has not reach n. The recovery timer T(r) is not
running or has expired. running or has expired.
AS-ACTIVE: The Application Server is available and application AS-ACTIVE: The Application Server is available and application
traffic is active. This state implies that at least n ASPs are in traffic is active. The AS moves to this state after being in AS-
the ASP-ACTIVE state. 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.
AS-PENDING: An active ASP has transitioned from ASP-ACTIVE to ASP- AS-PENDING: The last active ASP has transitioned from ASP-ACTIVE to
INACTIVE or ASP-DOWN and it was the number n active ASP in the AS. A ASP-INACTIVE or ASP-DOWN. A recovery timer T(r) SHOULD be started
recovery timer T(r) SHOULD be started and all incoming signalling and all incoming signalling messages SHOULD be queued by the SGP. If
messages SHOULD be queued by the SGP. If an ASP becomes ASP-ACTIVE an ASP becomes ASP-ACTIVE before T(r) expires, the AS is moved to the
before T(r) expires, the AS is moved to the AS-ACTIVE state and all AS-ACTIVE state and all the queued messages will be sent to the ASP.
the queued messages will be sent to the ASP.
If T(r) expires before an ASP becomes ASP-ACTIVE, and the SGP has no If T(r) expires before an ASP becomes ASP-ACTIVE, the SGP MAY stop
alternative, the SGP may stops queuing messages and discards all queuing messages and discards all
previously queued messages. The AS will move to the AS-INACTIVE state previously queued messages. The AS will move to the AS-INACTIVE state
if at least the number of ASPs in either ASP-INACTIVE or ASP-ACTIVE if at least the number of ASPs in ASP-INACTIVE sum n, otherwise it
sum n, otherwise it will move to AS-DOWN state. will move to AS-DOWN state.
Figure 5 shows an example AS state machine for the case where the Figure 5 shows an example AS state machine for the case where the
AS/ASP data is preconfigured and a n+k redundancy model. AS/ASP data is preconfigured and an n+k redundancy model.
Figure 5: AS State Transition Diagram Figure 5: AS State Transition Diagram
+----------+ IA2AC +-------------+ +----------+ IA2AC +-------------+
| AS- |---------------------------->| AS- | | AS- |---------------------------->| AS- |
| INACTIVE | | ACTIVE | | INACTIVE | | ACTIVE |
| |<----------- | | | |<----------- | |
+----------+ \ +-------------+ +----------+ \ +-------------+
^ | \ ^ | ^ | \ ^ |
| | IA2DN \ PN2IA | | AC2PN | | IA2DN \ PN2IA | | AC2PN
skipping to change at page 33, line 7 skipping to change at page 33, line 10
+----------+ +-------------+ +----------+ +-------------+
DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs are in DN2IA: One ASP moves to ASP-INACTIVE causing that n ASPs are in
either ASP-ACTIVE or ASP-INACTIVE states. either ASP-ACTIVE or ASP-INACTIVE states.
IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in IA2DN: One ASP moves to ASP-DOWN causing that the number of ASPs in
either ASP-ACTIVE or ASP-INACTIVE drops below n. either ASP-ACTIVE or ASP-INACTIVE drops below n.
IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the IA2AC: one ASP moves to ASP-ACTIVE, causing number of ASPs in the
ASP-ACTIVE state to be n. 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: one ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-DOWN AC2PN: the last ASP in ASP-ACTIVE state moves to ASP-INACTIVE or ASP-
states, causing the number of ASPs in ASP-ACTIVE drop below n. DOWN states, causing the number of ASPs in ASP-ACTIVE drop below 1.
PN2AC: One ASP moves to ASP-ACTIVE causing the number of ASPs in the PN2AC: One ASP moves to ASP-ACTIVE.
ASP-ACTIVE state to be n.
PN2IA: T(r) Expiry, n or more ASPs are in either ASP-INACTIVE or ASP- PN2IA: T(r) Expiry, n or more ASPs are in ASP-INACTIVE.
ACTIVE state and number of ASPs in ASP-ACTIVE state is less than n.
PN2DN: T(r) Expiry, the number of ASPs in either ASP-INACTIVE or ASP- PN2DN: T(r) Expiry, the number of ASPs in ASP-INACTIVE state is less
ACTIVE state is less than n. than n.
For other cases where the AS/ASP configuration data is created As "n" ASPs are needed to handle the maximum engineered load of the
dynamically, there would be differences in the state machine, AS, an AS becomes AS-ACTIVE right after n ASPs reach the ASP-ACTIVE
especially at creation of the AS. For example, where the AS/ASP state during the start-up phase (except for smooth start). Once the
configuration data is not created until Registration of the first traffic is flowing, an AS keeps the AS-ACTIVE state till the last ASP
ASP, the AS-INACTIVE state is entered directly upon the nth 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 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 is where the AS/ASP configuration data is not created until the nth
ASP successfully enters the ASP-ACTIVE state. In this latter case ASP successfully enters the ASP-ACTIVE state. In this latter case
the AS-ACTIVE state is entered directly. the AS-ACTIVE state is entered directly.
--------- ---------
Old text: (Section 4.3.4.3, for both loadsharing and broadcast) 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 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 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 active ASP until it determines that there are sufficient resources to
handle the expected load (e.g., until there are "n" ASPs in state 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 ASP-ACTIVE in the AS). In this case, the SGP or IPSP SHOULD withhold
the Notify (AS-ACTIVE) until there are sufficient resources. the Notify (AS-ACTIVE) until there are sufficient resources.
--------- ---------
New text: (Section 4.3.4.3, for both loadsharing and broadcast) New 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 At start-up or re-start phases, an SGP or IPSP, upon reception of an
ASP in a Loadshare AS, SHOULD NOT direct traffic to a newly active ASP Active message for the first ASP in a Loadshare AS, SHOULD NOT
ASP until it determines that there are sufficient resources to handle direct traffic to a newly active ASP until it determines that there
the expected load (e.g., until there are "n" ASPs in state ASP-ACTIVE are sufficient resources to handle the expected load (e.g., until
in the AS). In this case, the SGP or IPSP SHOULD withhold the Notify there are "n" ASPs in state ASP-ACTIVE in the AS). In this case, the
(AS-ACTIVE) until there are sufficient resources. SGP or IPSP SHOULD withhold the Notify (AS-ACTIVE) until there are
sufficient resources.
3.15.3 Solution description 3.14.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.
Also it is explicitely stated that "n" is seen as the "maximum
engineered load".
3.16 Multiple Parameters of the Same Type in a Message 3.15 Multiple Parameters of the Same Type in a Message
3.16.1 Description of the problem 3.15.1 Description of the problem
There was some confusion about whether or not multiple parameters There was some confusion about whether or not multiple parameters
of same type were allowed in a message. of same type were allowed in a message.
3.16.2 Text changes to the document 3.15.2 Text changes to the document
--------- ---------
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
Where more than one parameter is included in a message, the Where more than one parameter is included in a message, the
parameters may be in any order, except where explicitly mandated. A parameters may be in any order, except where explicitly mandated. A
receiver SHOULD accept the parameters in any order. receiver SHOULD accept the parameters in any order.
--------- ---------
skipping to change at page 34, line 33 skipping to change at page 35, line 4
Old text: (Section 3.2) Old text: (Section 3.2)
--------- ---------
Where more than one parameter is included in a message, the Where more than one parameter is included in a message, the
parameters may be in any order, except where explicitly mandated. A parameters may be in any order, except where explicitly mandated. A
receiver SHOULD accept the parameters in any order. receiver SHOULD accept the parameters in any order.
--------- ---------
New text: (Section 3.2) New text: (Section 3.2)
--------- ---------
Where more than one parameter is included in a message, the Where more than one parameter is included in a message, the
parameters may be in any order, except where explicitly mandated. A parameters may be in any order, except where explicitly mandated. A
receiver SHOULD accept the parameters in any order. receiver SHOULD accept the parameters in any order.
Unless explicitly stated or shown in a message format diagram, only Unless explicitly stated or shown in a message format diagram, only
one parameter of the same type is allowed in a message. one parameter of the same type is allowed in a message.
3.16.3 Solution Description 3.15.3 Solution Description
Added a statement to clarify that multiple parameters of the same Added a statement to clarify that multiple parameters of the same
type are forbidden in messages unless explicitly allowed. type are forbidden in messages unless explicitly allowed.
3.17 Registered Routing Key State After Unexpected ASP Up Message 3.16 Registered Routing Key State After Unexpected ASP Up Message
Received Received
3.17.1 Description of the problem
3.16.1 Description of the problem
If the ASP unexpectedly sends an ASP Up message while in the If the ASP unexpectedly sends an ASP Up message while in the
ASP-ACTIVE state, it is not clear what the peer should do ASP-ACTIVE state, it is not clear what the peer should do
with registered Routing Keys. Should these Routing Keys be with registered Routing Keys. Should these Routing Keys be
maintained as registered or should they be considered maintained as registered or should they be considered
deregistered? deregistered?
3.17.2 Text changes to the document 3.16.2 Text changes to the document
--------- ---------
Old text: (Section 4.3.4.1) Old text: (Section 4.3.4.1)
--------- ---------
If an ASP Up message is received and internally the remote ASP is in 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 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 an Error message ("Unexpected Message), and the remote ASP state is
changed to ASP-INACTIVE in all relevant Application Servers. changed to ASP-INACTIVE in all relevant Application Servers.
--------- ---------
New text: (Section 4.3.4.1) New text: (Section 4.3.4.1)
--------- ---------
If an ASP Up message is received and internally the remote ASP is in 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, the ASP-ACTIVE state, an ASP Up Ack message is returned, as well as,
an Error message ("Unexpected Message). In addition, the remote ASP an Error message ("Unexpected Message). In addition, the remote ASP
state is changed to ASP-INACTIVE in all relevant Application Servers state is changed to ASP-INACTIVE in all relevant Application Servers
and all registered Routing Keys are considered deregistered. and all registered Routing Keys are considered deregistered.
3.17.3 Solution Description 3.16.3 Solution Description
Added a statement to clarify that registered Routing Keys will be Added a statement to clarify that registered Routing Keys will be
considered deregistered if an unexpected ASP Up message is received considered deregistered if an unexpected ASP Up message is received
while the ASP is in the ASP-ACTIVE state. This clarification ensures while the ASP is in the ASP-ACTIVE state. This clarification ensures
the two peers remain synchronized. the two peers remain synchronized.
3.18 Location of Network Appearance 3.17 Location of Network Appearance
3.18.1 Description of the problem 3.17.1 Description of the problem
For the Payload Data message, it is clear that the Network For the Payload Data message, it is clear that the Network
Appearance, if included, MUST be the first parameter in the message. Appearance, if included, MUST be the first parameter in the message.
For the other messages that may contain Network Appearance, it is not For the other messages that may contain Network Appearance, it is not
so clear. so clear.
3.18.2 Text changes to the document 3.17.2 Text changes to the document
--------- ---------
Old text: (Section 3.4.1) Old text: (Section 3.4.1)
--------- ---------
Network Appearance: 32-bit unsigned integer Network Appearance: 32-bit unsigned integer
See Section 3.3.1 See Section 3.3.1
--------- ---------
New text: (Section 3.4.1) New text: (Section 3.4.1)
skipping to change at page 36, line 37 skipping to change at page 37, line 4
The optional Network Appearance parameter field identifies the SS7 The optional Network Appearance parameter field identifies the SS7
network context for the Routing Key, and has the same format as in 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 the DATA message (See Section 3.3.1). The absence of the Network
Appearance parameter in the Routing Key indicates the use of any Appearance parameter in the Routing Key indicates the use of any
Network Appearance value. Its format is: Network Appearance value. Its format is:
--------- ---------
New text: (Section 3.6.1) New text: (Section 3.6.1)
--------- ---------
Network Appearance: Network Appearance:
The optional Network Appearance parameter field identifies the SS7 The optional Network Appearance parameter field identifies the SS7
network context for the Routing Key, and has the same format as in 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 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 does not have to be the first parameter in the message. The
absence of the Network Appearance parameter in the Routing Key absence of the Network Appearance parameter in the Routing Key
indicates the use of any Network Appearance value. Its format is: indicates the use of any Network Appearance value. Its format is:
3.18.3 Solution Description 3.17.3 Solution Description
Add statements to clarify that Network Appearance, if present, does Add statements to clarify that Network Appearance, if present, does
not have to be the first parameter in the message with the exception not have to be the first parameter in the message with the exception
of the Payload Data message. of the Payload Data message.
3.19 Determination of Congestion Abatement When ASP Sends SCON 3.18 Determination of Congestion Abatement When ASP Sends SCON
3.19.1 Description of the problem 3.18.1 Description of the problem
Currently, there is no text in the RFC indicating that the ASP Currently, there is no text in the RFC indicating that the ASP
indicates when congestion has abated. indicates when congestion has abated.
3.19.2 Text changes to the document 3.18.2 Text changes to the document
--------- ---------
Old text: (Section 3.4.4) Old text: (Section 3.4.4)
--------- ---------
The SCON message can be sent from an SGP to all concerned ASPs to 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 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 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 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 variants (e.g., ANSI MTP) the SCON message may be sent when the SS7
skipping to change at page 37, line 40 skipping to change at page 38, line 5
The SCON message can be sent from an SGP to all concerned ASPs to 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 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 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 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 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 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 M3UA layer of an ASP to an M3UA peer indicating that the congestion
level of the M3UA layer or the ASP has changed. level of the M3UA layer or the ASP has changed.
3.19.3 Solution Description 3.18.3 Solution Description
Clarify that the ASP needs to indicate when the congestion level has Clarify that the ASP needs to indicate when the congestion level has
changed (including abatement). Further, the ASP peer can maintain changed (including abatement). Further, the ASP peer can maintain
a timer, if desired, in case the ASP fails to indicate congestion a timer, if desired, in case the ASP fails to indicate congestion
abatement. abatement.
3.20 Removing CIC and SSN from RK 3.19 Removing CIC and SSN from RK
3.20.1 Description of the problem 3.19.1 Description of the problem
Use of SSN and CIC Routing Keys is inadequately defined in RFC3332 Use of SSN and CIC Routing Keys is inadequately defined in RFC3332
leading to non-interoperable solutions. leading to non-interoperable solutions.
3.20.2 Text changes to the document 3.19.2 Text changes to the document
--------- ---------
Old text: (Section 1.4.2.1) Old text: (Section 1.4.2.1)
--------- ---------
Possible SS7 address/routing information that comprise a Routing Key Possible SS7 address/routing information that comprise a Routing Key
entry includes, for example, the OPC, DPC, SIO found in the MTP3 entry includes, for example, the OPC, DPC, SIO found in the MTP3
routing label, or MTP3-User specific fields (such as the ISUP CIC, routing label, or MTP3-User specific fields (such as the ISUP CIC,
SCCP subsystem number). Some example Routing Keys are: the DPC SCCP subsystem number). Some example Routing Keys are: the DPC
alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the alone, the DPC/OPC combination, the DPC/OPC/CIC combination, or the
skipping to change at page 39, line 29 skipping to change at page 39, line 45
Traffic that requires sequencing SHOULD be assigned to the same Traffic that requires sequencing SHOULD be assigned to the same
stream. To accomplish this, MTP3-User traffic may be assigned to stream. To accomplish this, MTP3-User traffic may be assigned to
individual streams based on, for example, the SLS value in the MTP3 individual streams based on, for example, the SLS value in the MTP3
Routing Label, subject of course to the maximum number of streams Routing Label, subject of course to the maximum number of streams
supported by the underlying SCTP association. supported by the underlying SCTP association.
--------- ---------
Old text: (Section 1.5.3) 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 For internal SGP modeling purposes, this may be accomplished with the
use of an implementation-dependent nodal interworking function within use of an implementation-dependent nodal interworking function within
the SGP that effectively sits below the SCCP and routes MTP-TRANSFER the SGP that effectively sits below the SCCP and routes MTP-TRANSFER
request/indication messages to/from both the MTP3 and the M3UA layer, request/indication messages to/from both the MTP3 and the M3UA layer,
based on the SS7 DPC or DPC/SSN address information. This nodal based on the SS7 DPC or DPC/SSN address information. This nodal
interworking function has no visible peer protocol with either the interworking function has no visible peer protocol with either the
ASP or SEP. ASP or SEP.
--------- ---------
New text: (Section 1.5.3) New text: (Section 1.5.3)
skipping to change at page 41, line 10 skipping to change at page 40, line 51
Congestion Indications 0x0205 Congestion Indications 0x0205
Concerned Destination 0x0206 Concerned Destination 0x0206
Routing Key 0x0207 Routing Key 0x0207
Registration Result 0x0208 Registration Result 0x0208
Deregistration Result 0x0209 Deregistration Result 0x0209
Local_Routing Key Identifier 0x020a Local_Routing Key Identifier 0x020a
Destination Point Code 0x020b Destination Point Code 0x020b
Service Indicators 0x020c Service Indicators 0x020c
Reserved 0x020d Reserved 0x020d
Originating Point Code List 0x020e Originating Point Code List 0x020e
Protocol Data 0x0210 Reserved 0x020f Protocol
Data 0x0210
Reserved 0x0211 Reserved 0x0211
Registration Status 0x0212 Registration Status 0x0212
Deregistration Status 0x0213 Deregistration Status 0x0213
--------- ---------
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
| Traffic Mode Type (optional) | | Traffic Mode Type (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Point Code | | Destination Point Code |
skipping to change at page 43, line 40 skipping to change at page 43, line 32
New text: (Section 3.6.1) New text: (Section 3.6.1)
--------- ---------
(none) (none)
--------- ---------
Old text: (Section 3.7.1) Old text: (Section 3.7.1)
--------- ---------
An Application Server Process may be configured to process traffic An Application Server Process may be configured to process traffic
for more than one logical Application Server. >From the for more than one logical Application Server. From the
perspective of an ASP, a Routing Context defines a range of perspective of an ASP, a Routing Context defines a range of
signalling traffic that the ASP is currently configured to receive signalling traffic that the ASP is currently configured to receive
from the SGP. For example, an ASP could be configured to support from the SGP. For example, an ASP could be configured to support
call processing for multiple ranges of PSTN trunks and therefore call processing for multiple ranges of PSTN trunks and therefore
receive related signalling traffic, identified by separate SS7 receive related signalling traffic, identified by separate SS7
DPC/OPC/CIC ranges. DPC/OPC/CIC ranges.
--------- ---------
New text: (Section 3.7.1) New text: (Section 3.7.1)
--------- ---------
skipping to change at page 44, line 4 skipping to change at page 43, line 43
perspective of an ASP, a Routing Context defines a range of perspective of an ASP, a Routing Context defines a range of
signalling traffic that the ASP is currently configured to receive signalling traffic that the ASP is currently configured to receive
from the SGP. For example, an ASP could be configured to support from the SGP. For example, an ASP could be configured to support
call processing for multiple ranges of PSTN trunks and therefore call processing for multiple ranges of PSTN trunks and therefore
receive related signalling traffic, identified by separate SS7 receive related signalling traffic, identified by separate SS7
DPC/OPC/CIC ranges. DPC/OPC/CIC ranges.
--------- ---------
New text: (Section 3.7.1) New text: (Section 3.7.1)
--------- ---------
An Application Server Process may be configured to process traffic An Application Server Process may be configured to process traffic
for more than one logical Application Server. >From the for more than one logical Application Server. From the
perspective of an ASP, a Routing Context defines a range of perspective of an ASP, a Routing Context defines a range of
signalling traffic that the ASP is currently configured to receive signalling traffic that the ASP is currently configured to receive
from the SGP. For example, an ASP could be configured to support from the SGP. For example, an ASP could be configured to support
call processing for multiple ranges of PSTN trunks and therefore call processing for multiple ranges of PSTN trunks and therefore
receive related signalling traffic, identified by separate SS7 receive related signalling traffic, identified by separate SS7
DPC/OPC/SI ranges. DPC/OPC/SI ranges.
--------- ---------
Old text: (Section 4.4.1) Old text: (Section 4.4.1)
--------- ---------
skipping to change at page 45, line 4 skipping to change at page 44, line 41
For example, where Application Servers are defined using ranges of For example, where Application Servers are defined using ranges of
ISUP CIC values, the Operator is implicitly splitting up control of ISUP CIC values, the Operator is implicitly splitting up control of
the related circuit groups. Some CIC value range assignments may the related circuit groups. Some CIC value range assignments may
interfere with ISUP circuit group management procedures. interfere with ISUP circuit group management procedures.
--------- ---------
New text: (Section A.2.1) New text: (Section A.2.1)
--------- ---------
(none) (none)
3.20.3 Solution Description
3.19.3 Solution Description
The removal of reference to SSN and CIC used in Routing Keys as well 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 as removal of Circuit Range from the Routing Key parameter removes
the unclear text from the specification. the unclear text from the specification.
3.21 ASP comes to ASP-ACTIVE state without full SS7 connectivity 3.20 ASP comes to ASP-ACTIVE state without full SS7 connectivity
3.21.1 Description of the problem 3.20.1 Description of the problem
There is not explicit text explaining how the protocol should work 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 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 some problems in the SS7 network that prevent it to have full
connectivity. connectivity.
3.21.2 Text changes to the document 3.20.2 Text changes to the document
--------- ---------
Old text: (Section 4.5.1) Old text: (Section 4.5.1)
--------- ---------
The SGP M3UA layer determines the set of concerned ASPs to be The SGP M3UA layer determines the set of concerned ASPs to be
informed based on the specific SS7 network for which the primitive informed based on the specific SS7 network for which the primitive
indication is relevant. In this way, all ASPs configured to indication is relevant. In this way, all ASPs configured to
send/receive traffic within a particular network appearance are send/receive traffic within a particular network appearance are
informed. If the SGP operates within a single SS7 network informed. If the SGP operates within a single SS7 network
skipping to change at page 46, line 49 skipping to change at page 46, line 41
an indication that the destination became available or restricted. an indication that the destination became available or restricted.
When an ASP becomes active for an AS and the SG is experiencing SS7 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 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 AS, the SG SHOULD send a DUNA(*) to the newly active ASP to prevent
the ASP from sending traffic. the ASP from sending traffic.
In the IPSP case, MTP restart could be considered if the IPSP also In the IPSP case, MTP restart could be considered if the IPSP also
has connection to an SS7 network. [...] has connection to an SS7 network. [...]
3.21.3 Solution Description 3.20.3 Solution Description
By specifying how send SSNM messages in that scenario the problem is By specifying how send SSNM messages in that scenario the problem is
solved. 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)
---------
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)
---------
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
| |
|<------------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)--->|
| |
| |
|<------- 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}, |
| ..., |
| {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)
---------
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)
---------
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)------------------>|
---------
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)--->|
| | | |
---------
New text: (Section 5.2.3)
---------
SGP ASP1 ASP2 ASP3
| | | |
|<----ASP Inact.----| | |
|---ASP Inact Ack-->| | |
| | | |
|-NTFY(AS-PENDING)->| | |
|-------------------NOTIFY(AS-PENDING)->| |
|---------------------------------------NOTIFY(AS-PENDING)->|
|---------------------------------------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.
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, Samuel Dur D. Jeyaseelan,
valuable comments and suggestions. Antonio Canete and many others for their valuable comments and
suggestions.
5. Authors' Addresses 5. Authors' Addresses
Javier Pastor-Balbas Javier Pastor-Balbas
Ericsson Espana S.A. Ericsson Espana S.A.
Ombu 3 Via de los Poblados 13
28045 Madrid 28033 Madrid
Spain Spain
Phone: +34-91-339-3819 Phone: +34-91-339-1397
Email: j.javier.pastor@ericsson.com Email: j.javier.pastor@ericsson.com
Ken Morneault Ken Morneault
Cisco Systems Inc. Cisco Systems Inc.
13615 Dulles Technology Drive 13615 Dulles Technology Drive
Herndon, VA. 20171 Herndon, VA. 20171
USA USA
Phone: +1-703-484-3323 Phone: +1-703-484-3323
EMail: kmorneau@cisco.com EMail: kmorneau@cisco.com
skipping to change at page 48, line 30 skipping to change at page 57, line 25
7.3 Changes from v02 to v03 7.3 Changes from v02 to v03
- Changed from "semi-optional" to "conditional"- Section 3.7 reworded - Changed from "semi-optional" to "conditional"- Section 3.7 reworded
- Updated Section 3.8 to correctly explain how the alias point code - Updated Section 3.8 to correctly explain how the alias point code
configuration can be supported with dynamically registered Routing configuration can be supported with dynamically registered Routing
Keys Keys
- Changes in "messages and streams" section - Changes in "messages and streams" section
- IPSP DE model is allowed. But IPSP MUST be supported. - IPSP DE model is allowed. But IPSP SE MUST be supported.
- New sections added: - New sections added:
- Multiple Parameters of the Same Type in a Message - Multiple Parameters of the Same Type in a Message
- Registration Routing Key State After Unexpected ASP Up Message - Registration Routing Key State After Unexpected ASP Up Message
- Location of Network Appearance - Location of Network Appearance
- Determination of Congestion Abatement When ASP Sends SCON - Determination of Congestion Abatement When ASP Sends SCON
- Removing CIC and SSN from RK - Removing CIC and SSN from RK
- ASP comes to ASP-ACTIVE state without full SS7 connectivity - ASP comes to ASP-ACTIVE state without full SS7 connectivity
7.4 Changes from v03 to v04
- 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.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). 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
 End of changes. 

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