draft-ietf-sigtran-m3ua-implementors-guide-01.txt   draft-ietf-sigtran-m3ua-implementors-guide-02.txt 
Network Working Group Javier Pastor Network Working Group Javier Pastor-Balbas
INTERNET-DRAFT Ericsson INTERNET-DRAFT Ericsson
Expires: December 2002 Expires: April 2003
Ken Morneault Ken Morneault
Cisco Systems Cisco Systems
June, 2002 October, 2002
M3UA ImplementorĘs Guide M3UA Implementor's Guide
<draft-ietf-sigtran-m3ua-implementors-guide-01.txt> <draft-ietf-sigtran-m3ua-implementors-guide-02.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 40 skipping to change at page 1, line 40
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This document is an individual submission to the IETF. Comments This document is an individual submission to the IETF. Comments
should be directed to the authors. should be directed to the authors.
Abstract Abstract
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 M3UA [RFCxxx]. These defects may be of an October 2002 for M3UA [RFC3332]. These defects may be of an editorial
editorial or technical nature. This document may be thought of as a or technical nature. This document may be thought of as a companion
companion document to be used in the implementation of M3UA to document to be used in the implementation of M3UA to clarify errors
clarify errors in the original M3UA document. This document updates in the original M3UA document. This document updates RFC3332 and text
RFCxxxx and text within this document supersedes the text found in within this document supersedes the text found in RFC3332.
RFCxxxx
TABLE OF CONTENTS TABLE OF CONTENTS
1.Introduction........................................................3 1.Introduction........................................................3
2.Conventions.........................................................3 2.Conventions.........................................................3
3.Corrections to RFC-M3UA.............................................3 3.Corrections to RFC-M3UA.............................................3
3.1 Parameter Containing Subparameters with Padding Bytes.............3 3.1 Parameter Containing Subparameters with Padding Bytes..............3
3.2 Dynamic Registration Not Supported................................4 3.2 Dynamic Registration Not Supported.................................4
3.3 Contents of User Protocol Data....................................6 3.3 Contents of User Protocol Data.....................................6
3.4 NIF Not Available on SGP..........................................7 3.4 NIF Not Available on SGP...........................................7
3.5 Scope of Network Appearance.......................................8 3.5 Scope of Network Appearance........................................8
3.6 Semi-optional RC parameter........................................9 3.6 Semi-optional RC parameter.........................................9
3.7 Receiving REG for a RK already registered........................12 3.7 Receiving REG for a RK already registered.........................12
3.8 OPC list in the Registration Request Message.....................13 3.8 OPC list in the Registration Request Message......................13
3.9 Auditing procedure and congestion state..........................13 3.9 Auditing procedure and congestion state...........................14
3.10 Response to an ASPIA message....................................16 3.10 Response to an ASPIA message.....................................16
3.11 INFO and DIAG parameter length..................................17 3.11 INFO and DIAG parameter length...................................18
3.12 IPSP stuff......................................................18 3.12 IPSP stuff.......................................................19
3.13 Messages and Streams............................................24 3.13 Messages and Streams.............................................24
3.14 ASP Id for IPSP communication...................................24 3.14 ASP Id for IPSP communication....................................25
3.15 n+k redundancy..................................................26 3.15 n+k redundancy...................................................26
4.Acknowledgements...................................................30 4.Acknowledgements...................................................31
5.Authors' Addresses.................................................30 5.Authors' Addresses.................................................31
6.References.........................................................31 6.References.........................................................31
7.Changes Control....................................................32 7.Changes Control....................................................33
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) [RFCxxxx]. These March 2002 for the MTP3 User Adaptation Layer (M3UA) [RFC3332]. These
defects may be of an editorial or technical nature. This document may defects may be of an editorial or technical nature. This document may
be thought of as a companion document to be used in the be thought of as a companion document to be used in the
implementation of M3UA to clarify errors in the original M3UA implementation of M3UA to clarify errors in the original M3UA
document. This document updates RFCxxxx and text within this document. This document updates RFC3332 and text within this
document, where noted, supersedes the text found in RFCxxxx. 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 RFCxxxx, - The text quoted from RFC3332,
- The replacement text, - The replacement text,
- A description of the solution. - A description of the solution.
1.1 Abbreviations
SPC Signalling Point Code
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in they appear in this document, are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Corrections to RFC-M3UA 3. Corrections to RFC-M3UA
3.1 Parameter Containing Subparameters with Padding Bytes 3.1 Parameter Containing Subparameters with Padding Bytes
skipping to change at page 7, line 44 skipping to change at page 7, line 44
Old text: (None) Old text: (None)
--------- ---------
None. None.
--------- ---------
New text: (Section 4.7) New text: (Section 4.7)
--------- ---------
If the SG (all the SGPs) is isolated from the NIF, then all the users If the SG (all the SGPs) is isolated from the NIF, then all the users
are isolated from the SS7 network. An ASP Inactive Ack message MUST are isolated from the SS7 network. A DUNA(*) message MUST be sent
be sent from the SGPs to all the ASPs. from the SGPs to all the ASPs.
If only one SGP in the SG is isolated entirely from the NIF, the SGP 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 SHOULD abort its associations. An alternative would be for the SGP to
send ASP Down Ack. send ASP Down Ack.
If one or more SGP suffer a partial failure (where aborting the If one or more SGP suffer a partial failure (where aborting the
association(s) would cause all active AS(es) to fail), then the SGP association(s) would cause all active AS(es) to fail), then the SGP
MUST send ASP Inactive Ack messages for the affected AS(es). This is MUST send DUNA messages for the affected SPC(es). This is the case
the case where an SGP can continue to service one or more active where an SGP can continue to service one or more active AS(es), but
AS(es), but due to a partial failure it is unable to service one or due to a partial failure it is unable to service other(s) active
more active AS(es). AS(es).
3.4.3 Solution description 3.4.3 Solution description
The addition of this text specifies the SGP/SG behavoir for the The addition of this text specifies the SGP/SG behavoir for the
different scenarios of the NIF becoming unavailable on the SGP/SG. different scenarios of the NIF becoming unavailable on the SGP/SG.
3.5 Scope of Network Appearance 3.5 Scope of Network Appearance
3.5.1 Description of the problem 3.5.1 Description of the problem
skipping to change at page 13, line 25 skipping to change at page 13, line 25
Old text: (Section 3.6.1) Old text: (Section 3.6.1)
--------- ---------
OPC List: OPC List:
The Originating Point Code List parameter contains one or more SS7 The Originating Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point Code 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 parameter. The absence of the OPC List parameter in the Routing Key
indicates the use of any OPC value, indicates the use of any OPC value,
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Origination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
--------- ---------
New text: (Section 3.6.1) New text: (Section 3.6.1)
--------- ---------
OPC List: DPC List:
The Originating Point Code List parameter contains one or more SS7 The Destination Point Code List parameter contains one or more SS7
OPC entries, and its format is the same as the Destination Point Code DPC entries, and its format is the same as the Destination Point Code
parameter. Multiple OPC values will only be valid in the case of parameter. Multiple DPC values will only be valid in the case of
Alias Point Code configuration. The absence of the OPC List parameter Alias Point Code configuration. The absence of the DPC List parameter
in the Routing Key indicates the use of any OPC value. in the Routing Key indicates the use of the DPC value as the only
posible DPC for the AS.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag = 0x020e | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ... /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mask = 0 | Destination Point Code #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.8.3 Solution description 3.8.3 Solution description
Including the scenario where this parameter is used (Alias point code Including the scenario where this parameter is used (Alias point code
configurations), the problem is solved. configurations), the problem is solved. The parameter name has also
be changed to "Destination" since it is the way that the SG sees it.
3.9 Auditing procedure and congestion state 3.9 Auditing procedure and congestion state
3.9.1 Description of the problem 3.9.1 Description of the problem
The current description of the AUDIT procedure in regards to The current description of the AUDIT procedure in regards to
congestion state is not clear enough. When to send SCON is not congestion state is not clear enough. When to send SCON is not
completely specified. completely specified.
3.9.2 Text changes to the document 3.9.2 Text changes to the document
skipping to change at page 14, line 39 skipping to change at page 15, line 22
available, the SGP MUST respond with an SCON message (indicating the available, the SGP MUST respond with an SCON message (indicating the
appropriate congestion level) and then a DAVA message. If the SS7 appropriate congestion level) and then a DAVA message. If the SS7
destination is restricted, the SGP MUST respond with an SCON message destination is restricted, the SGP MUST respond with an SCON message
(with the appropriate congestion level) immediately followed by a (with the appropriate congestion level) immediately followed by a
DRST message. If the SGP has no information on the availability DRST message. If the SGP has no information on the availability
status of the SS7 destination, the SGP responds with a DUNA message, 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 as it has no routing information to allow it to route traffic to this
destination. destination.
Where the SGP does not maintain the congestion status of the SS7 Where the SGP does not maintain the congestion status of the SS7
destination (ITU international networks), the response to a DAUD destination, the response to a DAUD message should always be only a
message should always be only a DAVA, DRST or DUNA message as DAVA, DRST or DUNA message as appropriate.
appropriate.
--------- ---------
Old text: (Section 5.4) Old text: (Section 5.4)
--------- ---------
5.4 M3UA/MTP3-User Boundary Examples 5.4 M3UA/MTP3-User Boundary Examples
--------- ---------
New text: (Section 5.4, 5.5) New text: (Section 5.4, 5.5)
--------- ---------
skipping to change at page 15, line 23 skipping to change at page 16, line 4
5.4.2 SG state: Congested (Congestion Level=2) / Available 5.4.2 SG state: Congested (Congestion Level=2) / Available
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------ SCON(2) -------- | | <------ SCON(2) -------- |
| <------- DAVA ---------- | | <------- DAVA ---------- |
5.4.3 SG state: Unknown / Available
5.4.3 SG state: Unknown (ITU international network) / Available
ASP SGP ASP SGP
--- --- --- ---
| -------- DAUD ---------> | | -------- DAUD ---------> |
| <------- DAVA ---------- | | <------- DAVA ---------- |
5.4.4 SG state: Uncongested / Unavailable 5.4.4 SG state: Uncongested / Unavailable
ASP SGP ASP SGP
--- --- --- ---
skipping to change at page 31, line 4 skipping to change at page 31, line 30
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
6. References 6. References
[M3UA] "MTP3 User Adaptation Layer" [RFC3332] "Signaling System 7 (SS7) Message Transfer Part 3 (MTP3) -
User Adaptation Layer (M3UA)". G. Sidebotton, K.
Morneault, J. Pastor-Balbas.
7. Changes Control 7. Changes Control
7.1 Changes from v00 to v01 7.1 Changes from v00 to v01
- Typos. - Typos.
- Update all the RC references to show it is a semi-optional - Update all the RC references to show it is a semi-optional
parameter. parameter.
skipping to change at page 31, line 20 skipping to change at page 32, line 4
7.1 Changes from v00 to v01 7.1 Changes from v00 to v01
- Typos. - Typos.
- Update all the RC references to show it is a semi-optional - Update all the RC references to show it is a semi-optional
parameter. parameter.
- DUNA(*) substituted for ASPIA-ACK when NIF is not available. - DUNA(*) substituted for ASPIA-ACK when NIF is not available.
- New sections added: - New sections added:
- IPSP stuff - IPSP stuff
- Messages and Streams - Messages and Streams
- ASP Id for IPSP communication - ASP Id for IPSP communication
- n+k redundancy - n+k redundancy
7.2 Changes from v01 to v02
- ASPIA-ACK substituted for DUNA when NIF is not available since
it also allows inter-ASP routing.
- Changed REGREQ's parameter from "Origination Point Code" to
"Destination Point Code".
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2002). 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/