Internet DRAFT - draft-coene-ss7-IP-addr
draft-coene-ss7-IP-addr
HTTP/1.1 200 OK
Date: Mon, 08 Apr 2002 23:19:28 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Mon, 18 Jan 1999 17:49:00 GMT
ETag: "2e7f84-5bbf-36a3740c"
Accept-Ranges: bytes
Content-Length: 23487
Connection: close
Content-Type: text/plain
INTERNET DRAFT Lode Coene
Category: Memo Siemens Atea
Title: <draft-coene-ss7-IP-addr-00.txt>
Date: January 1999
Expires: July 1999
Internet and SS7 addressing
<draft-coene-ss7-IP-addr-00.txt>
Status of this Memo
This document is an Internet-Draft. 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."
To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract
This document makes a comparison between Internet and SS7 addressing. The
functions of SS7 network layer relating to addressing and their relation with
the corresponding IP functions are explained. This may leads to requirements
for SS7 functionality dealing with IP addresses if SS7 signalling messages
are to be transported over IP infrastructure.
Table of Contents
1.0 Introduction
2.0 Terminology
3 Internet addressing
3.1 IP addresses
3.3 How to reach applications in the Internet
4 SS7 addressing
4.1 MTP addressing
4.2 SCCP addressing
4.3 Global Title
4.4 How to reach applications in SS7
5.0 Routing of SS7 messages in a IP net
5.1 Routing using globally assigned IP addresses.
5.2 Routing SS7 messages and Network Address Translators
6.0 References
7.0 Authors
1.0 Introduction
This architecture document covers subject terminology and makes a overview of
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
directly.
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)
Called Party Address(CLD):
Address of the party the message wants to reach.(Party can be a node,
person...,
a entity in general)
Calling Party Address(CLG):
Address of the party from which the message originated.
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 routing function which part of the address has
to use for routing the message.
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 which application needs to be reached in the
layer above.
Subnet: a subnet is a collections of nodes, belonging to the same operator/ISP
or colective 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 Internet addressing
3.1 IP address
3.2 How to reach applications in the Internet
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 determine 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 sorts
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.( Same 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.
4.0 SS7 addressing
4.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
- ITU 24 bit
- ANSI 24 bit
- Others.....
A MTP pointcode is private to its own network. The global uniqueness is not
assured by 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.
4.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. 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 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.
4.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 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(in stead 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.
- Encoding scheme: 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.
- 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 route 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.
4.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.
5.0 Routing of SS7 message in a IP net.
5.1 Routing using globally assigned IP addresses.
As IP addresses are seen by the community at large as global, 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 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 should 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 maximum allowed digits in the SCCP header may need to be
extended from 24 digits to 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(Just a idea). The same can be achieved via proper engineering of
the GT database.
A alternative is to use a MTP pointcode to IP pointcode mapping table.
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 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 means that global title translation will have a hard time.
5.3 Routing SS7 messages and routing protocols
The term routing protocols is much broader in the Internet than it is in the
SS7
world. SS7 designates such protocols as Management protocols(SCCP mamagement,
MTP management...) The scope of SS7 management protocols is far 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 perfom according to its own
rules. Beware of changing conditions being triggered by routing updates.
6.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)
7.0 Authors
Lode Coene
Siemens Atea
Atealaan 34
Herentals, Belgium
Phone: +32-14-252081
Email: lode.coene@vnet.atea.be
Full Copyright Statement
Copyright (C) The Internet Society (1998). 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.
