| | |
|<----------------------------ASP Active (Ldshr)-----|
|-----------------------------ASP Active Ack-------->|
| | |
5.1.4 Three ASPs in an Application Server (n+k sparing, load-sharing
case)
This scenario shows the example IUA message flows for the
establishment of traffic between an SG and three ASPs in the same
Application Server, where two of the ASPs are brought to active and
share the load. In this case, a minimum of two ASPs are required to
handle the total traffic load (2+1 sparing).
SG ASP1 ASP2 ASP3
| | | |
|<------ASP Up-------| | |
|-----ASP Up Ack---->| | |
| | | |
|<--------------------------ASP Up-------| |
|------------------------ASPUp Ack)----->| |
| | | |
|<---------------------------------------------ASP Up--------|
|--------------------------------------------ASP Up Ack----->|
| | | |
| | | |
|<-ASP Act (Ldshr)---| | |
|----ASP Act Ack---->| | |
| | | |
|<---------------------ASP Act (Ldshr)---| |
|----------------------ASP Act Ack------>| |
| | | |
5.2 ASP Traffic Fail-over Examples
5.2.1 (1+1 Sparing, withdrawal of ASP, Back-up Over-ride)
The following example shows a case in which an ASP withdraws from
service:
SG ASP1 ASP2
| | |
|<-----ASP Inactive-------| |
|----ASP Inactive Ack---->| |
|-------------------NTFY(AS-Pending) --------------->|
| | |
|<------------------------------ ASP Active----------|
|-----------------------------ASP Active Ack)------->|
| |
In this case, the SG notifies ASP2 that the AS has moved to the Down
state. The SG could have also (optionally) sent a Notify message
when the AS moved to the Pending state.
Note: If the SG detects loss of the IUA peer (IUA heartbeat loss or
detection of SCTP failure), the initial SG-ASP1 ASP Inactive message
exchange would not occur.
5.2.2 (1+1 Sparing, Back-up Over-ride)
The following example shows a case in which ASP2 wishes to over-ride
ASP1 and take over the traffic:
SG ASP1 ASP2
| | |
|<-------------------------------ASP Active----------|
|-----------------------------ASP Active Ack-------->|
|----NTFY( Alt ASP-Act)-->|
| | |
In this case, the SG notifies ASP1 that an alternative ASP has
overridden it.
5.2.3 (n+k Sparing, Load-sharing case, withdrawal of ASP)
Following on from the example in Section 5.1.4, and ASP1 withdraws
from service
SG ASP1 ASP2 ASP3
| | | |
|<----ASP Inact------| | |
|---ASP Inact Ack--->| | |
| | | |
|---------------------------------NTFY(Ins. ASPs)----------->|
| | | |
|<-----------------------------------------ASP Act (Ldshr)---|
|-------------------------------------------ASP Act (Ack)--->|
| | | |
In this case, the SG has knowledge of the minimum ASP resources
required (implementation dependent) for example if the SG knows that
n+k = 2+1 for a load-share AS and n currently equals 1.
Note: If the SG detects loss of the ASP1 IUA peer (IUA heartbeat
loss or detection of SCTP failure), the first SG-ASP1 ASP Inactive
message exchange would not occur.
5.3 Q.921/Q.931 primitives backhaul Examples
When the IUA layer on the ASP has a QPTM message to send to the SG,
it will do the following:
- Determine the correct SG
- Find the SCTP association to the chosen SG
- Determine the correct stream in the SCTP association based on
the D channel
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- Send the QPTM message to the remote IUA peer in the SG, over
the SCTP association
When the IUA layer on the SG has a QPTM message to send to the ASP,
it will do the following:
- Determine the AS for the Interface Identifier
- Determine the Active ASP (SCTP association) within the AS
- Determine the correct stream in the SCTP association based on
the D channel
- Fill in the QPTM message, fill in IUA Message Header, fill in
Common Header
- Send the QPTM message to the remote IUA peer in the ASP, over
the SCTP association
An example of the message flows for establishing a data link on a
signaling channel, passing PDUs and releasing a data link on a
signaling channel is shown below. An active association between MGC
and SG is established (Section 5.1) prior to the following message
flows.
SG ASP
<----------- Establish Request
Establish Confirm ---------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
Data Indication ----------->
<----------- Data Request
<----------- Data Request
Data Indication ----------->
<----------- Release Request (RELEASE_MGMT)
Release Confirm ---------->
An example of the message flows for a failed attempt to establish a
data link on the signaling channel is shown below. In this case, the
gateway has a problem with its physical connection (e.g., Red Alarm),
so it cannot establish a data link on the signaling channel.
SG ASP
<----------- Establish Request (ESTABLISH_START)
Release Indication ---------->
(RELEASE_PHYS)
5.4 Layer Management Communication Examples
An example of the message flows for communication between Layer
Management modules between SG and ASP is shown below. An active
association between ASP and SG is established (Section 5.1) prior to
the following message flows.
SG ASP
<----------- Data Request
Error Indication ---------->
(INVALID_TEI)
<----------- TEI Status Request
TEI Status Confirm ---------->
(Unassigned)
6.0 Security
IUA is designed to carry signaling messages for telephony services.
As such, IUA MUST involve the security needs of several parties the
end users of the services; the network providers and the applications
involved. Additional requirements MAY come from local regulation.
While having some overlapping security needs, any security solution
SHOULD fulfill all of the different parties' needs.
6.1 Threats
There is no quick fix, one-size-fits-all solution for security. As a
transport protocol, IUA has the following security objectives:
* Availability of reliable and timely user data transport.
* Integrity of user data transport.
* Confidentiality of user data.
IUA runs on top of SCTP. SCTP [3] provides certain transport related
security features, such as
* Blind Denial of Service Attacks
* Flooding
* Masquerade
* Improper Monopolization of Services
When IUA is running in professionally managed corporate or service
provider network, it is reasonable to expect that this network
includes an appropriate security policy framework. The "Site
Security Handbook" [5] SHOULD be consulted for guidance.
When the network in which IUA runs in involves more than one party,
it MAY NOT be reasonable to expect that all parties have implemented
security in a sufficient manner. In such a case, it is recommended
that IPSEC is used to ensure confidentiality of user payload.
Consult [6] for more information on configuring IPSEC services.
6.2 Protecting Confidentiality
Particularly for mobile users, the requirement for confidentiality
MAY include the masking of IP addresses and ports. In this case
application level encryption is not sufficient; IPSEC ESP SHOULD be
used instead. Regardless of which level performs the encryption, the
IPSEC ISAKMP service SHOULD be used for key management.
7.0 IANA Considerations
7.1 SCTP Payload Protocol Identifier
A request will be made to IANA to assign an IUA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered:
IUA "1"
The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but MAY be used by
certain network entities to identify the type of information being
carried in a Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being
presented to it by SCTP.
7.2 IUA Protocol Extensions
This protocol may also be extended through IANA in three ways:
-- through definition of additional message classes,
-- through definition of additional message types, and
-- through definition of additional message parameters.
The definition and use of new message classes, types and parameters
is an integral part of SIGTRAN adaptation layers. Thus, these
extensions are assigned by IANA through an IETF Consensus action as
defined in [RFC2434].
The proposed extension must in no way adversely affect the general
working of the protocol.
7.2.1 IETF Defined Message Classes
The documentation for a new message class MUST include the following
information:
(a) A long and short name for the message class.
(b) A detailed description of the purpose of the message class.
7.2.2 IETF Defined Message Types
Documentation of the message type MUST contain the following
information:
(a) A long and short name for the new message type.
(b) A detailed description of the structure of the message.
(c) A detailed definition and description of intended use of each
field within the message.
ti3 (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 which 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.0 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.
9.0 References
[1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System
No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer -
General Aspects'
[2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a
Voice over Packet Network'
[3] 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", RFC2960, October 2000.
[4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L.,
Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural
Framework for Signaling Transport", RFC2719, October 1999.
[5] Fraser, B., "Site Security Handbook", FYI 8, RFC2196, September
1997.
[6] Kent, S. and R. Atkinson, "Security Architecture for the Internet
Protocol", RFC2401, November 1998.
[7] Bradner, s., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC2119, March 1997.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC2434, October 1998.
10.0 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
Telcordia Technologies
NVC-2Z439
331 Newman Springs Road
Red Bank, NJ 07701
USA
Phone: +1-732-758-5260
EMail: srengasa@telcordia.com
Greg Sidebottom
Nortel Networks
3685 Richmond Road
Nepean, Ontario
Canada K2H5B7
Phone: +1-613-763-7305
EMail: gregside@nortelnetworks.com
10. 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.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.