INTERNET DRAFT Lode Coene Category: Memo Siemens Atea Title: Date: November 1999 Expires: May 2000 SS7 over internet applicability statement 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.