RFC relevance of signaling

As per Relevance of the word signaling, we have this rfc below:

Network Working Group L.
Request for Comments: 2719 Nortel
Category: Informational I.
M.

H.
L.

H.

I.

M.

C.
Cisco
October 1999

Framework Architecture for Signaling

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document defines an architecture framework and
requirements for transport of signaling information over IP.
framework describes relationships between functional and
entities exchanging signaling information, such as Signaling
and Media Gateway Controllers. It identifies interfaces
signaling transport may be used and the functional and
requirements that apply from existing Switched Circuit Network (SCN
signaling protocols

Ong, et al. Informational [Page 1]

RFC 2719 Framework Architecture for Signaling Transport October 1999

Table of

1. Introduction..................................................2
1.1 Overview.....................................................2
1.2 Terminology..................................................3
1.3 Scope.......................................................5
2. Signaling Transport Architecture.............................5
2.1 Gateway Component Functions.................................5
2.2 SS7 Interworking for Connection Control.....................6
2.3 ISDN Interworking for Connection Control....................8
2.4 Architecture for Database Access............................9
3. Protocol Architecture........................................10
3.1 Signaling Transport Components..............................10
3.2 SS7 access for Media Gateway Control........................11
3.3 Q.931 Access to MGC.........................................12
3.4 SS7 Access to IP/SCP........................................12
3.5 SG to SG....................................................14
4. Functional Requirements......................................15
4.1 Transport of SCN Signaling Protocols........................15
4.2 Performance of SCN Signaling Protocols......................17
4.2.1 SS7 MTP Requirements......................................17
4.2.2 SS7 MTP Level 3 Requirements..............................17
4.2.3 SS7 User Part Requirements................................18
4.2.4 ISDN Signaling Requirements...............................18
5. Management...................................................19
6. Security Considerations......................................19
6.1 Security Requirements.......................................19
6.2 Security Mechanisms Currently Available in IP Networks......20
7. Abbreviations................................................21
8. Acknowledgements.............................................21
9. References...................................................21
Authors' Addresses..............................................22
Full Copyright Statement........................................24

1.

1.1

This document defines an architecture framework for transport
message-based signaling protocols over IP networks. The scope
this work includes definition of encapsulation methods, end-to-
protocol mechanisms and use of existing IP capabilities to
the functional and performance requirements for signaling transport

The framework portion describes the relationships between
and physical entities used in signaling transport, including
framework for control of Media Gateways, and other scenarios
signaling transport may be required

Ong, et al. Informational [Page 2]

RFC 2719 Framework Architecture for Signaling Transport October 1999

The requirements portion describes functional and
requirements for signaling transport such as flow control, in
sequence delivery and other functions that may be required
specific SCN signaling protocols

1.2

The following are general terms are used in this document

Backhaul

Backhaul refers to the transport of signaling from the point
interface for the associated data stream (i.e., SG function in
MGU) back to the point of call processing (i.e., the MGCU), if
is not local

Signaling Transport (SIG):

SIG refers to a protocol stack for transport of SCN
protocols over an IP network. It will support standard primitives
interface with an unmodified SCN signaling application
transported, and supplements a standard IP transport
underneath with functions designed to meet transport requirements
SCN signaling

Switched Circuit Network (SCN):

The term SCN is used to refer to a network that carries
within channelized bearers of pre-defined sizes. Examples
Public Switched Telephone Networks (PSTNs) and Public Land
Networks (PLMNs). Examples of signaling protocols used in
include Q.931, SS7 MTP Level 3 and SS7 Application/User parts

The following are terms for functional entities relating to
transport in a distributed gateway model

Media Gateway (MG):

A MG terminates SCN media streams, packetizes the media data,, if
is not already packetized, and delivers packetized traffic to
packet network. It performs these functions in reverse order
media streams flowing from the packet network to the SCN

Ong, et al. Informational [Page 3]

RFC 2719 Framework Architecture for Signaling Transport October 1999

Media Gateway Controller (MGC):

An MGC handles the registration and management of resources at
MG. The MGC may have the ability to authorize resource usage based
local policy. For signaling transport purposes, the MGC serves as
possible termination and origination point for SCN
protocols, such as SS7 ISDN User Part and Q.931/DSS1.

Signaling Gateway (SG):

An SG is a signaling agent that receives/sends SCN native
at the edge of the IP network. The SG function may relay,
or terminate SS7 signaling in an SS7-Internet Gateway. The
function may also be co-resident with the MG function to process
signaling associated with line or trunk terminations controlled
the MG (e.g., signaling backhaul).

The following are terms for physical entities relating to
transport in a distributed gateway model

Media Gateway Unit (MGU

An MG-Unit is a physical entity that contains the MG function.
may contain other functions, esp. an SG function for
facility-associated signaling

Media Gateway Control Unit (MGCU

An MGC-Unit is a physical entity containing the MGC function

Signaling Gateway Unit (SGU

An SG-Unit is a physical entity containing the SG function

Signaling End Point (SEP):

This is a node in an SS7 network that originates or
signaling messages. One example is a central office switch

Signal Transfer Point (STP):

This is a node in an SS7 network that routes signaling messages
on their destination point code in the SS7 network

Ong, et al. Informational [Page 4]

RFC 2719 Framework Architecture for Signaling Transport October 1999

1.3

Signaling transport provides transparent transport of message-
signaling protocols over IP networks. The scope of this
includes definition of encapsulation methods, end-to-end
mechanisms and use of IP capabilities to support the functional
performance requirements for signaling

Signaling transport shall be used for transporting SCN
between a Signaling Gateway Unit and Media Gateway Controller Unit
Signaling transport may also be used for transport of message-
signaling between a Media Gateway Unit and Media Gateway
Unit, between dispersed Media Gateway Controller Units, and
two Signaling Gateway Units connecting signaling endpoints or
transfer points in the SCN

Signaling transport will be defined in such a way as to
encapsulation and carriage of a variety of SCN protocols. It
defined in such a way as to be independent of any SCN
translation functions taking place at the endpoints of the
transport, since its function is limited to the transport of the
protocol

Since the function being provided is transparent transport,
following areas are considered outside the scope of the
transport work

- definition of the SCN protocols themselves
- signaling interworking such as conversion from Channel
Signaling (CAS) to message signaling protocols
- specification of the functions taking place within the SGU or
- in particular, this work does not address whether the SGU
mediation/interworking, as this is transparent to the
function
- similarly, some management and addressing functions taking
within the SGU or MGU are also considered out of scope, such
determination of the destination IP address for signaling,
specific procedures for assessing the performance of the
session (i.e., testing and proving functions).

2. Signaling Transport

2.1 Gateway Component

Figure 1 defines a commonly defined functional model that
out the functions of SG, MGC and MG. This model may be
in a number of ways, with functions implemented in separate
or combined in single physical units

Ong, et al. Informational [Page 5]

RFC 2719 Framework Architecture for Signaling Transport October 1999

Where physical separation exists between functional entities
Signaling Transport can be applied to ensure that SCN
information is transported between entities with the
functionality and performance

+---------------+ +--------------+
| | | |
SCN<-------->[SG] <--+---------O------------+--> [SG] <------>
signal | | | | | |
+-------|-------+ +-----|--------+
Signaling|gateway Signaling|gateway (opt
O
| |
+-------|-------+ +-----|--------+
| | | | | |
| [MGC] <--+--------O-------------+--> [MGC] |
| | | | | |
| | | | | |
+-------|-------+ +-----|--------+
Gateway | controller Gateway | controller (opt
O
| |
+-------|-------+ +-----|--------+
Media | | | | | |
<------+---->[MG] <---+-----RTP stream-------+-> [MG] <----+-------->
stream| | | |
+---------------+ +--------------+
Media gateway Media

Figure 1: Sigtran Functional

As discussed above, the interfaces pertaining to signaling
include SG to MGC, SG to SG. Signaling transport may potentially
applied to the MGC to MGC or MG to MGC interfaces as well,
on requirements for transport of the associated signaling protocol

2.2 SS7 Interworking for Connection

Figure 2 below shows some example implementations of these
in physical entities as used for interworking of SS7 and IP
for Voice over IP, Voice over ATM, Network Access Servers, etc.
recommendation is made as to functional distribution and many
examples are possible but are not shown to be concise. The use
signaling transport is independent of the implementation

Ong, et al. Informational [Page 6]

RFC 2719 Framework Architecture for Signaling Transport October 1999

For interworking with SS7-controlled SCN networks, the SG
the SS7 link and transfers the signaling information to the MGC
signaling transport. The MG terminates the interswitch trunk
controls the trunk based on the control signaling it receives
the MGC. As shown below in case (a), the SG, MGC and MG may
implemented in separate physical units, or as in case (b), the
and MG may be implemented in a single physical unit

In alternative case (c), a facility-associated SS7 link is
by the same device (i.e., the MGU) that terminates the
trunk. In this case, the SG function is co-located with the
function, as shown below, and signaling transport is used
"backhaul" control signaling to the MGCU

Note: SS7 links may also be terminated directly on the MGCU
cross-connecting at the physical level before or at the MGU

+--------+
SS7<------>[SG] |
(ISUP) | | |
+---|----+
ST | SGU
+---|----+ +--------+ +--------+
| [MGC] | SS7---->[SG] | | [MGC] |
| | | | | | | | | |
+---|----+ +---|----+ +--|-|---+
MGCU | ST | | |
| | ST | |
Media +---|----+ Media +---|----+ +--|-|---+
------->[MG] | ----->[MG/MGC]| SS7 link-->[SG]| |
stream | | stream | | Media------> [MG] |
+--------+ +--------+ stream +--------+
MGU MGU

(a) (b) (c

Notes: ST = Signaling Transport used to carry SCN

Figure 2: Example

Ong, et al. Informational [Page 7]

RFC 2719 Framework Architecture for Signaling Transport October 1999

In some implementations, the function of the SG may be divided
multiple physical entities to support scaling, signaling
management and addressing concerns. Thus, Signaling Transport can
used between SGs as well as from SG to MGC. This is shown in Figure 3
below

SGU
+---------+ +---------+
| | ST | |
| [SG2]------------------------------>[MGC] |
| ^ ^ | | |
+---|-|---+ +---------+
| |
| |
ST| +--------------------------------+
| |
| |
SS7 +---|----------+ SS7 +----|---------+
-----------> [SG1] | -----------> [SG1] |
media | | media | |
------------------->[MG] | ------------------->[MG] |
stream +--------------+ stream +--------------+
MGU

Figure 3: Multiple SG

In this configuration, there may be more than one MGU
facility associated signaling (i.e. more than one containing it's
SG function), and only a single SGU. It will therefore be possible
transport one SS7 layer between SG1 and SG2, and another SS7
between SG2 and MGC. For example, SG1 could transport MTP3 to SG2,
and SG2 could transport ISUP to MGC

2.3 ISDN Interworking for Connection

In ISDN access signaling, the signaling channel is carried along
data channels, so that the SG function for handling Q.931
is co-located with the MG function for handling the data stream
Where Q.931 is then transported to the MGC for call processing
signaling transport would be used between the SG function and MGC
This is shown in Figure 3 below

Ong, et al. Informational [Page 8]

RFC 2719 Framework Architecture for Signaling Transport October 1999

+-------------+
| [MGC] |
| | | |
+-----|-|-----+
| |
| O device
| |
Q.931/ST O |
| |
+-----|-|-----+
| | | |
Q.931---->[SG]| |
signals| | |
| | |
Media---->[MG] |
stream | |
+-------------+

Figure 4: Q.931 transport

2.4 Architecture for Database

Transaction Capabilities (TCAP) is the application part within SS
that is used for non-circuit-related signaling

TCAP signaling within IP networks may be used for cross-
between entities in the SS7 domain and the IP domain, such as,
example

- access from an SS7 network to a Service Control Point (SCP) in IP
- access from an SS7 network to an MGC
- access from an MGC to an SS7 network element
- access from an IP SCP to an SS7 network element

A basic functional model for TCAP over IP is shown in Figure 5.

Ong, et al. Informational [Page 9]

RFC 2719 Framework Architecture for Signaling Transport October 1999

+--------------+
| IP SCP |
+--|----|------+
| |
SGU | |
+--------------+ | | +--------------+
| | | | | |
SS7<--------->[SG] ---------+ | | [SG]<---------> SS
(TCAP) | | | | | | |
+------|-------+ | +------|-------+
| | |
O +------------+
MGCU | | |
+-------|----|--+ +-----|--------+
| | | | | | |
| [MGC] | | [MGC] |
| | | | | |
+-------|-------+ +-----|--------+
| |
+-------|-------+ +-----|------+
Media | | | | | |
<------+---->[MG] <---+--RTP stream---+--> [MG] <-+-------->
stream| | | |
+---------------+ +------------+
MGU

Figure 5: TCAP Signaling over

3. Protocol

This section provides a series of examples of protocol
for the use of Signaling Transport (SIG).

3.1 Signaling Transport

Signaling Transport in the protocol architecture figures below
assumed to consist of three components (see Figure 6):

1) an adaptation sub-layer that supports specific primitives, e.g.,
management indications, required by a particular SCN
application protocol
2) a Common Signaling Transport Protocol that supports a common
of reliable transport functions for signaling transport
3) a standard, unmodified IP transport protocol

Ong, et al. Informational [Page 10]

RFC 2719 Framework Architecture for Signaling Transport October 1999

+-- +--------------------------------+
| | SCN adaptation module |
| +--------------------------------+
| |
S | +--------------------------------+
I | | Common Signaling Transport |
G | +--------------------------------+
| |
| +--------------------------------+
| | standard IP transport |
+-- +--------------------------------+

Figure 6: Signaling Transport

3.2. SS7 access for Media Gateway

This section provides a protocol architecture for signaling
supporting SS7 access for Media Gateway Control

****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *------------* MGC *
****** ******* ****** *******

+----+ +-----+
|ISUP| | ISUP
+----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP | SIG| | SIG |
|L1-3| |L1-3 | |L1-3+----+ +-----+
| | | | | | IP | | IP |
+----+ +-----+ +---------+ +-----+

STP - Signal Transfer Point SEP - Signaling End
SG - Signaling Gateway SIG - Signaling
MGC - Media Gateway

Figure 7: SS7 Access to

Ong, et al. Informational [Page 11]

RFC 2719 Framework Architecture for Signaling Transport October 1999

3.3. Q.931 Access to

This section provides a protocol architecture for signaling
supporting ISDN point-to-point access (Q.931) for Media
Control

****** ISDN ********* IP *******
* EP *--------------* SG/MG *------------* MGC *
****** ********* *******

+----+ +-----+
|Q931| | Q931|
+----+ +---------+ +-----+
|Q921| |Q921| SIG| | SIG |
+ + + +----+ +-----+
| | | | IP | | IP |
+----+ +---------+ +-----+

MG/SG - Media Gateway with SG function for
EP - ISDN End

Figure 8: ISDN

3.4. SS7 Access to IP/

This section provides a protocol architecture for database access
for example providing signaling between two IN nodes or two
network nodes. There are a number of scenarios for the
stacks and the functionality contained in the SIG, depending on
SS7 application

In the diagrams, SS7 Application Part (S7AP) is used for
to cover all Application Parts (e.g. MAP, IS-41, INAP, etc).
Depending on the protocol being transported, S7AP may or may
include TCAP. The interface to the SS7 layer below S7AP can be
the TC-user interface or the SCCP-user interface

Figure 9a shows the scenario where SCCP is the signaling
being transported between the SG and an IP Signaling Endpoint (ISEP),
that is, an IP destination supporting some SS7 application protocols

Ong, et al. Informational [Page 12]

RFC 2719 Framework Architecture for Signaling Transport October 1999

****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP
****** ******* ****** *******

+-----+ +-----+
|S7AP | |S7AP |
+-----+ +-----+
|SCCP | |SCCP |
+-----+ +-----+ +---------+ +-----+
|MTP | |MTP | |MTP |SIG | |SIG |
+ + + + + +----+ +-----+
| | | | | | IP | |IP |
+-----+ +-----+ +---------+ +-----+

Figure 9a: SS7 Access to IP node - SCCP being

Figure 9b shows the scenario where S7AP is the signaling
being transported between SG and ISEP. Depending on the
being transported, S7AP may or may not include TCAP, which
that SIG must be able to support both the TC-user and the SCCP-
interfaces

****** SS7 ******* SS7 ****** IP *******
*SEP *--------* STP *------* SG *-------------* ISEP
****** ******* ****** *******

+-----+ +-----+
|S7AP | |S7AP |
+-----+ +----+----+ +-----+
|SCCP | |SCCP| | | |
+-----+ +-----+ +----|SIG | |SIG |
|MTP | |MTP | |MTP | | | |
+ + + + + +----+ +-----+
| | | | | |IP | |IP |
+-----+ +-----+ +---------+ +-----+

Figure 9b: SS7 Access to IP node - S7AP being

Ong, et al. Informational [Page 13]

RFC 2719 Framework Architecture for Signaling Transport October 1999

3.5. SG to

This section identifies a protocol architecture for support
signaling between two endpoints in an SCN signaling network,
signaling transport directly between two SGs

The following figure describes protocol architecture for a
with two SGs providing different levels of function for
of SS7 and IP. This corresponds to the scenario given in Figure 3.

The SS7 User Part (S7UP) shown is an SS7 protocol using MTP
for transport within the SS7 network, for example, ISUP

In this scenario, there are two different usage cases of SIG,
which transports MTP3 signaling, the other which transports
signaling

****** SS7 ****** IP ****** IP ******
*SEP *-------* SG1*----------* SG2*-------*MGC *
****** ****** ****** ******

+----+ +----+
|S7UP| |S7UP
+----+ +----+----+ +----+
|MTP3| |MTP3| | | |
+----+ +---------+ +----+ SIG| |SIG |
|MTP2| |MTP2|SIG | |SIG | | | |
+ + + +----+ +----+----+ +----+
| | | | IP | | IP | | IP |
+----+ +----+----+ +----+----+ +----+

S7UP - SS7 User

Figure 10: SG to SG Case 1

The following figure describes a more generic use of SS7-
interworking for transport of SS7 upper layer signaling across an
network, where the endpoints are both SS7 SEPs

Ong, et al. Informational [Page 14]

RFC 2719 Framework Architecture for Signaling Transport October 1999

****** SS7 ****** IP ****** SS7 ******
*SEP *--------* SG *-----------* SG *--------*SEP *
****** ****** ****** ******

+----+ +-----+
|S7UP| | S7UP
+----+ +-----+
|MTP3| | MTP3|
+----+ +---------+ +---------+ +-----+
|MTP2| |MTP2| SIG| |SIG |MTP2| | MTP2|
+ + + +----+ +----+ + + +
| | | | IP | | IP | | | |
+----+ +----+----+ +----+----+ +-----+

Figure 11: SG to SG Case 2

4. Functional

4.1 Transport of SCN Signaling

Signaling transport provides for the transport of native SCN
messages over a packet switched network

Signaling transport shall

1) Transport of a variety of SCN protocol types, such as
application and user parts of SS7 (including MTP Level 3, ISUP, SCCP
TCAP, MAP, INAP, IS-41, etc.) and layer 3 of the DSS1/PSS1
(i.e. Q.931 and QSIG).

2) Provide a means to identify the particular SCN protocol
transported

3) Provide a common base protocol defining header formats,
extensions and procedures for signaling transport, and
extensions as necessary to add individual SCN protocols if and
required

4) In conjunction with the underlying network protocol (IP),
the relevant functionality as defined by the appropriate SCN
layer

Relevant functionality may include (according to the protocol
transported):

- flow
- in sequence delivery of signaling messages within a control

Ong, et al. Informational [Page 15]

RFC 2719 Framework Architecture for Signaling Transport October 1999

- logical identification of the entities on which the
messages originate or
- logical identification of the physical interface controlled by
signaling
- error
- recovery from failure of components in the transit
- retransmission and other error correcting
- detection of unavailability of peer entities

For example

- if the native SCN protocol is ISUP or SCCP, the
functionality provided by MTP2/3 shall be provided
- if the native SCN protocol is TCAP, the relevant
provided by SCCP connectionless classes and MTP 2/3 shall
supported
- if the native SCN protocol is Q.931, the relevant
provided by Q.921 shall be supported
- if the native SCN protocol is MTP3, the relevant functionality
MTP2 shall be supported

5) Support the ability to multiplex several higher layer SCN
on one underlying signaling transport session. This allows,
example, several DSS1 D-Channel sessions to be carried in
signaling transport session

In general, in-sequence delivery is required for signaling
within a single control stream, but is not necessarily required
messages that belong to different control streams. The
should if possible take advantage of this property to avoid
delivery of messages in one control stream due to sequence
within another control stream. The protocol should also allow the
to send different control streams to different destination ports
desired

6) Be able to transport complete messages of greater length than
underlying SCN segmentation/reassembly limitations. For example
signaling transport should not be constrained by the
limitations defined for SS7 lower layer protocol (e.g. 272 bytes
the case of narrowband SS7) but should be capable of carrying
messages without requiring segmentation

7) Allow for a range of suitably robust security schemes to
signaling information being carried across networks. For example
signaling transport shall be able to operate over proxyable sessions
and be able to be transported through firewalls

Ong, et al. Informational [Page 16]

RFC 2719 Framework Architecture for Signaling Transport October 1999

8) Provide for congestion avoidance on the Internet, by
appropriate controls on signaling traffic generation (
signaling generated in SCN) and reaction to network congestion

4.2 Performance of SCN Signaling

This section provides basic values regarding performance
of key SCN protocols to be transported. Currently only message-
SCN protocols are considered. Failure to meet these requirements
likely to result in adverse and undesirable signaling and
behavior

4.2.1 SS7 MTP

The performance requirements below have been specified for
of MTP Level 3 network management messages. The requirements
here are only applicable if all MTP Level 3 messages are to
transported over the IP network

- Message
- MTP Level 3 peer-to-peer procedures require response within 500
to 1200 ms. This value includes round trip time and
at the remote end
Failure to meet this limitation will result in the
of error procedures for specific timers, e.g., timer T4
ITU-T Recommendation Q.704.

4.2.2 SS7 MTP Level 3

The performance requirements below have been specified for
of MTP Level 3 user part messages as part of ITU-T SS
Recommendations [SS7].

- Message
- no more than 1 in 10E+7 messages will be lost due to

- Sequence
- no more than 1 in 10E+10 messages will be delivered out-of
sequence (including duplicated messages) due to

- Message
- no more than 1 in 10E+10 messages will contain an error that
undetected by the transport protocol (requirement is 10E+9
ANSI specifications

Ong, et al. Informational [Page 17]

RFC 2719 Framework Architecture for Signaling Transport October 1999

-
- availability of any signaling route set is 99.9998% or better
i.e., downtime 10 min/year or less. A signaling route set
the complete set of allowed signaling paths from a
signaling point towards a specific destination

- Message length (payload accepted from SS7 user parts
- 272 bytes for narrowband SS7, 4091 bytes for broadband SS

4.2.3 SS7 User Part

More detailed analysis of SS7 User Part Requirements can be found
[Lin].

ISUP Message Delay - Protocol Timer

- one example of ISUP timer requirements is the Continuity
procedure, which requires that a tone generated at the
end be returned from the receiving end within 2 seconds
sending an IAM indicating continuity test. This implies
one way signaling message transport, plus accompanying
functions need to be accomplished within 2 seconds

ISUP Message Delay - End-to-End

- the requirement for end-to-end call setup delay in ISUP is
an end-to-end response message be received within 20-30
of the sending of the IAM. Note: while this is the
guard timer value, users will generally expect faster
time

TCAP Requirements - Delay

- TCAP does not itself define a set of delay requirements.
work has been done [Lin2] to identify application-based
requirements for TCAP applications

4.2.4 ISDN Signaling

Q.931 Message

- round-trip delay should not exceed 4 seconds. A Timer of
length is used for a number of procedures, esp. RELASE/
COMPLETE and CONNECT/CONNECT ACK where excessive delay
result in management action on the channel, or release of
call being set up. Note: while this value is indicated
protocol timer specifications, faster response time is
expected by the user

Ong, et al. Informational [Page 18]

RFC 2719 Framework Architecture for Signaling Transport October 1999

- 12 sec. timer (T309) is used to maintain an active call
case of loss of the data link, pending re-establishment.
related ETSI documents specify a maximum value of 4
while ANSI specifications [T1.607] default to 90 seconds

5.

Operations, Administration & Management (OA&M) of IP networks or
networks is outside the scope of SIGTRAN. Examples of OA&M
legacy telephony management systems or IETF SNMP managers. OA&
implementors and users should be aware of the functional
of the SG, MGC and MG and the physical units they occupy

6. Security

6.1 Security

When SCN related signaling is transported over an IP network
possible network scenarios can be distinguished

- Signaling transported only within an Intranet
Security measures are applied at the discretion of the
owner

- Signaling transported, at least to some extent, in the
Internet
The public Internet should be regarded generally as an "insecure
network and usage of security measures is required

Generally security comprises several

- Authentication
It is required to ensure that the information is sent to/from
known and trusted partner

- Integrity
It is required to ensure that the information hasn't been
while in transit

- Confidentiality
It might be sometimes required to ensure that the
information is encrypted to avoid illegal use

- Availability
It is required that the communicating endpoints remain in
for authorized use even if under attack

Ong, et al. Informational [Page 19]

RFC 2719 Framework Architecture for Signaling Transport October 1999

6.2 Security Mechanisms Currently Available in IP

Several security mechanisms are currently available for use in
networks

- IPSEC ([RFC2401]):
IPSEC provides security services at the IP layer that address
above mentioned requirements. It defines the two protocols AH
ESP respectively that essentially provide data integrity and
confidentiality services

The ESP mechanism can be used in two different modes
- Transport mode
- Tunnel mode

In Transport mode IPSEC protects the higher layer protocol
portion of an IP packet, while in Tunnel mode a complete IP packet
encapsulated in a secure IP tunnel

If the SIG embeds any IP addresses outside of the SA/DA in the
header, passage through a NAT function will cause problems. The
is true for using IPsec in general, unless an IPsec ready
function is used as described in RFC 2663 [NAT].

The use of IPSEC does not hamper the use of TCP or UDP as
underlying basis of SIG. If automated distribution of keys
required the IKE protocol ([RFC2409]) can be applied

- SSL, TLS ([RFC2246]):
SSL and TLS also provide appropriate security services but
on top of TCP/IP only

It is not required to define new security mechanisms in SIG, as
use of currently available mechanisms is sufficient to provide
necessary security. It is recommended that IPSEC or some
method be used, especially when transporting SCN signaling
public Internet

Ong, et al. Informational [Page 20]

RFC 2719 Framework Architecture for Signaling Transport October 1999

7.

CAS Channel-Associated
DSS1 Digital Subscriber
INAP Intelligent Network Application
ISEP IP Signaling End
ISUP Signaling System 7 ISDN User
MAP Mobile Application
MG Media
MGU Media Gateway
MGC Media Gateway
MGCU Media Gateway Controller
MTP Signaling System 7 Message Transfer
PLMN Public Land Mobile
PSTN Public Switched Telephone
S7AP SS7 Application
S7UP SS7 User
SCCP SS7 Signaling Connection Control
SCN Switched Circuit
SEP Signaling End
SG Signaling
SIG Signaling Transport protocol
SS7 Signaling System No. 7
TCAP Signaling System 7 Transaction Capabilities

8.

The authors would like to thank K. Chong, I. Elliott, Ian Spiers,
Varney, Goutam Shaw, C. Huitema, Mike McGrew and Greg Sidebottom
their valuable comments and suggestions

9.

[NAT] Srisuresh P. and M. Holdrege, "IP Network
Translator (NAT) Terminology and Considerations",
2663, August 1999.

[PSS1/QSIG] ISO/IEC 11572 Ed. 2 (1997-06), "Information
- Telecommunications and information exchange
systems - Private Integrated Services Network -
mode bearer services - Inter-exchange
procedures and protocol

[Q.931/DSS1] ITU-T Recommendation Q.931, ISDN user-network
layer 3 specification (5/98)

[SS7] ITU-T Recommendations Q.700-775, Signalling System No. 7

Ong, et al. Informational [Page 21]

RFC 2719 Framework Architecture for Signaling Transport October 1999

[SS7 MTP] ITU-T Recommendations Q.701-6, Message Transfer Part
SS

[T1.607] ANSI T1.607-1998, Digital Subscriber Signaling
Number 1 (DSS1) - Layer 3 Signaling Specification
Circuit-Switched Bearer

[Lin] Lin, H., Seth, T., et al., "Performance Requirements
Signaling in Internet Telephony", Work in Progress

[Lin2] Lin, H., et al., "Performance Requirements for
Signaling in Internet Telephony", Work in Progress

[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.

[RFC2409] Harkins, D. and C. Carrel, "The Internet Key
(IKE)", RFC 2409, November 1998.

[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
Internet Protocol", RFC 2401, November 1998.

Authors'

Lyndon
Nortel
4401 Great America
Santa Clara, CA 95054,

EMail: long@nortelnetworks.

Ian
Ericsson
37/360 Elizabeth
Melbourne, Victoria 3000,

EMail: ian.rytina@ericsson.

Matt
Lucent
1701 Harbor Bay
Alameda, CA 94502

EMail: holdrege@lucent.

Ong, et al. Informational [Page 22]

RFC 2719 Framework Architecture for Signaling Transport October 1999

Lode
Siemens
Atealaan 34
Herentals,

EMail: lode.coene@siemens.atea.

Miguel-Angel
Ericsson
Retama 7
28005 Madrid,

EMail: Miguel.A.Garcia@ericsson.

Chip
Cisco
7025 Kit Creek
Res Triangle Pk, NC 27709,

EMail: chsharp@cisco.

Imre

EMail: imre.i.juhasz@telia.

Haui-an Paul
Telcordia
Piscataway, NJ,

EMail: hlin@research.telcordia.

HannsJuergen
SIEMENS
Hofmannstr. 51
81359 Munich,

EMail: HannsJuergen.Schwarzbauer@icn.siemens.

Ong, et al. Informational [Page 23]

RFC 2719 Framework Architecture for Signaling Transport October 1999

Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Funding for the RFC Editor function is currently provided by
Internet Society

Ong, et al. Informational [Page 24]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX