Internet DRAFT - draft-coene-ss7-over-ip
draft-coene-ss7-over-ip
INTERNET DRAFT Lode Coene
Category: Memo Siemens Atea
Title: <draft-coene-ss7-over-ip-00.txt>
Date: November 1999
Expires: May 2000
SS7 over internet applicability statement
<draft-coene-ss7-over-ip-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document describes the applicability of the different SS7
user adapatation layers over SCTP for transport of SS7 signalling
information over IP infrastructure. The functions of SS7 network
layer relating to addressing and their relations with the
corresponding IP functions are explained.
Table of Contents
1.0 Introduction
2.0 Terminology
3.0 SS7 over IP infrastructure
3 1 Internet addressing
3.1.1 IP addresses
3.1.2 How to reach applications in the Internet
3.2 SS7 addressing
3.2.1 MTP addressing
3.2.2 SCCP addressing
3.2.3 Global Title
3.2.4 How to reach applications in SS7
3.3 Possible architectures of SS7-over-IP
3.4 SS7 Signalling transport using SCTP
3.4.1 MTP lvl 2 user adaptation layer(M2UA)
3.4.2 MTP lvl 3 User adaptation layer(ITUN)
3.4.3 Multihoming within SCTP
3.5 Congestion control & avoidance
3.6 Use of QOS methods for signalling transport
3.6.0 Overprovisioning
3.6.1 Differentiated services
3.6.2 Integrated services
3.6 Routing of SS7 messages in a IP net
3.6.1 Routing using globally assigned IP addresses.
3.6.2 Routing SS7 messages and Network Address Translators
3.6.3 Routing SS7 and IPv6 prefix optimisation
3.6.4 Routing SS7 and dynamical assigned IP addresses
3.6.5 Automatic configuration of SS7 nodes
3.7 Security issues
7.0 References
8.0 Authors
1.0 Introduction
This architecture document covers subject terminology and makes a
overview of the solutions for transporting SS7 signalling
information over Internet Protocol infrastructure. This includes
also a overview of the available Internet and SS7 addressing. It
tries to explain what the meaning is of the different addressing
modes in the internet and Signaling System Nr. 7 and where their
added value resides. Some scenario's are provided as example of
how applications in the SS7 and/or internet may be able to reach
each other.
2.0 Terminology
The following functions are commonly identified in related work :
Signal Transfer Point (STP):
This is a node in an SS7 network that routes signalling messages based on their
destination address in the SS7 network
Signal Relay Point (SRP):
This is a node in an SS7 network that routes signalling messages based on their
called party address in the SS7 network.(Translates Called party address to a
destination pointcode and also translates Calling prty address when needed)
Signalling Common Transport Protocol(SCTP):
A transport protocol designed for the reliable transport of
signalling information over a connectionless network( example: the
Internet)
Called Party Address(CLD):
Address of the party the message wants to reach.(Party can be a
node, person, network..., a entity in general)(=Destination
address)
Calling Party Address(CLG):
Address of the party from which the message originated.(Originating address)
Global Title:(GT)
A globally unique identifier used in the CLD and/or CLG for identifying a
entity. A global title can consist of a pointcode, translation type, nature of
address, numbering plan and the title itself(=digits).
Pointcode(PC)
The Pointcode in SS7 and IP have the same meaning, but not necessary the same
size and interpretation. A pointcode identifies a node within a particular
network.
Routing Indicator:
The routing indicator tells the SCCP routing function which part of the address has
to use for routing the message(SSN + global title or SSN + pointcode).
Translation Type Number(TTN):
The translation type number indicates the translation type of the address.
Numbering Plan(NP):
This indicates the numbering plan to which the digits belong: that can be E164,
E212, private numbering plans, Internet Numbering Plan, .....
Nature-Of-address(NA):
The nature of address indicates whether a address is for national, international
or other use.
Encoding Scheme(ES):
The encoding scheme indicates how the digits are encoded. Encoding is normally
in Binary Coded decimal(BCD) format.
SubSystem Number(SSN)
The SSN indicates the application entity that must be reached in the final
destination node of the msg
Global Titel Format(GTI):
Indicates which of the above mentioned parameters are actually present in the
party address. If some parameters are not present in the address then default
parameters are used for executing the Global Title Translation.
Portnumber:
Indicates on the tranport level in IP which application needs to be reached in
the layer above.
Subsystem number(SSN):
Indicates on the networklayer in SS7 which application needs to be reached in
the application layer.
Subnet: a subnet is a collections of nodes, belonging to the same operator/ISP
or collective of operators/ISP's. This may be equivalent with a Internet domain.
A MTP net is always a subnet. Subnet may be owned by more than one
operator(example MTP NAT0 subnet in the US)
3.0 SS7 over IP infrastructure
3.1 Internet addressing
Every layer needs to determine the service to which it wants to deliver its
information. The way in which this is done depends from layer to layer. The
transport protocols above the IP network protocol are indicated in the protocol
extension headers field contained at the end of the IP header. Every protocol
has its own standardized protocol number.
The transport layer determines the application to which it wants
to deliver the information by the portnumber.
The tuple destination address and portnumber uniqely identifies a application in
the internet. Further selectors may be used in higher layers to
obtain the desired application. The IP address itself is a
pointcode. The following types of pointcode may de distinguished :
- Unicast address: a unicast address designates a single node within a IP
network. It can have some hierarchy in it or not. The address may be globally
unique or be a private pointcode.
- Multicast address: the message is send to all nodes
belonging/attached to that multicast address/group.( Similar
principle as with SCCP broadcast but different implementation)
- Link-local address: these are addresses assigned to the link(wow local
"private").
- Site-local address: these are addresses assigned to a site(wow local,
"private")
- ...
As the meaning of the pointcodes is only known to IP and it has a relation to
the link and its interface to the link, layers which only know about
destinations(such as SCCP), SHOULD NOT/MUST NOT try to to interprete the IP
address.
The IP pointcode does not strictly identify the node in the network but rather
the interface to the IP network layer. Thus IP nodes can have more
than 1 Pointcode(and those PC can be used for having 2 links
between 2 adjacend nodes, a feature that is called multihoming ).
3.2 SS7 addressing
3.2.1 MTP addres :
SS7 was develop in stages: ISUP and MTP were first developped. The decision to
route was done by the application in a similar way as the MFC/... signalling
determined the trunk to the next exchange. ISUP had to determine for a certain
E164 number a DPC(= the pointcode of the adjacend exchange) and then the msg was
routed to the office where the same procedure was done over all again.(=link-by-
link routing)
MTP routing label consists of a Network indicator(also called A MTP-SAP=service
acces point) , a destination Pointcode(=DPC) and a origination Pointcode(OPC).
The MTP-SAP indicates for which network the pointcode in the routing label is
valid. If the routing table has been engineerd in a node for that network, the
message can reach that destination. The size of a pointcode is fixed within a
single network. Different networks can have different sizes of pointcodes:
- ITU 14 bit
- China 24 bit
- ANSI 24 bit
- Others.....
A MTP pointcode is private to its own network. The global uniqueness is NEVER
assured by the MTP pointcode but by global titles(as used in SCCP and in ISUP).
The representation of pointcodes can be diverse: decimal, 3-4-3-4 format, 8-8-8
format .... It is allowed to structure the pointcode(akind to CIDR and its
prefixes in IP).
MTP uses static routing: no routing protocols like RIP, OSPF or BGP are used for
finding out routes between nodes in a MTP network. However it is allowed to use
dynamic routing in a MTP net. The ITU marked this as "For Further study", but
they never got around to it.
3.2.2 SCCP adress
The SCCP address is a variable length address build as a
collection of optional elements. It identifies destinations and
has no notion about routes to those destinations. That is left to
the underlying network layer(MTP or IP). A destination can be a
network, node ,application entity, a person... Routing is static.
The SCCP address is generally refered to as a Global title. The
global title must be globally unique(at least on a world scale) as
this allows the A-party to reach the B-party End-to-End without
setting up a connection through the network. It can also be used
for Link-by-link routing.
The function responsible for deriving a pointcode from a global title is (not
surprisingly) called the global title translation function(GTT). The GTT is a
local function which bases it translation and routing decision on the local
situation(translation rule, loadsharing of destinations, route to backup
node...) It has no topological knowledge of the network(something MTP and
certainly IP have). The GTT function can therefore not only be used by msg with
SCCP address but also by Q931 or other signaling messages for finding out to
which destination the message must be sent.
The elements of the Global Title consists of the following:
- MTP pointcode AND Network indicator(=MTP-SAP). The network indicator
indicates to which network the msg belongs.
- Subsystem Number: indicates to which application the msg belongs.
- Global title: a structure indicating a global identification of a node and/or
application. A GT may occur in the SCCP Calling(=Originator address) and in the
Called(Destination address) Party address.
If only a MTP pointcode, network indicator and SSN is present,
then the message can only be routed within that particular MTP
network. If a global title(meaning if translation type, nature of
addres and/or Digits) is present (accompanied possibly by a MTP
pointcode, network indicator and SSN), then the msg can be routed
across multiple MTP networks, provided the networks are
interconnected and the destination is reachable.
3.2.3 Global Title and Global Title Translations:
A global title contains the following elements. They are nearly all optional,
the occurrence of the field in the SCCP message itself is governed by the global
title format field(GTI) in the message.
-Translation Type(TTN): should indicate what sort of translation is needed. The
most used TTN is the UNKNOWN. In the US some of the TTN have been used to
address the application(instead of the SSN), thus doubling as application
entity selectors. The Translation Type Number has no counterpart in IP.
- Numbering plan(NP): this contains the numbering plan indication to which the
rest of the address conforms. This may be the E164, E212, E211, private
numbering plans, .... The Numbering plan indication has no explicit counterpart
in IP. It is implicitly included in the IPv4 address and partly explicitly
included in the IPv6(example : E164 numbers included in OSI-NSAP address in
IPv6)
- Nature-of-address(NA): this indicates the national or international use of
the address. The Nature-of-Address has no counterpart in IP. This could be interpreted as scope indication of the address, something that is explicitly present in Ipv6 pointcodes(Link local, site local...).
- Encoding scheme(ES): this is a implicit parameter used to indicate the format of the global title digits(BCD even or BCD uneven). The Encoding scheme has no
counterpart in IP.
- Global title digits: digits in the format specified by the encoding scheme.
They contain the global identification of node(and possibly also of the
application within that node.) Also the number of digits is included(as GT is a
variable length address.
- Subsystem Number(SSN): indicates the application entity which should be
reached . Some of the SSN are universally defined while others are not. Some are
even double used. The SSN corresponds roughly to the portnumber of IP. However
SSNs are derived at the network layer and go straight through to the application
layer. Portnumbers only obtain their visibility from the transportlayer.
- Global title format: indicates which of the field mentioned above are
explicitly contained in the called or calling party address of the message.
Some formats indicates that some fields(like NA and NP) are specified
implicitly.
Global title have no explicit counterpart in IP. IP addresses are implicitly
assumed to be Global (NAT not included). A GT could also be a name(such as in
Directory Naming service (DNS)).
Also some routing information is included in the calling/called party address.
- routing Indicator: indicates to the node processing calling/called party
address how to route the message on. The message can be routed on the Pointcode
(and SSN: applicable only in the final end-node) or on global title(this
requires a translation).The routing indicator has no counterpart in IP.
Depending on the routing indicator the message will be routed by SCCP. If route-
on-SPC then MTP will do the routing. If route-on-GT then the SCCP global Title
translation function will be invoked to determine the next(possible final or
intermediate) node of the message. The address will be examined on the TTN,NP,NA
and Digits and a translation will be done yielding a MTP pointcode + network
indicator. A SSN may also be the additional outcome of the Global Title
Translation(GTT). This MTP address is then used by MTP to route to the next
destination(intermediate or final).
If required, the TTN, NP, NA, SSN and possible all the digits may be transformed
into a TTN', NP' , NA' , SSN' and digits'. It will change the address (if the
routing policy prescribes it) in a effort to reach the final destination. The
only rule to which it has to adhere is that the change in addresses must be so
that the return message(from the B-party) must reach the originator of the start
msg(=A-party). This means that the message routing is NOT symmetric. Global
title translation conforms to the notion of a Store-Compute-and-Forward network
as opposed to a IP network which is a Store-and-Forward network. This
translation is completely stateless(we are routing unitdata messages). The same
function can also be invoked for connections(see SCCP connection-oriented) then
the translation is done only once at the connection setup phase and we have then
state.
The translation rules for digits consist of:
- Deleting digits.
- Inserting digits
- Replacing digits
- Copying digits
That means that your called party address may have completely changed once it
went through the GTT and at the same time the calling party address must also be
changed to adhere to the rule that the backward message MUST be routable so that
a end-to-end dialogue may be send up between 2 nodes.
3.2.4 How to reach applications in SS7
Every layer needs to determine the service access point to which it wants to
deliver its information. The basic element in SS7 to determine this is the
Subsystem Number(SSN for short). the SSN can be found in MTP and SCCP.
The MTP has a SSN which indicates along others ISUP, SCCP ,..etc... The SSN in
MTP are standardized on international level. Locally defined SSN are allowed but
may not be used outside that network.
The SSN used in SCCP indicates directly to which application the message must be
send to. These SSN may be standardized but that is not a prerequisite(see Q715).
Some applications have standardized SSN, while others use(and sometimes reuse)
not standardized SSN. When messages go from a net with SSN1 to a net with
SSN2(SSN1 and SSN2 indicate the same protocol) global title translation must be
invoke to convert the SSN's. This is one of the most basic and simplest use of
Global Title translation in SS7.
3.3 Possible architectures of SS7-over-IP
3.3.1 General SS7-over-IP architecture.
Examples of usage for SS7-over-IP include:
- terminating call-related and non-callrelated signalling to a
Media gatway Controller(MGC). (PSTN to IP)
- Transparant transport of signalling information accross a
intranet or internet infrastructure between 2 intermediate SS7
nodes.(PSTN-IP-PSTN)
- Originating call-related and non-callrelated signalling from the
SS7-over-IP net to the PSTN.(IP to PSTN)
- SS7-over-IP to SS7-over-IP networks (IP-PSTN-IP or IP-IP).
The general architecture should look like this:
+-----+
| ASC |
+-----+
|
|
! | !
! | !
+----+ +-----+ +----+
-| SG |----------| SRP |----------| SG |-----
+----+ +-----+ +----+
! !
! !
NB NB
Fig 1: General SS7-over_IP architecture
- SG: Signalling Gateway: marks the border between administrative
domains in the SS7-over-IP or between the PSTN and the SS7-over-IP
=> Network Border = NB
- SRP: Signalling relay point(optional): perform additional
routing within the administrative domain. This functionality is
taken care of by the SGs in small networks.
- ASC: Application Server Cluster: contain the applications(ISUP,
MAP, ISS, QSIG, LNP...) to use. The server may be directly
interconnected with the SGs in small networks.
Every node(SG, SRP, ASC...) has its own SS7 pointcode.
3.3.2 Examples of SS7-over-IP
Fig 3.3.2.1 PSTN - MGC example
Fig 3.3.2.2 PSTN - PSTN transport example
Fig 3.3.2.3 3G.IP example
3.4 SS7 Signalling transport using SCTP
SS7 messages are transported across IP using the Simple Control
Transmission Protocol(SCTP). SCTP provides a high relialable,
redundant transport between 2 SS7-over-IP nodes. A SS7-over IP
node is a SCTP endpoint.
The interface with SS7 is message based. Therefore a
adaptationlayer is needed to prevent changes to the upper layer
SS7 protocols.
Within a asociation between 2 endpoint, 1 or more stream(s) may be
avialable. These streams are not directly visible to the
adaptation layers.
The linkset towards a certain destination is the collection of all
the links which can send trfaffic to that destination, even with a
intermediate node in between(so different path towards that
destination exsist). The MTP linkset is thus equivalent to the
SCTP association. The streams within SCTP may be regarded as the
links. A advantage of SCTP streams is, when one of the multihomed
paths fails, the stream will migrate to one of the still open
paths(Soft changeover). In SS7 when a link fails, a
a change over procedure has to be initiated towards a still
working link of the same linkset(=hard changeover)).
In a MTP based network, the capacity of the links is fixed at n
times 64Kb (with n= 1,32,...). SCTP association do not have a
fixed capacity assigned to them. The bandwith used/provided by
SCTP is dependant on the rest of the traffic(other SCTP, TCP,
RTP,UDP...) going through the same links of the path followed by
the SCTP association. See also the SCTP applicability
statement[17].
3.4.1 MTP lvl 2 user adaptation layer(M2UA)
The MTP lvl 2 user adaptation layer provides a emulation of a
single MTP link between 2 SS7 nodes.
3.4.2 MTP lvl 3 User adaptation layer(M3UA)
The MTP lvl 3 user adaptation layer provides a emulation of MTP
lvl 3 towards its users. Its function is address translation and
mapping, stream mapping, congestion control and network
management.
3.4.2.1 Address Mapping
The M3UA layer has to handle a couple of SCTP associations. The
selction of such a SCTP association is done by primarly using the
MTP DPC (and other fields of the MTP routing label). This DPC is
mapped to a SCTP association. If a association were to fail then
alternate mapping may be done(Implementation dependant).
3.4.2.3 Network Management
Management messages are exchanged between the M3UA peers for
exchanging and updating the status of the SS7-over-IP nodes.
3.4.2.4 Network Maintenance
3.4.3 Multihoming within SCTP
Redundant communication between 2 SCTP endpoints is achieved by
using multihoming where the endpoint is able to send/receive over
more than one IP address/UDP port.
Under the assumption that every IP address/UDP port will have a
different path towards the remote endpoint, (this is the
responsability of the routing protocols or of manual
configuration), if the transport to one of the IP address/UDP port
(= 1 particular path) fails then the traffic can migrate to the
other remaining IP address/UDP ports(= other paths).
3.5 Congestion control & avoidance
2 levels of congestion control/avoidance are present in a
SS7-over-IP net.
- congestion control/avoidance within SCTP
- Congestion control/avoidance present in the layers above the
user adaptation layers( example: SCCP, ISUP ...)
For a more indepth description of congestion , see the SCTP
applicability statement[1].
SCTP conforms to the model of end-to-end congestion control
located in the transport leyer while ISUP and SCCP model
themselves on a link and destination based congestion
control/overload mechanism located in the network layer.
3.6 Use of QOS methods for signalling transport
SCTP is a end-to-end protocol which cannot guarantee the quality
of service along the complete path.
- Overprovisioning of the links so that the total traffic running
over over the link never exced the link capacity
- Use of a intranet solely for signalling transport purposes
- Differentail services: by providing a certain codepoint in the
Type-of-service field (TOS), certain Differential services can be
selected.
3.6.1 Differentiated services
3.6.2 Integrated services
5.0 Routing of SS7 message in a IP net.
5.1 Routing using globally assigned IP addresses.
IP addresses are required to be globally unique. If SS7 wants to
transport its messages over a IP network, then they should be
treated as global addresses. This means that SS7 shall look at
them as global titles, it shall NOT rely on the specific handling
of the addresses by the underlying IP layer and below. This also
means that SCCP is a prerequisite for transporting message over a
IP infrastructure when non-call related messages are to be
transported over IP. ISUP and other signaling protocols will have
to the same for call related messages , translating the addresses
it has in the adaptation layers to IP addresses. They can all
invoke the GTT function if wanted.
The following cases may be envisioned:
- E164,E212, (=telephone numbers) to IP address(depending on the underlying
network Ipv4 or Ipv6) (equivalent to translation MTP 14bit, 24bit ...)
- IP address to IP address
- IP address to MTP address
- IP address to a form of a telephone address (=E164*) : needed if the message
transit from a IP net to a IP net via a couple of MTP nets.
As some forms of IP addresses have a very limited scope(such as link-local and
site local), they should better not be used. Globally assigned Unicast,
multicast may be used.
A word of care is advised when using multicast addresses. This is especially
true if the routing indicator in SCCP is Route-on-GT. SCCP has no knowledge
whether the translation yielded a unicast or multicast PC, so it cannot and it
will not take action to relay or stop the message. This is a area for further
study.
Implications of this are that GTT function could support IP pointcodes. The IP
pointcode must be put in the digit block of the GT. The representation may be in
BCD, the meaning of it should not. The length of a Ipv4 address(32bits) should
then be 8 digits(always fixed). The length of a Ipv6 address(128bits) should be
32 digits. The GT number of digits in the SCCP header should allow for at least
32 digits(some extra digits may need to be inserted for proper routing). The
result attached to a certain translation must be or a MTP PC(14,24) or a Ipv4 PC
or a Ipv6 PC. The nature of address may be defined as indicating a international
address with bitmap format. This could even lead to a new GTT operation (besides
insert, copy, delete, replace) called bitmapPCCopy. The bitmapPCcopy takes the
IPvx poitncode out of the GT and uses it as the resulting pointcode of the GTT
for further routing. The same effect can also be achieved via proper engineering
of the GT database.
Other possibilities include User adaptation layers which maps the MTP pointcode
to IP pointcode or a mapping from MTP pointcode to a certain SCTP session.
If GTT is used then IP must need a Numbering plan indicator(NP value normally
assigned by SG11). This may or may not be agreed with SG11. This is not
mandatory(but it is encouraged) as already there exists private numbering plans
not known to SG11. As long as you make sure at the network border via GTT that
the next network will be able to route the message NP , you can do pretty much
anything. This is a bilateral agreement between operators/Internet Service
providers)
In general any value may be used as long as it is routable in your own subnet
and that you or somebody else is able to route it further over its own net.
Also maybe the portnumber may become part of the input/output to the GTT
function.
5.2 Routing SS7 messages and dynamic assigned adresses
Problems may occur with dynamicable assigned IP addresses. The
node would obtain a IP address that is later reclaimed and/or
replaced by another IP address out of a pool of IP addresses. The
destination address in the routing Tables would have to be
invalidated or changed. Therefore it is strongly recommended to
use a fixed assigned IP address. Do not forget that the IP node
which is working in the SS7 net is supposed to be up all the time.
It should not be regarded as a dial-up user(for which Dynamic
assigned addresses are meant).
If this practice should turn out to be unavoidable, then a Q3/SNMP Management msg would be required to be exchanged between DHCP and SCCP network element configuration part so that the pointcode attached to a certain GT must be updated, deleted or added. The same solution is also feasible for working in NAT's with dynamical assigned addresses.
5.3 Routing SS7 message and Network address Translators.
Network Address Translator(NAT) are boxes which map a private IP net address to
a globally assigned IP address. This happens because there are many more users
within the private IP net than there a globally assigned IP addresses allocated
to that private IP net. That means that the mapping is ALWAYS dynamic. The
mapping must be both ways and via the same NAT and the NAT is always the final
destination. Also the association is based on state(thus breaking the end-to-end
principle). This amounts to crossing a network border. It should be envisioned to use a static private address in the NAT.
5.3 Routing SS7 messages and routing protocols
The term routing protocols has a much broader sense in the
Internet than in the SS7 world. SS7 designates such protocols as
Management protocols(SCCP management, MTP management...) The scope
of SS7 management protocols is much smaller. They only exchange
informations of links in service and nodes in service(mostly only
the own links and the adjacend nodes) The topology of the network
is NOT exchanged between SS7 nodes. In general most nodes haven't
got the faintest idea how even the topology of its own subnet may
look like.(and they don't care).
The interaction between IP routing protocols and SS7 routing may require some
study especially in the case that routes start changing due to routing
recomputation. The loadsharing and primary/backup systems of GTT seems not to be
impacted as it relies on destinations and not on links. As long as a destination
is accessible/avialable in the IP net, then messages may be send to it. If the
destination is no longer avialable, then GTT must perform according to its own
rules. Beware of changing conditions being triggered by routing updates.
5.4 Routing SS7 messages and automatic renumbering
Automatic renumbering is the process of changing the IP addresses
of one or more nodes in a network so that the prefix of the
address (which is then common for all the changed nodes) allows to
have a routing table with a reduced number of entries. This
renumbering is mainly of interest in IPv6 networks.
If this happens, a similar solution(management request of the GT
tree) should be used to change the pointcode derived from GT.
6.0 Security
The following aspects of security are :
6.1 Authentication
Information is sent/received from a known and/or trusted partner. Until recently
the number of interconnects of a SS7 node with another SS7 node belonging to
another operator was relativily limited and those other operators were implicitly
known (and sometimes trusted). Due to the increasing interconnect demands between
different operators on a voluntary or mandatory basis, the trusted relation
does not longer exist. That mean that a operator will not accept all SS7 msg
send to him by another operator. This is done using MTP and SCCP screening:
depending on the inormation in the different MTP fields(example OPC...) and/or SCCP
fields(example Calling party address, SSN...) a msg may be rejected or accepted
for transport across or termination into the network. In the worst case it may
try to screen up to the application level(example: the user info in a IAM msg or
in a TC INVOKE component, Application Context name screening). See [16].
A SS7 gateway using screening does behave like a firewall.
6.2 Intergrity
Information may not be modified while in transit. The integrity of a msg in a
public network is not guaranteed. If it is transported over a IP network the
integrity may be guaranteed at 2 levels.
(1) the IP level using IPSEC:
which is equivalent to providing integrity on on SS7 link level basis. Keydistribution
is at most limited to the network of that operator.
(2) End-To-End integrity using TCAP: For further study in the ITU.
6.3 Confidentiality
Information cannot be examined by not authorised users.
6.4 Availability
The communicating endpoint must remain in service in all circonstances.
All SS7 nodes have to remain active for the 99.999% of the time.
7.0 References and related work
[01] ITU-T Recommendation Q.700, "Introduction to CCITT Signaling System
No.7", March, 1993
[02] ITU-T Recommendation Q.701-705, "Message Transfer part
No. 7", 1996
[03] ITU-T Recommendation Q.710-715, "Signaling Connection Control Part
No. 7", 1996
[04] ITU-T Recommendation Q.770-775, "Transaction Capabilities Application Part
No. 7", 1996
[05] ITU-T Recommendation Q.1400, " architecture framework for the
development of signaling and OA&M protocols using OSI concepts ",1993
[06] "Routing in the Internet", C. Huitema, 1995, Prentice-Hall
[07] "Signaling System #7", T. Russell,1998, McGraw-Hill
[08] An Architecture for IPv6 Unicast Address Allocation (RFC 1887)
[09] OSI NSAPs and IPv6 (RFC 1888)
[10] IP Version 6 Addressing Architecture (RFC 2373)
[11] An IPv6 Aggregatable Global Unicast Address Format (RFC 2374)
[12] IPv6 Multicast Address Assignments (RFC 2375)
[13] Proposed TLA and NLA Assignment Rules (RFC 2450)
[14] Internet Protocol, Version 6 (IPv6) Specification (RFC 2460)
[15] Names, addresses, ports and routes(RFC 0814)
[16] Telcordia Screening Requirements (.....)
[17] SCTP applicability statement (RFCmmmm)
7.0 Authors
Lode Coene
Siemens Atea
Atealaan 34
Herentals, Belgium
Phone: +32-14-252081
Email: lode.coene@siemens.atea.be
Expires: May 2000
Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.
