INTERNET DRAFT Lode Coene Category: Memo Siemens Atea Title: Date: January 1999 Expires: July 1999 Internet and SS7 addressing 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.