(d) A detailed procedural description of the use of the new
message type within the operation of the protocol.
(e) A detailed description of error conditions when receiving this
message type.
When an implementation receives a message type that it does not
support, it MUST respond with an Error (ERR) message with an Error
Code of Unsupported Message Type.
7.2.3. IETF-Defined TLV Parameter Extension
Documentation of the message parameter MUST contain the following
information:
(a) Name of the parameter type.
(b) Detailed description of the structure of the parameter field.
This structure MUST conform to the general type-length-value
format described in Section 3.1.5.
(c) Detailed definition of each component of the parameter value.
(d) Detailed description of the intended use of this parameter type,
and an indication of whether and under what circumstances
multiple instances of this parameter type may be found within the
same message type.
8. Timer Values
The following are suggestions for default timer values.
T(r) 3-5 seconds
T(ack) 2-5 seconds
T(beat) Heartbeat Timer 30 seconds
9. Acknowledgements
The authors would like to thank Alex Audu, Maria Sonia Vazquez
Arevalillo, Ming-te Chao, Keith Drage, Norm Glaude, Nikhil Jain,
Bernard Kuc, Ming Lin, Stephen Lorusso, John Loughney, Barry
Nagelberg, Neil Olson, Lyndon Ong, Heinz Prantner, Jose Luis Jimenez
Ramirez, Ian Rytina, Michael Tuexen, and Hank Wang for their valuable
comments and suggestions.
10. References
10.1. Normative References
[1] ITU-T Recommendation Q.920, ’Digital Subscriber signaling System
No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer -
General Aspects’
[2] Coded Character Set--7-Bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[3] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
3788, June 2004.
10.2. Informative References
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Framework
Architecture for Signaling Transport", RFC 2719, October 1999.
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[8] Stone, J., Stewart, R., and D. Otis, "Stream Control
Transmission Protocol (SCTP) Checksum Change", RFC 3309,
September 2002.
11. Change Log
Below is a list of the major changes between this document and RFC
3057.
1. The TEI Query message was added.
2. An explanation of the DLCI format (shown in Figure 6) is
provided.
3. Aligned the ASP and AS procedures in Section 4 with RFC3331 and
RFC3332.
4. Alinged the format of the ASPSM and ASPTM messages with RFC3331
and RFC3332. These changes include removing the Reason field
from the ASP Down and ASP Down Ack messages and the Traffic Mode
Type field from the ASP Inactive and ASP Inactive Ack messages.
5. Sections 1.3.3 and 1.3.4 were moved to Appendix A. A new section
was added in place of Section 1.3.3.
6. The references have been split between Normative and Informative.
7. The new Sigtran security document is referenced and Section 6 has
been updated appropriately.
Appendix A
A.1. Signaling Network Architecture
A Signaling Gateway is used to support the transport of Q.921-User
signaling traffic to one or more distributed ASPs (e.g., MGCs).
Clearly, the IUA protocol is not designed to meet the performance and
reliability requirements for such transport by itself. However, the
conjunction of distributed architecture and redundant networks does
allow for a sufficiently reliable transport of signaling traffic over
IP. The IUA protocol is flexible enough to allow its operation and
management in a variety of physical configurations, enabling Network
Operators to meet their performance and reliability requirements.
To meet the ISDN signaling reliability and performance requirements
for carrier grade networks, Network Operators SHOULD ensure that
there is no single point of failure provisioned in the end-to-end
network architecture between an ISDN node and an IP ASP.
Depending of course on the reliability of the SG and ASP functional
elements, this can typically be met by the provision of redundant
Quality of Service (QoS)-bounded IP network paths for SCTP
Associations between SCTP End Points, and redundant Hosts, and
redundant SGs. The distribution of ASPs within the available Hosts
is also important. For a particular Application Server, the related
ASPs SHOULD be distributed over at least two Hosts.
An example logical network architecture relevant to carrier-grade
operation in the IP network domain is shown in Figure 8 below:
Host1
******** **************
* *_________________________________________* ******** *
* * _________* * ASP1 * *
* SG1 * SCTP Associations | * ******** *
* *_______________________ | * *
******** | | **************
| |
******** | |
* *_______________________________|
* * |
* SG2 * SCTP Associations |
* *____________ |
* * | | Host2
******** | | **************
| |_________________* ******** *
|____________________________* * ASP1 * *
* ******** *
* *
**************
.
.
.
Figure 8. Logical Model Example
For carrier-grade networks, the failure or isolation of a particular
ASP SHOULD NOT cause stable calls to be dropped. This implies that
ASPs need, in some cases, to share the call state or be able to pass
the call state between each other. However, this sharing or
communication of call state information is outside the scope of this
document.
A.2. Application Server Process Redundancy
To avoid a single point of failure, it is recommended that a minimum
of two ASPs be in the list, resident in separate hosts and therefore
available over different SCTP Associations. For example, in the
network shown in Figure 8, all messages from a particular D Channel
(Interface Identifier) could be sent to ASP1 in Host1 or ASP1 in
Host2. The AS list at SG1 might look like the following:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Inactive
In this 1+1 redundancy case, ASP1 in Host1 would be sent any incoming
message for the Interface Identifiers registered. ASP1 in Host2
would normally be brought to the active state upon failure of, or
loss of connectivity to, ASP1/Host1. In this example, both ASPs are
Up, meaning that the related SCTP association and far-end IUA peer
are ready.
The AS List at SG1 might also be set up in load-share mode as shown
below:
Interface Identifier(s) - Application Server #1
ASP1/Host1 - State=Up, Active
ASP1/Host2 - State=Up, Active
In this case, both the ASPs would be sent a portion of the traffic.
In the process of fail-over, it is recommended that in the case of
ASPs supporting call processing, stable calls do not get released.
It is possible that calls in transition MAY fail, although measures
of communication between the ASPs involved can be used to mitigate
this problem. For example, the two ASPs MAY share call state via
shared memory, or MAY use an ASP-to-ASP protocol to pass call state
information. The ASP-to-ASP protocol is outside the scope of this
document.
Authors’ Addresses
Ken Morneault
Cisco Systems Inc.
13615 Dulles Technology Drive
Herndon, VA. 20171
USA
Phone: +1-703-484-3323
EMail: kmorneau@cisco.com
Malleswar Kalla
Telcordia Technologies
PYA 2J-341
3 Corporate Place
Piscataway, NJ 08854
USA
Phone: +1-732-699-3728
EMail: mkalla@telcordia.com
Selvam Rengasami
Tridea Works
Phone: +1-732-512-0969
EMail: selvam@trideaworks.com
Greg Sidebottom
Signatus Technologies
Kanata, Ontario, Canada
EMail: greg@signatustechnologies.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).