Network Working Group Vipin Gupta
INTERNET-DRAFT Hughes Software Systems
Kamesh Kaul
Hughes Software Systems
Expires in six months Jan 2002
SIGTRAN Inter Signaling Process Communication
<draft-vk-sigtran-isp-communication-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. 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 to cite them other than as 'work in progress.'
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
To learn the current status of any Internet-Draft, please check the
'1id-abstracts.txt' listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Gupta [Page 1]
Internet Draft Inter Signaling Process Communication Dec 2001
Abstract
This Internet Draft explains the need of Inter Signaling process
communication in the systems making use of SIGTRAN protocol. It also
proposes procedures and various interface primitives for inter signaling
process communication. This draft mainly focuses on Signaling Gateway
Processes and Application Server Processes as defined in SIGTRAN.
Kaul [Page 2]
Internet Draft Inter Signaling Process Communication Dec 2001
TABLE OF CONTENTS
1. Introduction.......................................................4
1.1 Scope.........................................................4
1.2 Terminology...................................................5
1.3 Assumptions...................................................8
2. Need for Inter SP communication....................................8
2.1 Example Scenarios.............................................9
2.2 Traffic Forwarding between SPs...............................11
2.3 Mis-Sequencing Problem and its Solution......................12
2.4 Sequence Numbers.............................................13
2.5 Information sharing between SPs..............................13
2.5.1 Information sharing between SGPs.......................14
2.5.2 Information sharing between ASPs.......................14
3. Inter-SP Interface................................................14
4. Support from SIGTRAN UA Protocols.................................15
4.1 Parameters required in DATA Messages.........................15
4.1.1 Sequence Number........................................16
4.1.2 SP ID..................................................16
4.2 Messages Required in SIGTRAN UA protocols....................16
5. Example of Inter SP Coordination..................................17
6. Acknowledgements..................................................19
7. References........................................................19
8. Author's Addresses................................................19
Gupta [Page 3]
Internet Draft Inter Signaling Process Communication Dec 2001
1. Introduction
This draft explains the need of inter signaling process communication
and proposes procedures and interfaces to support inter signaling
process communication between various signaling processes supporting
the same logical entity. These logical entities are Application Server
and Signaling Gateway as defined in the SIGTRAN. It mainly focuses on
how multiple Signaling Processes can coordinate with each other to
provide high availability of SIGTRAN for the SS7 traffic.
The main focus is to maximize:
(a) availability of logical SS7 nodes in the IP domain served by
Application Server Processes
(b) accessibility to SS7 network using Signaling Gateway Processes.
1.1 Scope
There is a need for networks using SIGTRAN to meet the high
availability requirements imposed by the SS7 standards. One of the most
effective methods to achieve this is by supporting multiple Signaling
processes in the same logical entity and providing Inter Signaling
Process communication between them.
The scope of this draft is to:
(a) explain the need of Inter Signaling process communication
(b) propose procedures and interface primitives for Inter Signaling
Process communication.
Kaul [Page 4]
Internet Draft Inter Signaling Process Communication Dec 2001
1.2 Terminology
Application Server (AS) - A logical entity serving a specific Routing
Key. An example of an Application Server is a virtual switch element
handling all call processing for a unique range of PSTN trunks,
identified by an SS7 SIO/DPC/OPC/CIC_range. Another example is a
virtual database element, handling all HLR transactions for a
particular SS7 DPC/OPC/SCCP_SSN combination. The AS contains a set of
one or more unique Application Server Processes, of which one or more
is normally actively processing traffic. Note that there is a 1:1
relationship between an AS and a Routing Key.
Application Server Process (ASP) - A process instance of an Application
Server. An Application Server Process serves as an active or backup
process of an Application Server (e.g., part of a distributed virtual
switch or database). Examples of ASPs are processes (or process
instances) of MGCs, IP SCPs or IP HLRs. An ASP contains an SCTP
endpoint and may be configured to process signalling traffic within
more than one Application Server.
Association - An association refers to an SCTP association. The
association provides the transport for the delivery of SIGTRAN UA
protocol data units.
IP Server Process (IPSP) - A process instance of an IP-based
application. An IPSP is essentially the same as an ASP, except that it
uses SIGTRAN UA in a point-to-point fashion. Conceptually, an IPSP does
not use theservices of a Signalling Gateway node.
Failover - The capability to reroute signalling traffic as required
to an alternate Application Server Process, or group of ASPs, within an
Application Server in the event of failure or unavailability of a
currently used Application Server Process. Failover also applies upon
the return to service of a previously unavailable Application Server
Process.
Host - The computing platform that the process (SGP, ASP or IPSP) is
running on.
Gupta [Page 5]
Internet Draft Inter Signaling Process Communication Dec 2001
Layer Management - Layer Management is a nodal function that handles
the inputs and outputs between the SIGTRAN UA layer and a local
management entity.
Linkset - A number of signalling links that directly interconnect two
signalling points, which are used as a module.
MTP - The Message Transfer Part of the SS7 protocol.
MTP3 - MTP Level 3, the signalling network layer of SS7
MTP3-User - Any protocol normally using the services of the SS7 MTP3
(e.g., ISUP, SCCP, TUP, etc.).
Network Appearance - The Network Appearance is a local reference
shared by SG and AS (typically an integer) that together with an
Signaling Point Code uniquely identifies an SS7 node by indicating
the specific SS7 network it belongs to. It can be used to distinguish
between signalling traffic associated with different networks being
sent between the SG and the ASP over a common SCTP association. An
example scenario is where an SG appears as an element in multiple
separate national SS7 networks and the same Signaling Point Code
value may be reused in different networks.
Network Byte Order: Most significant byte first, a.k.a Big Endian.
Routing Key: A Routing Key describes a set of SS7 parameters and
parameter values that uniquely define the range of signalling traffic
to be handled by a particular Application Server. Parameters within the
Routing Key cannot extend across more than a single Signalling Point
Management Cluster.
Routing Context - A value that uniquely identifies a Routing Key.
Routing Context values are either configured using a configuration
management interface, or by using the routing key management procedures
defined in this document.
Kaul [Page 6]
Internet Draft Inter Signaling Process Communication Dec 2001
Signalling Gateway Process (SGP) - A process instance of a Signalling
Gateway. It serves as an active, backup, loadsharing or broadcast
process of a Signalling Gateway.
Signalling Gateway - An SG is a signaling agent that receives/sends SCN
native signaling at the edge of the IP network [1]. An SG appears to
the SS7 network as an SS7 Signalling Point. An SG contains a set of
one or more unique Signalling Gateway Processes, of which one or more
is normally actively processing traffic. Where an SG contains more
than one SGP, the SG is a logical entity and the contained SGPs are
assumed to be coordinated into a single management view to the SS7
network and to the supported Application Servers.
Signalling Process (SP) - A process instance that uses SIGTRAN UA to
communicate with other signalling processes. An ASP, an SGP and an
IPSP are all signalling processes.
Signalling Point Management Cluster (SPMC) - The complete set of
Application Servers represented to the SS7 network under a single MTP
entity (Signalling Point) in one specific Network Appearance. SPMCs
are used to aggregate the availability, congestion, and user part
status of an MTP entity (Signalling Point) that is distributed in the
IP domain, for the purpose of supporting MTP3 management procedures
towards the SS7 network. In some cases, the SG itself may also be a
member of the SPMC. In this case, the SG availability /congestion
/User_Part status should also be taken into account when considering
any supporting MTP3 management actions.
Stream - A stream refers to an SCTP stream; a unidirectional logical
channel established from one SCTP endpoint to another associated SCTP
endpoint, within which all user messages are delivered in-sequence
except for those submitted to the unordered delivery service.
SIGTRAN UA - It refers to any SIGTRAN User Adaptation Layer like M3UA,
SUA or M2UA.
Gupta [Page 7]
Internet Draft Inter Signaling Process Communication Dec 2001
1.3 Assumptions
This draft assumes the following:
(a) The IP network used by the SIGTRAN is well designed and available
all the time, i.e., if communication lost primitive is received from
SCTP then it is not due to any failures in the underlying IP network.
(b) Method of communication between two coordinating SPs is reliable
and no messages are lost. SPs communicating with each other use a
mechanism which ensures no loss and mis-sequencing of messages.
2. Need for Inter SP Communication
SIGTRAN is designed to transport the SS7 signaling over the IP network.
This implies that the systems supporting SIGTRAN should be highly
reliable. Considering a complete SIGTRAN system, it consists of IP
network and Signaling Processes running over it. Properly designed
networks will certainly ensure less failures but improper
configurations and local failures in SPs may become a source of overall
failure in a SIGTRAN system.
Inter Signaling Process communication can be utilised in order to
overcome some of the deficiencies arising due to improper
configurations or local failures in an SP. Even if a single SP in a
logical entity is available then no SS7 traffic on that logical entity
should be discarded.
When an SP becomes inactive and other active SP takes over all the
traffic of the inactive SP then mis-sequencing of SS7 traffic can take
place unless some sort of inter SP coordination is present.Similarly
if a SP becomes newly active and takes over some part of the traffic
from the other active SPs then again mis-sequencing can take place
if inter SP coordination is absent.
Kaul [Page 8]
Internet Draft Inter Signaling Process Communication Dec 2001
2.1 Example Scenarios
Take an example where an SG consists of three SGPs and the AS consists
of one ASP.
+---------------------+
| SG1 |
| +----------------+ |
| | | |
| | SGP1 +--+------+
| | | | |
| +----------------+ | |
| | | +--------------------+
| | | | AS1 |
| +----------------+ | +------+ | |
| | | | | | +---------------+ |
| | SGP2 | | +--+--+ | |
| | +--+----------------+--+ ASP1 | |
| +----------------+ | +--+--+ | |
| | | | +---------------+ |
| +----------------+ | +------+ | |
| | | | | | |
| | SGP3 | | | +--------------------+
| | +--+------+
| +----------------+ |
| |
+---------------------+
Consider the case when ASP1 is ACTIVE in all the SGPs. All the SGPs
are sending/receiving data to/from the ASP1. SG is operating in
loadsharing mode. Now ASP1 becomes INACTIVE in SGP2. In normal case
if the SGPs are not coordinating with each other then SS7 traffic at
SGP2 is buffered for pending time period and after that it will
be rejected. Even though the AS is reachable via SGP1 and SGP3, SG
is rejecting a portion of SS7 traffic which is responsibility of SGP2.
Here it is assumed that the distribution mechanism at SG, which is
distributing the traffic received from the SS7 network between the
SGPs is not aware of the state of AS in SGPs. Even if the distribution
mechanism is intelligent enough to re-distribute the traffic, it cannot
Gupta [Page 9]
Internet Draft Inter Signaling Process Communication Dec 2001
avoid mis-sequencing of traffic. The mis-sequencing problem is
discussed in detail later in this draft. If ASP1 has become DOWN in
SGP2 due to some local failure in SGP2 or SCTP CDI then there are
chances of loss of data that has been sent from SGP2 to ASP1. If SCTP
supports then this data can be retrieved from SCTP.
To avoid above mentioned problems it is recommended that the
distribution mechanism should not re-distribute the traffic and SPs
should communicate with each other to avoid mis-sequencing and traffic
rejection or loss.
Consider the case where an AS consists of 3 ASPs and SG consists of
single SGP.
+---------------------+
| AS1 |
| +----------------+ |
| | | |
| | ASP1 +--+------|
| | | | |
| +----------------+ | |
| | | +--------------------+
| | | | SG1 |
| +----------------+ | -------| | |
| | | | | | ----------------+ |
| | ASP2 | | ---+--| | |
| | +--+----------------+--+ SGP1 | |
| +----------------+ | ---+--| | |
| | | | +---------------+ |
| | | | |
| +----------------+ | -------| | |
| | | | | | |
| | ASP3 | | | +--------------------+
| | +--+------|
| +----------------+ |
| |
+---------------------+
Kaul [Page 10]
Internet Draft Inter Signaling Process Communication Dec 2001
All the ASPs are active in the SGP and sending SS7 traffic to the SGP.
Now Association between ASP2 and SGP1 goes down, then the ASP User at
the ASP2 will not be able to send the data to the SG even though the
SS7 network is reachable via the SG. To avoid this problem ASPs can
coordinate with each other and hence provide uninterrupted service to
their users.
2.2 Traffic Forwarding between SPs
As explained in section 2.1 that if Inter SP communication is present
and any association is ACTIVE between an AS and a SG then continous
flow of SS7 traffic can be ensured. In case an SP is unable to send
messages to the peer SP, then traffic forwarding can be put in use to
provide uninterrupted flow of SS7 traffic between AS and SG.
This forwarding of traffic certainly requires SPs to share some
information between them. This information is discussed in detail in
the subsequent sections.
Gupta [Page 11]
Internet Draft Inter Signaling Process Communication Dec 2001
2.3 Mis-Sequencing Problem and its Solution
If an SP starts forwarding data through another SP as discussed in
section 2.2 then mis-sequencing can take place. To avoid this problem
coordination between SP(s) of the same logical entity and coordination
between the peer SPs serving same peer logical entity is required.
Consider the following figure with AS consisting of two ASPs and SG
consisting of two SGPs.
+-------------------+ +--------------------+
| SG1 | | AS1 |
| +---------------+ | | +----------------+ |
| | | | (a)| | | |
| | SGP1 |--------------| ASP1 | |
| | |-------| | | | |
| +---------------+ | | | +----------------+ |
| | | | |
| | | | |
| +---------------+ | | (b)| +----------------+ |
| | | | -------| | |
| | SGP2 |--------------| ASP2 | |
| | | | (c)| | | |
| +---------------+ | | +----------------+ |
| | | |
+-------------------+ +--------------------+
All the associations are active between the SG and AS. Now their is
some local failure in the SGP1 and associations from it to ASP1 and
ASP2 goes down. Before SGP1 starts forwarding data to SGP2 it is
necessary that all the data sent from SGP1 on its associations (a) and
(b) must reach the AS otherwise mis-sequencing of data can take place.
In short if any traffic from one association is moved to another
association then mis-sequencing can take place.
The solution to this problem is to attach sequence number with the
data messages. Following are the steps which will help preventing
mis-sequencing if SGP1 wishes to forward data through SGP2. While
Kaul [Page 12]
Internet Draft Inter Signaling Process Communication Dec 2001
this procedure takes place all the data arriving at SGP2 for
associations (a) and (b) should be buffered.
1) SGP1 will request SGP2 to retrieve the sequence number of the
last data message received by ASP1 and ASP2.
2) SGP2 sends request for sequence number of last data message from
SGP1 to ASP2.
3) ASP2 will collect the information from all the ASP(s) in the same
AS (AS1), in this case ASP1, about the sequence number of the last
data message received by them from SGP1.
4) These sequence numbers received from all the other ASP(s) are sent
to the SGP2 from ASP2.
5) SGP2 will then return these sequence numbers to SGP1.
6) Now based on these numbers SGP1 will decide whether or not all the
data sent from it to AS1 (ASP1 and ASP2) before AS1 became DOWN in
SGP1 has been received by the AS1.
The above solution can easily be generalised and should be used if
Data message forwarding is supported by the SPs. Same logic can be
applied for the ASPs which are part of the same AS.
2.4 Sequence Numbers
Sequence numbers should be attached to all the data messages. Each
SP will have its own sequence numbering. Sequence numbers should be
maintained by an SP on local and remote SP pair. Sequence numbers
for each AS should be maintained separately. For example SGP1 will
maintain a sequence number for SGP1 and ASP1 pair and SGP1 and ASP2
pair separately. This implies that while sequence numbers are assigned
to a data message, destination SP to which data message will be sent
is known.
2.5 Information sharing between SPs
There is a need for information sharing between the SPs as mentioned
before in this draft. The information which has to be shared between
the SGPs and ASPs is different. The information to be shared is
discussed in the following sub sections. There is also a need to
uniquely identify all the logical entities (ASs and SGs). This unique
id should be same in all the ASP(s) and SGP(s).
Gupta [Page 13]
Internet Draft Inter Signaling Process Communication Dec 2001
2.5.1 Information sharing between SGPs
Information that is required to be shared between the SGPs is state of
all the ASs configured in the SGPs. If an SGP receives data for an AS
which is not ACTIVE in it, then it can forward data via some other
coordinating SGP which has AS ACTIVE in it.
2.5.2 Information sharing between ASPs
Information that is required to be shared between the ASPs is state of
Point Codes which are reachable through the SG. If an ASP receives data
for a DPC which is reachable through some SG in which the ASP is not
ACTIVE, then it can forward data via some other coordinating ASP which
is ACTIVE in the SG.
3.0 Inter-SP Interface
The Primitives for Inter SP interface are:
RETR_LAST_SEQ_NO_FROM_PEER_REQ
A SP requests a coordinating SP to retrieve the sequence number of the
last data message received by the SP of the peer logical entity.
RETR_LAST_SEQ_NO_FROM_PEER_RSP
Response to RETR_LAST_SEQ_NO_FROM_PEER_REQ.
LAST_SEQ_NO_RECVD_FROM_PEER_REQ
A SP requests for the last sequence number received from a peer SP to
a coordinating SP.
LAST_SEQ_NO_RECVD_FROM_PEER_RSP
Response to LAST_SEQ_NO_RECVD_FROM_PEER_REQ.
AS_STATE_CHANGE_IND
Kaul [Page 14]
Internet Draft Inter Signaling Process Communication Dec 2001
An SGP informs all the coordinating SGPs about the AS state change in
it.
AS_STATE_REQ
An SGP requests for the AS state to a coordinating SGP.
AS_STATE_RSP
Response to AS_STATE_REQ.
DPC_STATE_CHANGE_IND
An ASP informs all the coordinating ASPs about the state change of a
DPC through an SG. If this DPC state change is due to
DUNA/DAVA/SCON/DRST etc., then state of the DPC is changed in the AS.
If the DPC state change is due to the ASP becoming INACTIVE/DOWN in the
SG then the state change is marked only for that particular ASP.
DPC_STATE_REQ
An ASP requests for the DPC state to a coordinating ASP.
DPC_STATE_RSP
Response to DPC_STATE_REQ.
DATA_FORWARD_REQ
An SP requests another coordinating SP to send traffic on its behalf
to the remote logical entity.
DATA_RETR_REQ
An SP requests a coordinating SP to return all its data messages.
4. Support from SIGTRAN UA Protocols
4.1 Parameters required in DATA Messages
Some parameters are required to be added in the DATA messages in
order to support inter SP communication. The parameters required
are described in the following sub sections. These parameters are
required to be present as TLV's in the DATA messages.
Gupta [Page 15]
Internet Draft Inter Signaling Process Communication Dec 2001
4.1.1 Sequence Number
Sequence number TLV is required to be attached to each of the DATA
message. A Sequence number should be maintained for each pair of
Logical Entities (SG and AS).
4.1.2 SP ID
The SP ID of the SP from which message has originated is also required
in the DATA messages. This ID should uniquely identify an SP. This TLV
will help the peer SP in maintaining the sequence number of the last
DATA message from the originating SP. If message forwarding takes place
between coordinating SPs then the SP ID of the SP which forwarded the
message to another coordinating SP should be present in the DATA
message.
For example if SGP1 is unable to send DATA to AS1 and SGP2 has AS1
ACTIVE, then messages forwarded from SGP1 to SGP2 will have ID of SGP1
in them.
4.2 Messages Required in SIGTRAN UA protocols
Messages are required to be exchanged between the SPs of peer logical
entities. These messages are used to exchange Sequence numbers which is
explained earlier in the draft. These messages are explained below
with parameters. These messages can be sent as normal SIGTRAN UA
messages.
LAST_SEQ_NO_REQ
This message is sent by a SP to a peer SP to retrieve the sequence
number of the last data message of a coordinating SP from the peer
logical entity.
Parameters required in this message are:
Local SP ID of the SP for which sequence number is requested
Routing Context of the AS (optional)
Kaul [Page 16]
Internet Draft Inter Signaling Process Communication Dec 2001
LAST_SEQ_NO_RSP
This message is sent in response to LAST_SEQ_NO_REQ. The parameters for
this message are:
SP ID of the SP for which sequence number was requested
Sequence Number with SP ID of the SP at the receiving end, this
parameter may be present multiple times.
5. Example of Inter SP Coordination
Consider an SG with two SGPs and AS with two ASPs as depicted below
in the figure. All the Associations are ACTIVE.
+---------------+ +---------------+
| SG1 | | AS1 |
| +-----------+ | | +-----------+ |
| | SGP1 |-+------------------+-| ASP1 | |
| | |-+---------- | | | |
| +-----------+ | | | +-----------+ |
| | | | |
| +-----------+ | | | +-----------+ |
| | SGP2 | | |--------+-| ASP2 | |
| | |-+------------------+-| | |
| +-----------+ | | +-----------+ |
| | | |
+---------------+ +---------------+
Now AS1 becomes DOWN in the SGP1. Now following sequence of events will
take place:
1) SGP1->SGP2: AS_STATE_REQ
2) SGP2->SGP1: AS_STATE_RSP, If AS state is ACTIVE, then,
3) SGP1->SGP2: RETR_LAST_SEQ_NO_FROM_PEER_REQ
4) SGP2->ASP2: LAST_SEQ_NO_REQ with SP ID of SGP1
5) ASP2->ASP1: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for SGP1
6) ASP1->ASP2: LAST_SEQ_NO_RECVD_FROM_PEER_RSP
7) ASP2->SGP2: LAST_SEQ_NO_RSP
8) SGP2->SGP1: RETR_LAST_SEQ_NO_FROM_PEER_RSP
9) SGP1->SGP2: DATA_FORWARD_REQ
10) SGP2->ASP2: DATA
Gupta [Page 17]
Internet Draft Inter Signaling Process Communication Dec 2001
Now AS1 (ASP1) again becomes ACTIVE in the SGP1. Following sequence of
events will take place:
1) SGP1->ASP1: LAST_SEQ_NO_REQ with SP ID of SGP1
2) ASP1->ASP2: LAST_SEQ_NO_RECVD_FROM_PEER_REQ
3) ASP2->ASP1: LAST_SEQ_NO_RECVD_FROM_PEER_RSP
4) ASP1->SGP1: LAST_SEQ_NO_RSP
5) SGP1->ASP1: DATA
Consider all the Associations are ACTIVE. Now due to some local failure
in the ASP1, SG1 becomes unreachable for ASP1. All the point codes are
now unreachable through ASP1. Now following sequence of events will
take place:
1) ASP1->ASP2: DPC_STATE_REQ
2) ASP2->ASP1: DPC_STATE_RSP, If DPC state is AVAILABLE, then,
3) ASP1->ASP2: RETR_LAST_SEQ_NO_FROM_PEER_REQ
4) ASP2->SGP2: LAST_SEQ_NO_REQ with SP ID of ASP1
5) SGP2->SGP1: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for ASP1
6) SGP1->SGP2: LAST_SEQ_NO_RECVD_FROM_PEER_RSP
7) SGP2->ASP2: LAST_SEQ_NO_RSP
8) ASP2->ASP1: RETR_LAST_SEQ_NO_FROM_PEER_RSP
9) ASP1->ASP2: DATA_FORWARD_REQ
10) ASP2->SGP2: DATA
Now SG1 again becomes available to ASP1, then the following sequence of
events will take place:
1) ASP1->SGP1: LAST_SEQ_NO_REQ with SP ID of ASP1
2) SGP1->SGP2: LAST_SEQ_NO_RECVD_FROM_PEER_REQ for ASP1
3) SGP2->SGP1: LAST_SEQ_NO_RECVD_FROM_PEER_RSP
4) SGP1->ASP1: LAST_SEQ_NO_RSP
5) ASP1->SGP1: DATA
Kaul [Page 18]
Internet Draft Inter Signaling Process Communication Dec 2001
6. Acknowledgements
The authors are grateful to:
Dipak Aggarwal for motivating the authors to write this draft
Sandeep Mahajan and Anshoo Sharma for providing valuable comments
and suggestions.
R.C.Monee and Harsh Bhondwe for providing all the required resources
and support.
7. References
[1] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong
[2] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al,
October 2000.
[3] RFC 2119, "Key words for use in RFCs to Indicate Requirement
Levels", S. Bradner, March 1997.
[4] <draft-ietf-sigtran-m2ua-10.txt>, "MTP2-User Adaptation Layer",
K. Morneault et al, Sept 2001
8. Author's Addresses
Vipin Gupta
vkgupta@hss.hns.com
Hughes Software Systems
Plot 31 Sector 18
Electronic City
Gurgaon Haryana
India 122015
Kamesh Kaul
kakaul@hss.hns.com
Hughes Software Systems
Plot 31 Sector 18
Electronic City
Gurgaon Haryana
India 122015
Gupta [Page 19]