| draft-ietf-sigtran-m3ua-implementors-guide-00Description: Request For CommentsYou can download source copies of the file as follows:
Listed below is the contents of file draft-ietf-sigtran-m3ua-implementors-guide-00.txt.
Network Working Group Javier Pastor
INTERNET-DRAFT Ericsson
Expires: September 2002
Ken Morneault
Cisco Systems
March, 2002
M3UA ImplementorÆs Guide
<draft-ietf-sigtran-m3ua-implementors-guide-00.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/lid-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments
should be directed to the authors.
Abstract
This document contains a compilation of all defects found up until
March 2002 for the M3UA [RFCxxx]. These defects may be of an
editorial or technical nature. This document may be thought of as a
companion document to be used in the implementation of M3UA to
clarify errors in the original M3UA document. This document updates
RFCxxxx and text within this document supersedes the text found in
RFCxxxx
Pastor, Morneault [Page 1]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
TABLE OF CONTENTS
1.Introduction........................................................3
2.Conventions.........................................................3
3.Corrections to RFC-M3UA.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes..............3
3.2 Dynamic Registration Not Supported.................................4
3.3 Contents of User Protocol Data.....................................6
3.4 NIF Not Available on SGP...........................................7
3.4.1 Description of the problem.......................................7
3.4.2 Text changes to the document.....................................7
3.4.3 Solution description.............................................8
3.5 Scope of Network Appearance........................................8
3.6 Semi-optional RC parameter.........................................9
3.7 Receiving REG for a RK already registered.........................10
3.8 OPC list in the Registration Request Message......................11
3.9 Auditing procedure and congestion state...........................12
3.10 Response to an ASPIA message.....................................14
3.11 INFO and DIAG parameter length...................................15
4.Acknowledgements...................................................17
5.Authors' Addresses.................................................17
6.References.........................................................17
7.Changes Control....................................................18
Pastor, Morneault [Page 2]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
1. Introduction
This document contains a compilation of all defects found up until
March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFCxxxx]. These
defects may be of an editorial or technical nature. This document may
be thought of as a companion document to be used in the
implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFCxxxx and text within this
document, where noted, supersedes the text found in RFCxxxx. Each
error will be detailed within this document in the form of:
- The problem description,
- The text quoted from RFCxxxx,
- The replacement text,
- A description of the solution.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[RFC2119].
3. Corrections to RFC-M3UA
3.1 Parameter Containing Subparameters with Padding Bytes
3.1.1 Description of the problem
If a parameter contains subparameters with padding bytes, should the
parameter length include the subparameter padding bytes or not.
3.1.2 Text changes to the document
---------
Old text: (Section 3.2)
---------
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. Thus, a parameter with a zero-length Parameter Value
field would have a Length field of 4. The Parameter Length does not
include any padding bytes.
Pastor, Morneault [Page 3]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
---------
New text: (Section 3.2)
---------
Parameter Length: 16 bits (unsigned integer)
The Parameter Length field contains the size of the parameter in
bytes, including the Parameter Tag, Parameter Length, and Parameter
Value fields. Thus, a parameter with a zero-length Parameter Value
field would have a Length field of 4. The Parameter Length does not
include any padding bytes. If the parameter contains subparameters,
the Parameter Length field will include all the bytes of each
subparameter including subparameter padding bytes (if any).
3.1.3 Solution description
When calculating the length of a parameter that contains
subparameters, include the padding bytes of the subparameters.
3.2 Dynamic Registration Not Supported
3.2.1 Description of the problem
There is a need to be able to correlate a Dynamic Registration not
supported error to a Registration Request.
3.2.2 Text changes to the document
---------
Old text: (Section 4.4.1)
---------
If the SGP does not support the registration procedure, the SGP
returns an Error message to the ASP, with an error code of
"Unsupported Message Type".
---------
New text: (Section 4.4.1)
---------
If the SGP does not support the registration procedure, the SGP
returns an Error message to the ASP, with an error code of
"Unsupported Message Class".
Pastor, Morneault [Page 4]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
---------
Old text: (Section 3.8.1)
---------
The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received.
The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received.
---------
New text: (Section 3.8.1)
---------
The "Unsupported Message Class" error is sent if a message with an
unexpected or unsupported Message Class is received. For this error,
the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message.
The "Unsupported Message Type" error is sent if a message with an
unexpected or unsupported Message Type is received. For this error,
the Diagnostic Information parameter MUST be included with the first
40 bytes of the offending message.
---------
Old text:
---------
The Error message contains the following parameters:
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Optional
(*) Only mandatory for specific Error Codes
---------
New text:
---------
The Error message contains the following parameters:
Error Code Mandatory
Routing Context Mandatory*
Network Appearance Mandatory*
Affected Point Code Mandatory*
Diagnostic Information Semi-Optional
(*) Only mandatory for specific Error Codes
Pastor, Morneault [Page 5]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
3.2.3 Solution description
A SGP that does not support registration must return an Error
(Unsupported Message Class) message with the first 40 bytes of the
offending message (i.e. any Routing Key Management message sent by
the ASP) so that the ASP can correlate this error to the Registration
Request message.
Note that the changes to the "Unsupported Message Class" and
"Unsupported Message Type" text make this a general solution that
allows the ASP or SG side to correlate these error responses with the
offending message.
3.3 Contents of User Protocol Data
3.3.1 Description of the problem
There is a need to add a reference that contains the different SS7
message label types to ensure implementations take into account the
differences among these labels.
3.3.2 Text changes to the document
---------
Old text: (Section 3.3.1)
---------
Protocol Data: (variable)
The Protocol Data field contains a byte string of MTP-User
information from the original SS7 message starting with the
first byte of the original SS7 message following the Routing
Label.
---------
New text: (Section 3.3.1)
---------
Protocol Data: (variable)
The Protocol Data field contains a byte string of MTP-User
information from the original SS7 message starting with the
first byte of the original SS7 message following the Routing
Label [7].
Pastor, Morneault [Page 6]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
---------
Old text: (Section 9.1)
---------
[7] ITU-T Recommendations Q.701 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP
---------
New text: (Section 9.1)
---------
[7] ITU-T Recommendations Q.700 to Q.705, "Signalling System No. 7
(SS7) - Message Transfer Part (MTP)"
3.3.3 Solution description
A proper reference to the different SS7 message label types was
required.
3.4 NIF Not Available on SGP
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)
---------
-
---------
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.
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.
Pastor, Morneault [Page 7]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
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 ASP Inactive Acks for the affected AS(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 one or more
active AS(es).
3.4.3 Solution description
The addition of this text specifies the SGP/SG behavoir 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
clear whether it should be unique across SG-AS or unique across SCTP
associations
3.5.2 Text changes to the document
---------
Old text: (Section 3.3.1)
---------
Network Appearance: 32-bits (unsigned integer)
The Network Appearance parameter identifies the SS7 network context
for the message and implicitly identifies the SS7 Point Code format
used, the SS7 Network Indicator value, and the MTP3 and possibly the
MTP3-User protocol type/variant/version used within the specific SS7
network. Where an SG operates in the context of a single SS7
network, or individual SCTP associations are dedicated to each SS7
network context, the Network Appearance parameter is not required.
In other cases the parameter may be configured to be present for the
use of the receiver.
The Network Appearance parameter value is of local significance only,
coordinated between the SGP and ASP. Therefore, in the case where an
ASP is connected to more than one SGP, the same SS7 network context
may be identified by different Network Appearance values depending
over which SGP a message is being transmitted/received.
Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of the
Protocol Data field.
IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a
particular network context.
Pastor, Morneault [Page 8]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
---------
New text: (Section 3.3.1)
---------
Network Appearance: 32-bits (unsigned integer)
The Network Appearance parameter identifies the SS7 network context
for the message and implicitly identifies the used SS7 Point Code
format, the SS7 Network Indicator value, and the MTP3 and possibly
the MTP3-User protocol type/variant/version used within the specific
SS7 network. Where a SG operates in the context of a single SS7
network, or individual SCTP associations are dedicated to each SS7
network context, the Network Appearance parameter is not required.
In other cases the parameter may be configured to be present for the
use of the receiver.
The Network Appearance parameter value is of local significance only,
coordinated between the SG and AS. Therefore, in the case where an AS
is connected to more than one SG, the same SS7 network context may be
identified by different Network Appearance values depending over
which SG a message is being transmitted/received.
Where the optional Network Appearance parameter is present, it must
be the first parameter in the message as it defines the format of the
Protocol Data field.
IMPLEMENTATION NOTE: For simplicity of configuration it may be
desirable to use the same NA value across all nodes sharing a
particular network context.
3.5.3 Solution description
The text is modified to show that NA has to be coordinated between AS
to SG. This correction also aligns this text with the NA definition
in section 1.2 of the RFC.
3.6 Semi-optional RC parameter
3.6.1 Description of the problem
Some optional parameters are not always optional. The text should be
clear when optional parameters are not optional.
Pastor, Morneault [Page 9]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
3.6.2 Text changes to the document
---------
Old text: (Section 3.3.1)
---------
3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters:
Network Appearance Optional
Routing Context Optional
Protocol Data Mandatory
Correlation Id Optional
---------
New text: (Section 3.3.1)
---------
3.3.1 Payload Data Message (DATA)
The DATA message contains the SS7 MTP3-User protocol data, which is
an MTP-TRANSFER primitive, including the complete MTP3 Routing Label.
The DATA message contains the following variable length parameters:
Network Appearance Optional
Routing Context Semi-Optional
Protocol Data Mandatory
Correlation Id Optional
3.6.3 Solution description
Stating that the parameter is semi-optional, implies that it not
either optional or mandatory. In the parameter description the text
explains when it is mandatory and when optional.
3.7 Receiving REG for a RK already registered
3.7.1 Description of the problem
The RFC does not clearly specify what to do in this case.
3.7.2 Text changes to the document
---------
Old text: (Section 4.4.1)
---------
-
Pastor, Morneault [Page 10]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
--------
New text: (Section 4.4.1)
---------
If the SG determines that the received RK was already registered, the
SGP returns a Registration Response message to the ASP, containing a
Registration Result "Error - Cannot Support Unique Routing".
3.7.3 Solution description
By specifying the error code, the general problem of re-registering a
RK is solved. This error response applies whether the Routing Key is
Active or Inactive.
3.8 OPC list in the Registration Request Message
3.8.1 Description of the problem
It is not clear the reason of having an OPC list in the Registration
Request message. What is it valid for?
3.8.2 Text changes to the document
---------
Old text: (Section 3.6.1)
---------
OPC List:
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,
---------
New text: (Section 3.6.1)
---------
OPC List:
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. Multiple OPC values will only be valid in the case of
Alias Point Code configuration. The absence of the OPC List parameter
in the Routing Key indicates the use of any OPC value.
Pastor, Morneault [Page 11]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
3.8.3 Solution description
Including the scenario where this parameter is used (Alias point code
configurations), the problem is solved.
3.9 Auditing procedure and congestion state
3.9.1 Description of the problem
The current description of the AUDIT procedure in regards to
congestion state is not clear enough. When to send SCON is not
completely specified.
3.9.2 Text changes to the document
---------
Old text: (Section 3.3.1)
---------
[...]. Where the SGP maintains the congestion status of the SS7
destination, and the SS7 destination is congested, the SGP MUST
additionally respond with an SCON message before the DAVA or DRST
message. If the SS7 destination is available and congested, the SGP
MUST respond with an SCON message and then a DAVA message. If the
SS7 destination is restricted and congested, the SGP MUST respond
with an SCON message immediately followed by a DRST message. If the
SGP has no information on the availability status of the SS7
destination, the SGP responds with a DUNA message, as it has no
routing information to allow it to route traffic to this destination.
---------
New text: (Section 3.3.1)
---------
[...]. Where the SGP maintains the congestion status of the SS7
destination, the SGP MUST additionally respond with an SCON message
before the DAVA or DRST message. If the SS7 destination is
available, the SGP MUST respond with an SCON message (indicating the
appropriate congestion level) and then a DAVA message. If the SS7
destination is restricted, the SGP MUST respond with an SCON message
(with the appropriate congestion level) immediately followed by a
DRST message. If the SGP has no information on the availability
status of the SS7 destination, the SGP responds with a DUNA message,
as it has no routing information to allow it to route traffic to this
destination.
Pastor, Morneault [Page 12]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
Where the SGP does not maintain the congestion status of the SS7
destination (ITU international networks), the response to a DAUD
message should always be only a DAVA, DRST or DUNA message as
appropriate.
---------
Old text: (Section 5.4)
---------
5.4 M3UA/MTP3-User Boundary Examples
---------
New text: (Section 5.4, 5.5)
---------
5.4 Auditing examples
5.4.1 SG State: Uncongested / Unavailable
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(0) -------- |
| <------- DAVA ---------- |
5.4.2 SG state: Congested (Congestion Level=2) / Available
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------ SCON(2) -------- |
| <------- DAVA ---------- |
5.4.3 SG state: Unknown (ITU international network) / Available
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DAVA ---------- |
Pastor, Morneault [Page 13]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
5.4.4 SG state: Uncongested / Unavailable
ASP SGP
--- ---
| -------- DAUD ---------> |
| <------- DUNA ---------- |
5.5 M3UA/MTP3-User Boundary Examples
3.9.3 Solution description
Whenever a DAUD is received, it has to be responded with
DAVA/DUNA/DRST message depending on the peer node's state. If the SGP
has congestion control (i.e. no ITU international networks) an SCON
message with the appropiate congestion level should precede to the
DAVA/DRST messages upon a DAUD arrival.
A new examples section has been added to show this behavior.
3.10 Response to an ASPIA message
3.10.1 Description of the problem
It was not clear how to act in the following scenario:
ASP SGP
--- ---
| ------ ASPIA (RC1)-----> |
| <---- ASPIA Ack ------- |
| -----DEREG REQ (RC1)---> |
| <----DEREG RSP (RC1)---- |
| -------ASPIA (RC1)-----> |
What should SG do?
3.10.2 Text changes to the document
---------
Old text: (Section 4.5.3)
---------
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
Pastor, Morneault [Page 14]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
action MAY be initiated at the ASP by an M-ASP_INACTIVE request
primitive from Layer Management or MAY be initiated automatically by
an M3UA management function. In the case where an ASP is processing
the traffic for more than one Application Server across a common SCTP
association, the ASP Inactive message contains one or more Routing
Contexts to indicate for which Application Servers the ASP Inactive
message applies.
---------
New text: (Section 4.5.3)
---------
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
ASP Inactive message to the SGP or IPSP.
An ASP Inactive message MUST be always responded by the peer
(although other messages may be sent in the middle):
- If the corresponding RK is registered (statically or
dynamically), the peer should respond with an ASP Inactive Ack
message.
- If the RK is not registered, or the RC information is not valid,
the peer must respond with an ERROR message with Error Code =
"Invalid Routing Context".
- If the RC is missing and its specification is needed according
to the used configuration, the peer must respond with an ERROR
message with Error Code = "Missing Parameter".
The action of sending the ASP Inactive message MAY be initiated at
the ASP by an M-ASP_INACTIVE request primitive from Layer Management
or MAY be initiated automatically by an M3UA management function. In
the case where an ASP is processing the traffic for more than one
Application Server across a common SCTP association, the ASP Inactive
message contains one or more Routing Contexts to indicate for which
Application Servers the ASP Inactive message applies.
3.10.3 Solution description
A more detailed specification of the messages to be sent upon the
reception of an ASPIA has been added to the Inactive Procedures
Section.
3.11 INFO and DIAG parameter length
3.11.1 Description of the problem
At the 2nd interop a question was raised about accepting length of 4
bytes for DIAG and INFO parameters.
Pastor, Morneault [Page 15]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
3.11.2 Text changes to the document
---------
Old text: (Section 3.4.1)
---------
INFO String: variable length
The optional INFO String parameter can carry any meaningful UTF-8
[10] character string along with the message. Length of the INFO
String parameter is from 0 to 255 octets. No procedures are presently
identified for its use but the INFO String MAY be used for debugging
purposes.
---------
New text: (Section 3.4.1)
---------
INFO String: variable length
The optional INFO String parameter can carry any meaningful UTF-8
[10] character string along with the message. Length of the INFO
String parameter is from 0 to 255 octets. This means that No
procedures are presently identified for its use but the INFO String
MAY be used for debugging purposes. An INFO String with a zero length
parameter is not considered as an error (this means that the Length
field in the TLV will be set to 4).
---------
Old text: (Section 3.8.1)
---------
Diagnostic Information: variable length
When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in
identification of the error condition. The Diagnostic information
SHOULD contain the offending message.
---------
New text: (Section 3.8.1)
---------
Diagnostic Information: variable length
When included, the optional Diagnostic information can be any
information germane to the error condition, to assist in
identification of the error condition. The Diagnostic information
Pastor, Morneault [Page 16]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
SHOULD contain the offending message. A Diagnostic Information with a
zero length parameter is not considered as an error (this means that
the Length field in the TLV will be set to 4).
3.11.3 Solution description
It has been explicitly included the fact that a parameter with legth
zero is allowed.
4. Acknowledgements
-
5. Authors' Addresses
Javier Pastor-Balbas
Ericsson Espana S.A.
Ombu 3
28045 Madrid
Spain
Phone: +34-91-339-3819
Email: j.javier.pastor@ericsson.com
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
6. References
[M3UA] "MTP3 User Adaptation Layer"
Pastor, Morneault [Page 17]
INTERNET-DRAFT M3UA IMPLEMENTORÆS GUIDE March 22, 2002
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
7. Changes Control
TBD
Pastor, Morneault [Page 18]
| ||||||||||||||||
| Last modified: Wed, 12 Nov 2014 22:14:24 GMT Copyright © 2014 OpenSS7 Corporation All Rights Reserved. | |||||||||||||||||