idnits 2.17.1 draft-ietf-sigtran-signalling-over-sctp-applic-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 30 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 31 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 316: '...livery mechanism SHOULD meet the follo...' RFC 2119 keyword, line 599: '...s(such as SCCP), SHOULD NOT/MUST NOT t...' RFC 2119 keyword, line 800: '...backward message MUST be routable so t...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 70 has weird spacing: '...ased on their...' == Line 74 has weird spacing: '...ased on their...' == Line 182 has weird spacing: '...onality till ...' == Line 217 has weird spacing: '...rotocol provi...' == Line 508 has weird spacing: '...erances at th...' == (4 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFCblabla' on line 160 looks like a reference -- Missing reference section? 'RFCSCTPA' on line 375 looks like a reference -- Missing reference section? '11' on line 315 looks like a reference -- Missing reference section? 'RFCSCTPAS' on line 1264 looks like a reference -- Missing reference section? 'RFC2719' on line 1240 looks like a reference -- Missing reference section? '17' on line 870 looks like a reference -- Missing reference section? '1' on line 946 looks like a reference -- Missing reference section? '16' on line 1198 looks like a reference -- Missing reference section? '18' on line 1227 looks like a reference -- Missing reference section? 'SCTP' on line 1231 looks like a reference -- Missing reference section? 'Q1400' on line 1280 looks like a reference -- Missing reference section? 'IANA' on line 1244 looks like a reference -- Missing reference section? 'RFC814' on line 1249 looks like a reference -- Missing reference section? 'M2UA' on line 1252 looks like a reference -- Missing reference section? 'M3UA' on line 1256 looks like a reference -- Missing reference section? 'IUA' on line 1260 looks like a reference -- Missing reference section? 'Q700' on line 1268 looks like a reference -- Missing reference section? 'Q70X' on line 1271 looks like a reference -- Missing reference section? 'Q71X' on line 1274 looks like a reference -- Missing reference section? 'Q77x' on line 1277 looks like a reference -- Missing reference section? 'RFC1035' on line 1284 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 10 warnings (==), 24 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT L. Coene 2 Internet Engineering Task Force Siemens 3 Issued: 30 june 2000 J. Loughney 4 Expires: 31 December 2000 Nokia 5 I. Rytina 6 Ericsson 7 L. Ong 8 Nortel Networks 10 Signalling Transport over SCTP applicability statement 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet- 28 Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html 31 Abstract 33 This document describes the applicability of the Stream Control 34 Transmission Protocol for transport of signalling information over IP 35 infrastructure. A few signalling application are descibed such as 36 signalling System Nr7(SS7), Digital Subsciber Service 1/2 37 (DSS1/2).... Specific info on signalling transport over 38 IP(addressing, routing) is also provided. The use and specification 39 of each of the adaptation layers for signalling transport in 40 conjunction with SCTP is described. 42 Draft Signalling Transport over SCTP applicability statementJuly 2000 44 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 46 Signalling transport over SCTP Applicability statement ......... ii 47 Chapter 1: Introduction ........................................ 1 48 Chapter 2: Signalling tranport using SCTP ...................... 3 49 Chapter 9: Security considerations ............................. 25 50 Chapter 10: References ......................................... 28 51 Chapter 11: Authors ............................................ 29 53 1 INTRODUCTION 55 This applicability statement document covers subject terminology 56 and makes a overview of the solutions for transporting SS7, ISDN user or 57 any other form of signalling information over Internet Protocol infras- 58 tructure. This includes also a overview of the available Internet and 59 SS7 addressing. It tries to explain what the meaning is of the different 60 addressing modes in the internet and Signaling System Nr. 7 and where 61 their added value resides. Some example scenario's are provided as exam- 62 ple of how applications in the SS7 and/or internet may be able to reach 63 each other. 65 1.1 Terminology 67 The following functions are commonly identified in related work: 69 Signal Transfer Point (STP): This is a node in an SS7 network that 70 routes signalling messages based on their destination address in 71 the SS7 network 73 Signal Relay Point (SRP): This is a node in an SS7 network that 74 routes signalling messages based on their called party address in 75 the SS7 network. (Translates Called party address to a destination 76 pointcode and also translates Calling prty address when needed) 78 Stream Control Transmission Protocol(SCTP): A transport protocol 79 designed for the reliable transport of signalling information over 80 a connectionless network( example: the Internet) 82 Called Party Address(CLD): Address of the party the message wants 84 Draft Signalling Transport over SCTP applicability statementJuly 2000 86 to reach.(Party can be a node, person, network..., a entity in 87 general)(=Destination address) 89 Calling Party Address(CLG): Address of the party from which the 90 message originated.(Originating address) 92 Global Title:(GT) A globally unique identifier used in the CLD 93 and/or CLG for identifying a entity. A global title can consist of 94 a pointcode, translation type, nature of address, numbering plan 95 and the title itself(=digits). 97 Pointcode(PC) The Pointcode in SS7 and IP have the same meaning, 98 but not necessary the same size and interpretation. A pointcode 99 identifies a node within a particular network. 101 Routing Indicator: The routing indicator tells the SCCP routing 102 function which part of the address has to use for routing the 103 message(SSN + global title or SSN + pointcode). 105 Translation Type Number(TTN): The translation type number indicates 106 the translation type of the address. 108 Numbering Plan(NP): This indicates the numbering plan to which the 109 digits belong: that can be E164, E212, private numbering plans, 110 Internet Numbering Plan, ..... 112 Nature-Of-address(NA): The nature of address indicates whether a 113 address is for national, international or other use. 115 Encoding Scheme(ES): The encoding scheme indicates how the digits 116 are encoded. Encoding is normally in Binary Coded decimal(BCD) for- 117 mat. 119 SubSystem Number(SSN) The SSN indicates the application entity that 120 must be reached in the final destination node of the msg 122 Global Titel Format(GTI): Indicates which of the above mentioned 123 parameters are actually present in the party address. If some 124 parameters are not present in the address then default parameters 125 are used for executing the Global Title Translation. 127 Portnumber: Indicates on the tranport level in IP which applica- 128 tion needs to be reached in the layer above. 130 Subsystem number(SSN): Indicates on the networklayer in SS7 which 131 application needs to be reached in the application layer. 133 Subnet: a subnet is a collections of nodes, belonging to the same 135 Draft Signalling Transport over SCTP applicability statementJuly 2000 137 operator/ISP or collective of operators/ISP's. This may be 138 equivalent with a Internet domain. A MTP net is always a subnet. 139 Subnet may be owned by more than one operator(example MTP NAT0 sub- 140 net in the US) 142 Transport Address: An IP address and a port number pair which 143 identifies a SCTP association. 145 2 Signalling tranport using the Stream Control Transmission Protocol 146 (SCTP) 148 2.1 INTRODUCTION 150 The Stream Control Transmission Protocol(SCTP) provides a high relial- 151 able, redundant transport between 2 endpoints. It also makes sure that 152 it will back off in case of congestion on the internet it is running on. 153 The interface between SCTP and its signalling applications is handled 154 via adaptation layers which provide a intermediation layer so that the 155 upper layer signalling protocols of a certain protocol stack architec- 156 ture does not have to change their interface towards the transport 157 medium and internal functionality when they start using SCTP instead of 158 a other transport protocol. Another issue is that the supported protocol 159 stack architecture will conform to the internet architecture as 160 described in [RFCblabla] without compromising its own rules. 162 For more information of how to use SCTP see [RFCSCTPA]. 164 2.2 Adaptation layers for SCTP 166 Adaptation layers are used for transporting protocols without having to 167 change the interfaces between the tranported protocol and SCTP. SCTP is 168 a stream based protocol while some application of SCTP are message based 169 protocols. Without a adaptation layer, the transported protocol would 170 have to change in protocol structure or its underlaying interface or 171 some intermediate layer would be necessary. 173 It is the task of the adaptation layer to present the view towards its 174 application protocol as if it was the original protocol or protocol 175 stack that it is substituting for. therefore a adaptation layer is more 176 aptly called a Foo User adaptation layer, with foo the protocol is sub- 177 stituted for. 179 2.2.1 How to define and Use adaptation layers 181 Many different signaling applications may use SCTP for different pur- 182 poses. They go from replacing MPT functionality till replacing SCCP 184 Draft Signalling Transport over SCTP applicability statementJuly 2000 186 signalling information transport. 188 The basic architecture is as in Figure 1 : 190 User/Application level Protocols 191 | | | 192 +------------------------------------+ 193 | User Adaptation modules | 194 +------------------------------------+ 195 | 196 +------------------------------------+ 197 |Stream Control Transmission protocol| 198 +------------------------------------+ 199 | 200 +------------------------------------+ 201 | Standard IP Transport | 202 +------------------------------------+ 203 | 204 Network Layer (IP) 206 Figure 2.4.1: Transport Components 208 The three components of the transport protocol are : 210 (1) Adaptation modules that support specific primitives, e.g. manage- 211 ment indications, required by a particular user/ application proto- 212 col. 214 (2) the Stream Control Transmission Protocol itself that supports a 215 common set of reliable transport functions. 217 (3) a standard IP transport/network protocol provided by the operating 218 system. In some network scenarios, it has been recognised that TCP 219 can provide limited (but sufficient) reliable transport functional- 220 ity for some applications, and this is discussed later in this 221 document. 223 Each of the interfaces described above may be implementation depen- 224 dant. They are in general not specified by the protocol documents. 226 2.2.2 Adapation layers for signalling transport 228 Draft Signalling Transport over SCTP applicability statementJuly 2000 230 Currently, there are four adaptation layers, to support carrying of SS7 231 application protocols over IP. These adaptation layers are being 232 developed for different purposes, and there is no assumption that they 233 should interwork - i.e. - M2UA carries M3UA. They should be thought of 234 as individual protocols for specific uses. 236 Adataption layers can have a peer-to-peer or master-slave relationship. 237 The master-slave relationship is mostly envisioned for very simple net- 238 works while the peer-to-peer case is more for fullfledged signalling 239 networks(akind to the present SS7 network worldwide). 241 2.2.2.1 IUA 243 There is a need for Switched Circuit Network (SCN) signaling protocol 244 delivery from an ISDN Signaling Gateway (SG) to a Media Gateway Con- 245 troller (MGC). The delivery mechanism should meet the following cri- 246 teria 248 * Support for transport of the Q.921 / Q.931 boundary primitives 250 * Support for communication between Layer Management modules on SG 251 and MGC 253 * Support for management of active associations between SG and MGC 255 This draft supports both ISDN Primary Rate Access (PRA) as well as Basic 256 Rate Access (BRA) including the support for both point-to-point mode and 257 point-to-multipoint modes of communication. QSIG adaptation layer 258 requirements do not differ from Q.931 adaptation layer, hence the pro- 259 cedures described in this draft are also applicable to QSIG adaptation 260 layer. 262 2.2.2.2 M2UA 264 There is a need for SCN signaling protocol delivery from an Signaling 265 Gateway (SG) to a Media Gateway Controller (MGC) or IP Signaling Point 266 (IPSP). The delivery mechanism should meet the following criteria: 268 * Support for MTP Level 2 / MTP Level 3 interface boundary 270 * Support for communication between Layer Management modules on SG 271 and MGC 273 Draft Signalling Transport over SCTP applicability statementJuly 2000 275 * Support for management of active associations between the SG and 276 MGC 278 In other words, the Signaling Gateway will transport MTP Level 3 mes- 279 sages to a Media Gateway Controller (MGC) or IP Signaling Point (IPSP). 280 In the case of delivery from an SG to an IPSP, the SG and IPSP function 281 as traditional SS7 nodes using the IP network as a new type of SS7 link. 282 This allows for full MTP Level 3 message handling and network management 283 capabilities. 285 2.2.2.3 M3UA 287 There is a need for SCN signaling protocol delivery from an SS7 Signal- 288 ing Gateway (SG) to a Media Gateway Controller (MGC) or IP-resident 289 Database as described in the Framework Architecture for Signalling Tran- 290 sport [11]. The delivery mechanism should meet the following criteria: 292 * Support for transfer of all SS7 MTP3-User Part messages (e.g., 293 ISUP, SCCP, TUP, etc.) 295 * Support for the seamless operation of MTP3-User protocol peers 297 * Support for the management of SCTP transport associations and 298 traffic between an SG and one or more MGCs or IP-resident Databases 300 * Support for MGC or IP-resident Database failover and loadsharing 302 * Support for the asynchronous reporting of status changes to 303 management 305 In simplistic terms, the SG will terminate SS7 MTP2 and MTP3 protocols 306 and deliver ISUP, SCCP and/or any other MTP3-User protocol messages over 307 SCTP transport associations to MTP3-User peers in MGCs or IP-resident 308 Databases. 310 2.2.2.4 SUA 312 This document details the delivery of SCCP-user messages (MAP & CAP over 313 TCAP, RANAP, etc.) over IP, from an SS7 Signaling Gateway (SG) to an 314 IP-based signaling node (such as an IP-resident Database) as described 315 in the Framework Architecture for Signaling Transport [11]. The 316 delivery mechanism SHOULD meet the following criteria: 318 Draft Signalling Transport over SCTP applicability statementJuly 2000 320 * Support for transfer of SS7 SCCP-User Part messages (e.g., TCAP, 321 RANAP, etc.) 323 * Support for SCCP connectionless service. 325 * Support for SCCP connection oriented service. 327 * Support for the seamless operation of SCCP-User protocol peers 329 * Support for the management of SCTP transport associations 330 between an SG and one or more IP-based signaling nodes). 332 * Support for distributed IP-based signaling nodes. 334 * Support for the asynchronous reporting of status changes to 335 management 337 2.2.3 General issues for transporting signalling info over SCTP 339 2.3.4 SCTP Multihoming 341 Redundant communication between 2 SCTP endpoints is achieved by using 342 multihoming where the endpoint is able to send/receive over more than 343 one IP transport address. 345 Under the assumption that every IP transport address will have a dif- 346 ferent path towards the remote endpoint, (this is the responsability of 347 the routing protocols(3.2.4) or of manual configuration), if the tran- 348 sport to one of the IP address/port (= 1 particular path) fails then the 349 traffic can migrate to the other remaining IP address/ports(= other 350 paths). 352 2.2.5 Routing protocols 354 In order to provide redundant paths for a certain SCTP association 355 throughout the network, Routing protocols must support multihoming and 356 the endnodes must have at LEAST one transport address(that is have more 357 than 1 interface with a IP address). 359 It is advisable to let the originator choose from which source addresss 360 it can send the datagram towards the destination because the paths are 361 based on source, destination pair and letting the network layer choose, 362 would probably always yield a alternating selection of the source and 364 Draft Signalling Transport over SCTP applicability statementJuly 2000 366 thus of the interface. 368 Do not forget that congestion control is an a per destination basis, 369 which is not completely the same as congestion control on a path basis 370 if the source PC cannot be explicitly stated form a datagram. 372 2.3.11 Congestion control & avoidance 374 A general overview of congestion control and avoidance can be found in 375 the SCTP applicability statement[RFCSCTPA]. 377 However some particular restrictions migth be observed when using SCTP 378 for transporting signalling info over IP infrastructure. This restric- 379 tions must be aplied with care as in most cases, the SCTP association is 380 never in complete full control of the links between the 2 nodes exchang- 381 ing the signalling info. See paragraph 2.3.12, use of QOS methods. 383 This restrictions are mostly based on restriction found in the origianl 384 protocol, the adaptation layer is replacing. (Example: boundaries on 385 message transmission time, retransmission timers and so on). Sometimes 386 the restriction has a direct impact on some of SCTP protocol variables 387 which might to be tunable for tranporting signalling traffic. 389 2.3.12 Use of QOS methods 391 SCTP is a end-to-end protocol which cannot guarantee the quality-of- 392 service along the complete path taken by the messages of that particular 393 association. It only guarantees that a message will be deliverred wintin 394 a certain timeframe or otherwise be lost. If more guarantees are 395 required(example: on the timeframe, message loss...) for improving the 396 relialability of the transport, some form of QOS mechanism may be 397 needed. 399 (1) Overprovisioning 400 Overprovisioning of the links so that the total traffic running 401 over over the link never excedes the link capacity. In practice, 402 this may be difficult to ensure reliably. If the same performance 403 as MTP is required(regarding msg delays and msg delivery), then it 404 is advisable to assign at most a single SCTP association to a IP 405 link. This would also mean that the 2 endpoints would be directly 406 interconnected. A router may be present but should carry only the 407 traffic of those SCTP associations between the 2 nodes. Any router 408 that might be present and carries unrelated traffic would interfer 410 Draft Signalling Transport over SCTP applicability statementJuly 2000 412 with the SCTP association esspecially in high load condition. Due 413 the backoff of SCTP in high load conditions, that would mean that 414 for example 2 associations would get each about the 50% of the link 415 bandwith or router capacity if both where trying to run at the 416 highest transmission rate possible(without packet loss). 418 If another transport protocol which does not behave as SCTP and/or 419 TCP would be running on the same link, or through the same router 420 as the signalling traffic, then the signalling traffic may be 421 pushed aside by the more aggressive transport protocol. 423 The general rule is that if the associations try to obtain maximum 424 throughput accross a single link in absence of any other traffic, 425 they will over a long time divide the bandwith up in equal 426 spaces(example 4 users => bandwith of 1 user = Total linkbandwith / 427 4) 429 If agressive transport protocols are used, then the SCTP assocai- 430 tion will be pushed to use minimal bandwith(mathematical speaking : 431 bandwith use of SCTP will go to 0) 433 (2) Specific intranet Use of a private network solely for signalling 434 transport purposes. Private networks may allow better control and 435 monitoring of resources available. 437 (3) Differentiated services: by providing a certain codepoint in the 438 Type-of-service field (TOS), certain Differential services can be 439 selected. Setting the code point for signaling transport requires 440 some thought. It is good practice to give the signaling transport 441 a higher priority than the traffic for which the signaling is being 442 made. 444 (4) Integrated services By use of integrated services [RSVP reference 445 needed], resources are reserved for signaling transport. If 446 resources are unavailable for to initiate a new signaling tran- 447 sport, that request will be denied. In practice, RSVP may turn out 448 not to scale very well for large number of signalling links and 449 this solution may prove to be unfeasable. 451 2.3.13 Multiple associations. 453 The association may be spread out acrossn the IPv4 and IPv6 domain. 454 /* editors note: Multiple associations: see in the MDTP drafts en 455 SCTP drafts got lost in transit */ 456 2.3.14 Efficiency 458 Draft Signalling Transport over SCTP applicability statementJuly 2000 460 2.2.15 Bundeling 462 Bundling can be done on SCTP and/or on user adapatation layer. In 463 case of the adapatation layer it has to specified by the adaptation 464 protocol. 466 2.2.16 Portnumbers 468 The SG acts as a server and listen on the wellknown port of the adapta- 469 tion layers that the SG supports. The clients can indicate to the SG to 470 use different portnumbers. (dynamical portnumber assigment) The subse- 471 quent communication is then exchange via those portnumbers. If 2 472 servers try to connect, then the adaptation layer management should 473 resolve to client-server model. 475 2.2.17 Sequenced / non-sequenced delivery 477 SCTP can deliver messages in sequence or not in sequence. Most signal- 478 ling adaptation layers expect SCTP to deliver the msg in sequence. How- 479 ever not all SS7 applications (= applications located above the adapta- 480 tion layer) do need sequenced delivery. 482 2.2.18 Stream usage 484 The application can choose on which stream he can send it data. Some 485 application level protocols may standardize stream number usage conven- 486 tion, which, for instance, allows to send jpeg and gif portions of a 487 page through certain stream while text through others, so as to avoid 488 large graphics from blocking text content. This is not a must. 490 User adaptation layers data msg and adaptation layer management msg may 491 be transported over different streams. The order of the management msg 492 should be kept. Sequence is important. Management msg Should be on 493 stream 0. It is alllowed for some management msg to use unordered , 494 non-stream 0 streams. This should be specified by the management part of 495 the user adaptation layer. 497 2.2.19 Network apperance Identifier 499 A similar id to the protocol id (see SCTP applicability 500 statement[RFCSCTPAS]) is also contained in the adaptation layers, but it 501 has not the same meaning. It is called the network apperance(akin to the 502 network idnetifier in SS7: NAT0, NAT1...). It is a administrable number 503 to be determined between or within the network operator. The network 505 Draft Signalling Transport over SCTP applicability statementJuly 2000 507 apperance identifies a set of pointcodes. SG and Host can be present in 508 in different network apperances at the same time. Communication should 509 be done between nodes of the same network apperances(thus having the 510 same network apperance value). 512 3 SPECIFIC ISSUES OF SIGNALLING ADAPTATION LAYERS 514 3.1 MTP lvl3 User Adaptation layers(M3UA) 516 3.1.1 Routing in M3UA 518 a strict assignment must be made in the SG to reach the correct Applica- 519 tion Server(AS) (Example ISUP CICs and trunkgroups must match). The 520 Application Server Process being part of the AS must have common state 521 sharing between the ASPs. Each ASP of the same 522 AS can be a different Application node(AN). Each application is a 523 physical box or host. How the state is shared, is an internal 524 implementation issue. 526 3.1.2 M3UA heartbeats 528 If a M3UA nodes fails,then this must be detected via the use of heart- 529 beats msg between the M3UA peers. The SCTP heartbeat is not sufficient 530 because it only determines if a path for the SCTP association exists, 531 not if M3UA is ready to process msg. 533 The transmission rate of sending keepalive msg should be engineerable 534 and the possible loss of keepalive msg could be used for the monitoring 535 and measurements of the concerned M3UA nodes. 537 3.2 MTP lvl2 User Adaptation layer(M2UA) 539 3.2.1 Link and application redudancy 541 Link reduncancy is accomplished via multihoming in SCTP itself. You have 542 multiple links towards your DPC. Application redundancy is handled in 543 the user adapatation layers via switching over from one association to 544 another association. 546 3.3 ISDN User Adaptation layer(IUA) 548 Draft Signalling Transport over SCTP applicability statementJuly 2000 550 /* editors note: work in progress */ 552 2 Addressing and signalling over IP infrastructure 554 One of the basic problems in any network is to get from point A to point 555 B. Another problem is how to chosse between different point B. The first 556 problem is solved via SCTP associations(you put the msg in SCTP at one 557 end, and voila, it pos out at the other end). The second problem is 558 solved via addressing. Some signalling is point-to-point, meaning that 559 it simply needs a SCTP association to get to the other side(UIA, M2UA is 560 a case in point). Other Signalling needs to route based on its address- 561 ing contained in the message(M3UA, SUA). 563 2.1 Internet addressing 565 Every layer needs to determine the service to which it wants to deliver 566 its information. The way in which this is done depends from layer to 567 layer. The transport protocols above the IP network protocol are indi- 568 cated in the protocol extension headers field contained at the end of 569 the IP header. Every protocol has its own standardized protocol number. 571 The transport layer determines the application to which it wants to 572 deliver the information by the portnumber. 574 The tuple destination address and portnumber uniqely identifies a appli- 575 cation in the internet. Further selectors may be used in higher layers 576 to obtain the desired application. The IP address itself is a pointcode. 577 The following types of pointcode may de distinguished : 579 - Unicast address: a unicast address designates a single node 580 within a IP network. It can have some hierarchy in it or not. The 581 address may be globally unique or be a private pointcode. 583 - Multicast address: the message is send to all nodes 584 belonging/attached to that multicast address/group.( Similar prin- 585 ciple as with SCCP broadcast but different implementation) 587 - Link-local address: these are addresses assigned to the link(wow 588 local "private"). 590 - Site-local address: these are addresses assigned to a site(wow 591 local, "private") 593 - ... 595 Draft Signalling Transport over SCTP applicability statementJuly 2000 597 As the meaning of the pointcodes is only known to IP and it has a rela- 598 tion to the link and its interface to the link, layers which only know 599 about destinations(such as SCCP), SHOULD NOT/MUST NOT try to to inter- 600 prete the IP address. 602 The IP pointcode does not strictly identify the node in the network but 603 rather the interface to the IP network layer. Thus IP nodes can have 604 more than 1 Pointcode(and those PC can be used for having 2 links 605 between 2 adjacend nodes, a feature that is called multihoming ). 607 2.2 SS7 addressing 609 SS7 was develop in stages: ISUP and MTP were first developped. The deci- 610 sion to route was done by the application in a similar way as the 611 MFC/... signalling determined the trunk to the next exchange. ISUP had 612 to determine for a certain E164 number a DPC(= the pointcode of the 613 adjacend exchange) and then the msg was routed to the office where the 614 same procedure was done over all again.(=link-by- link routing) 616 (1) MTP addres: MTP routing label consists of a Network indicator(also 617 called A MTP-SAP=service acces point) , a destination 618 Pointcode(=DPC) and a origination Pointcode(OPC). The MTP-SAP indi- 619 cates for which network the pointcode in the routing label is 620 valid. If the routing table has been engineerd in a node for that 621 network, the message can reach that destination. The size of a 622 pointcode is fixed within a single network. Different networks can 623 have different sizes of pointcodes: 625 - ITU 14 bit 627 - China 24 bit 629 - ANSI 24 bit 631 - Others..... 633 A MTP pointcode is private to its own network. The global unique- 634 ness is NEVER assured by the MTP pointcode but by global titles(as 635 used in SCCP and in ISUP). 637 The representation of pointcodes can be diverse: decimal, 3-4-3-4 638 format, 8-8-8 format .... It is allowed to structure the 639 pointcode(akind to CIDR and its prefixes in IP). 641 MTP uses static routing: no routing protocols like RIP, OSPF or BGP 642 are used for finding out routes between nodes in a MTP network. 644 Draft Signalling Transport over SCTP applicability statementJuly 2000 646 However it is allowed to use dynamic routing in a MTP net. The ITU 647 marked this as "For Further study", but they never got around to 648 it. 650 (2) SCCP adress : The SCCP address is a variable length address build 651 as a collection of optional elements. It identifies destinations 652 and has no notion about routes to those destinations. That is left 653 to the underlying network layer(MTP or IP). A destination can be a 654 network, node ,application entity, a person... Routing is static. 655 The SCCP address is generally refered to as a Global title. The 656 global title must be globally unique(at least on a world scale) as 657 this allows the A-party to reach the B-party End-to-End without 658 setting up a connection through the network. It can also be used 659 for Link-by-link routing. 661 The function responsible for deriving a pointcode from a global 662 title is (not surprisingly) called the global title translation 663 function(GTT). The GTT is a local function which bases it transla- 664 tion and routing decision on the local situation(translation rule, 665 loadsharing of destinations, route to backup node...) It has no 666 topological knowledge of the network(something MTP and certainly IP 667 have). The GTT function can therefore not only be used by msg with 668 SCCP address but also by Q931 or other signaling messages for find- 669 ing out to which destination the message must be sent. 671 The elements of the Global Title consists of the following: 673 - MTP pointcode AND Network indicator(=MTP-SAP). The network 674 indicator indicates to which network the msg belongs. 676 - Subsystem Number: indicates to which application the msg 677 belongs. 679 - Global title: a structure indicating a global identification 680 of a node and/or application. A GT may occur in the SCCP 681 Calling(=Originator address) and in the Called(Destination 682 address) Party address. 684 If only a MTP pointcode, network indicator and SSN is present, then 685 the message can only be routed within that particular MTP network. 686 If a global title(meaning if translation type, nature of addres 687 and/or Digits) is present (accompanied possibly by a MTP pointcode, 688 network indicator and SSN), then the msg can be routed across mul- 689 tiple MTP networks, provided the networks are interconnected and 690 the destination is reachable. 692 Draft Signalling Transport over SCTP applicability statementJuly 2000 694 (3) Global Title and Global Title Translations: 696 A global title contains the following elements. They are nearly all 697 optional, the occurrence of the field in the SCCP message itself is 698 governed by the global title format field(GTI) in the message. 700 -Translation Type(TTN): should indicate what sort of transla- 701 tion is needed. The most used TTN is the UNKNOWN. In the US 702 some of the TTN have been used to address the 703 application(instead of the SSN), thus doubling as application 704 entity selectors. The Translation Type Number has no counter- 705 part in IP. 707 - Numbering plan(NP): this contains the numbering plan indica- 708 tion to which the rest of the address conforms. This may be 709 the E164, E212, E211, private numbering plans, .... The 710 Numbering plan indication has no explicit counterpart in IP. 711 It is implicitly included in the IPv4 address and partly 712 explicitly included in the IPv6(example : E164 numbers 713 included in OSI-NSAP address in IPv6) 715 - Nature-of-address(NA): this indicates the national or inter- 716 national use of the address. The Nature-of-Address has no 717 counterpart in IP. This could be interpreted as scope indica- 718 tion of the address, something that is explicitly present in 719 Ipv6 pointcodes(Link local, site local...). 721 - Encoding scheme(ES): this is a implicit parameter used to 722 indicate the format of the global title digits(BCD even or BCD 723 uneven). The Encoding scheme has no counterpart in IP. 725 - Global title digits: digits in the format specified by the 726 encoding scheme. They contain the global identification of 727 node(and possibly also of the application within that node.) 728 Also the number of digits is included(as GT is a variable 729 length address. 731 - Subsystem Number(SSN): indicates the application entity 732 which should be reached . Some of the SSN are universally 733 defined while others are not. Some are even double used. The 734 SSN corresponds roughly to the portnumber of IP. However SSNs 735 are derived at the network layer and go straight through to 736 the application layer. Portnumbers only obtain their visibil- 737 ity from the transportlayer. 739 - Global title format: indicates which of the field mentioned 740 above are explicitly contained in the called or calling party 741 address of the message. Some formats indicates that some 743 Draft Signalling Transport over SCTP applicability statementJuly 2000 745 fields(like NA and NP) are specified implicitly. 747 Global title have no explicit counterpart in IP. IP addresses are 748 implicitly assumed to be Global (NAT not included). A GT could also 749 be a name(such as in Directory Naming service (DNS)). 751 Also some routing information is included in the calling/called 752 party address. 754 - routing Indicator: indicates to the node processing 755 calling/called party address how to route the message on. The 756 message can be routed on the Pointcode (and SSN: applicable 757 only in the final end-node) or on global title(this requires a 758 translation).The routing indicator has no counterpart in IP. 760 Depending on the routing indicator the message will be routed by 761 SCCP. If route-on-SPC then MTP will do the routing. If route-on-GT 762 then the SCCP global Title translation function will be invoked to 763 determine the next(possible final or intermediate) node of the mes- 764 sage. The address will be examined on the TTN,NP,NA and Digits and 765 a translation will be done yielding a MTP pointcode + network indi- 766 cator. A SSN may also be the additional outcome of the Global Title 767 Translation(GTT). This MTP address is then used by MTP to route to 768 the next destination(intermediate or final). 770 If required, the TTN, NP, NA, SSN and possible all the digits may 771 be transformed into a TTN', NP' , NA' , SSN' and digits'. It will 772 change the address (if the routing policy prescribes it) in a 773 effort to reach the final destination. The only rule to which it 774 has to adhere is that the change in addresses must be so that the 775 return message(from the B-party) must reach the originator of the 776 start msg(=A-party). This means that the message routing is NOT 777 symmetric. Global title translation conforms to the notion of a 778 Store-Compute-and-Forward network as opposed to a IP network which 779 is a Store-and-Forward network. This translation is completely 780 stateless(we are routing unitdata messages). The same function can 781 also be invoked for connections(see SCCP connection-oriented) then 782 the translation is done only once at the connection setup phase and 783 SCCP connection oriented will then contain the state. 785 The translation rules for digits consist of: 787 - Deleting digits. 789 - Inserting digits 791 - Replacing digits 793 Draft Signalling Transport over SCTP applicability statementJuly 2000 795 - Copying digits 797 That means that your called party address may have completely 798 changed once it went through the GTT and at the same time the cal- 799 ling party address must also be changed to adhere to the rule that 800 the backward message MUST be routable so that a end-to-end dialogue 801 may be send up between 2 nodes. 803 2.3 How to reach applications in SS7 805 Every layer needs to determine the service access point to which it 806 wants to deliver its information. The basic element in SS7 to determine 807 this is the Subsystem Number(SSN for short). the SSN can be found in MTP 808 and SCCP. The MTP has a SSN which indicates along others ISUP, SCCP 809 ,..etc... The SSN in MTP are standardized on international level. 810 Locally defined SSN are allowed but may not be used outside that net- 811 work. 813 The SSN used in SCCP indicates directly to which application the message 814 must be send to. These SSN may be standardized but that is not a 815 prerequisite(see Q715). Some applications have standardized SSN, while 816 others use(and sometimes reuse) not standardized SSN. When messages go 817 from a net with SSN1 to a net with SSN2(SSN1 and SSN2 indicate the same 818 protocol) global title translation must be invoke to convert the SSN's. 819 This is one of the most basic and simplest use of Global Title transla- 820 tion in SS7. 822 2.3.1 General SS7-over-IP architecture. 824 Examples of usage for SS7-over-IP include: 826 - terminating call-related and non-callrelated signalling to a 827 Media gatway Controller(MGC). (PSTN to IP) 829 - Transparant transport of signalling information accross a 830 intranet or internet infrastructure between 2 intermediate SS7 831 nodes.(PSTN-IP-PSTN) 833 - Originating call-related and non-callrelated signalling from the 834 SS7-over-IP net to the PSTN.(IP to PSTN) 836 - SS7-over-IP to SS7-over-IP networks (IP-PSTN-IP or IP-IP). 838 Draft Signalling Transport over SCTP applicability statementJuly 2000 840 The general architecture is decribed in [RFC2719]. 842 3 SS7 Signalling transport using SCTP 844 SS7 messages are transported across IP using the Stream Control 845 Transmission Protocol(SCTP). SCTP provides a high relialable, redundant 846 transport between 2 SS7-over-IP nodes. A SS7-over IP node is a SCTP end- 847 point. 849 The interface with SS7 is message based. Therefore a adaptationlayer is 850 needed to prevent changes to the upper layer SS7 protocols. 852 Within a asociation between 2 endpoint, 1 or more stream(s) may be avi- 853 alable. These streams are not directly visible to the adaptation layers. 855 The linkset towards a certain destination is the collection of all the 856 links which can send trfaffic to that destination, even with a inter- 857 mediate node in between(so different path towards that destination 858 exsist). The MTP linkset is thus equivalent to the SCTP association. The 859 streams within SCTP may be regarded as the links. A advantage of SCTP 860 streams is, when one of the multihomed paths fails, the stream will 861 migrate to one of the still open paths(Soft changeover). In SS7 when a 862 link fails, a a change over procedure has to be initiated towards a 863 still working link of the same linkset(=hard changeover)). 865 In a MTP based network, the capacity of the links is fixed at n times 866 64Kb (with n= 1,32,...). SCTP association do not have a fixed capacity 867 assigned to them. The bandwith used/provided by SCTP is dependant on 868 the rest of the traffic(other SCTP, TCP, RTP,UDP...) going through the 869 same links of the path followed by the SCTP association. See also the 870 SCTP applicability statement[17]. 872 3.1 MTP lvl 2 user adaptation layer(M2UA) 874 The MTP lvl 2 user adaptation layer provides a emulation of a single MTP 875 link between 2 SS7 nodes. 877 3.2 MTP lvl 3 User adaptation layer(M3UA) 879 The MTP lvl 3 user adaptation layer provides a emulation of MTP lvl 3 880 towards its users. Its function is address translation and mapping, 881 stream mapping, congestion control and network management. 883 Draft Signalling Transport over SCTP applicability statementJuly 2000 885 3.2.1 Address Mapping 887 The M3UA layer has to handle at least one or more SCTP associations. The 888 selection of a SCTP association can be done by via a single part or mul- 889 tiple parts of the DPC, OPC, SLS, CIC fields of the MTP routing label. 890 If a association were to fail then alternate mappings may be done 891 (Implementation dependant). 893 3.2.2 Network Management 895 Management messages are exchanged between the M3UA peers for exchanging 896 and updating the status of the SS7-over-IP nodes. 898 Influence of the IP routing protocols on M3UA routing and SCCP routing. 899 Intradomain vs Interdomain 901 - RIP 903 - OSPF 905 - BGMP 907 3.2.3 Network Maintenance 909 3.2.4 Multihoming within SCTP 911 Multihoming in SCTP is the process by where an SCTP endpoint has several 912 transport addresses, which consist of an IP address and a UDP port pair, 913 on which to send and receive on. 915 Multihoming provides redundant communication in SCTP by allowing commun- 916 ication between two endpoints to continue in the event of failure along 917 a path between the endpoints. 919 Under the assumption that every IP address/UDP port will have a dif- 920 ferent path towards the remote endpoint, (this is the responsability of 921 the routing protocols or of manual configuration), if the transport to 922 one of the IP address/port (= 1 particular path) fails then the traffic 923 can migrate to the other remaining IP address/ports(= other paths). 925 Multihoming could also be used for sharing the traffic load across the 926 different paths. However as the througput of any of the paths is not 927 known in advance and constantly changes due to the actions of other 929 Draft Signalling Transport over SCTP applicability statementJuly 2000 931 associations and transport protocols along that particular path, this 932 would require very tight feedback of the paths to the loadsharing func- 933 tions of the adaptation layer. 935 3.2.5 Congestion control & avoidance 937 2 levels of congestion control/avoidance are present in a SS7-over-IP 938 net. 940 - congestion control/avoidance within SCTP 942 - Congestion control/avoidance present in the layers above the 943 user adaptation layers( example: SCCP, ISUP ...) 945 For a more indepth description of congestion , see the SCTP applicabil- 946 ity statement[1]. 948 SCTP conforms to the model of end-to-end congestion control located in 949 the transport leyer while ISUP and SCCP model themselves on a link and 950 destination based congestion control/overload mechanism located in the 951 network layer. 953 5.0 Routing of SS7 message in a IP net. 955 As the signalling is in fact transported over a "SS7" overlay network on 956 top of IP, both SS7 pointcodes and IP pointcodes are used. The basic 957 routing in the overlay network is done using SS7 pointcodes. However at 958 a certain point, that SS7 pointcode must be mapped to a IP pointcode 959 because (1) SCTP uses the IP pointcode(+portnumber) for selecting the 960 correct association and (2) IP routes only on IP pointcodes. 962 The way in way this mapping can be done, could be static or dynamic. 963 This is dependant on what adaptation layer is used and also on the sort 965 Draft Signalling Transport over SCTP applicability statementJuly 2000 967 of network architecture(redundant servers, associations...). 969 /* editors note: work in progress */ 971 5.1 Routing using globally assigned IP addresses. 973 /* editors note: This section might address a problem in SS7 of shor- 974 tage of pointcodes in certain SS7 nets, notably the international 975 (INAT0) SS7 network) */ 977 IP addresses are required to be globally unique. If SS7 wants to tran- 978 sport its messages over a IP network, then they should be treated as 979 global addresses. This means that SS7 shall look at them as global 980 titles, it shall NOT rely on the specific handling of the addresses by 981 the underlying IP layer and below. This also means that SCCP is a prere- 982 quisite for transporting message over a IP infrastructure when non-call 983 related messages are to be transported over IP. ISUP and other signaling 984 protocols will have to the same for call related messages , translating 985 the addresses it has in the adaptation layers to IP addresses. They can 986 all invoke the GTT function if wanted. 988 The following cases may be envisioned: 990 - E164,E212, (=telephone numbers) to IP address(depending on 991 the underlying network Ipv4 or Ipv6) (equivalent to transla- 992 tion MTP 14bit, 24bit ...) 994 - IP address to IP address - IP address to MTP address 996 - IP address to a form of a telephone address (=E164*) : 997 needed if the message transit from a IP net to a IP net via a 998 couple of MTP nets. 1000 As some forms of IP addresses have a very limited scope(such as 1001 link-local and site local), they should better not be used. 1003 The following poitncodes can be used: 1005 - IPv4 unicast : Globally assigned - IPv4 multicast: Globaly 1006 assigned, very few avialable Note 1. 1008 - IPv6 unicast : 1010 - IPv6 multicast: Note 1 1012 - IPv6 anycast: 1014 Draft Signalling Transport over SCTP applicability statementJuly 2000 1016 - IPv6 link-local: 1018 - IPv6 site-local: 1020 Note 1: A word of care is advised when using multicast addresses. 1021 This is especially true if the routing indicator in SCCP is Route- 1022 on-GT. SCCP has no knowledge whether the translation yielded a uni- 1023 cast or multicast PC, so it cannot and it will not take action to 1024 relay or stop the message. The use of this form of address is 1025 dependant on the application in question. 1027 Note 2 1029 Implications of this are that GTT function could support IP 1030 pointcodes. The IP pointcode must be put in the digit block of the 1031 GT. The representation may be in BCD, the meaning of it should not. 1032 The length of a Ipv4 address(32bits) should then be 8 digits(always 1033 fixed). The length of a Ipv6 address(128bits) should be 32 digits. 1034 The GT number of digits in the SCCP header should allow for at 1035 least 32 digits(some extra digits may need to be inserted for 1036 proper routing). The result attached to a certain translation must 1037 be or a MTP PC(14,24) or a Ipv4 PC or a Ipv6 PC. The nature of 1038 address may be defined as indicating a international address with 1039 bitmap format. This could even lead to a new GTT operation (besides 1040 insert, copy, delete, replace) called bitmapPCCopy. The bit- 1041 mapPCcopy takes the IPvx poitncode out of the GT and uses it as the 1042 resulting pointcode of the GTT for further routing. The same effect 1043 can also be achieved via proper engineering of the GT database. 1045 Other possibilities include User adaptation layers which maps the 1046 MTP pointcode to IP pointcode or a mapping from MTP pointcode to a 1047 certain SCTP session. 1049 If GTT is used then IP must need a Numbering plan indicator(NP 1050 value normally assigned by SG11). This may or may not be agreed 1051 with SG11. This is not mandatory(but it is encouraged) as already 1052 there exists private numbering plans not known to SG11. As long as 1053 you make sure at the network border via GTT that the next network 1054 will be able to route the message NP , you can do pretty much any- 1055 thing. This is a bilateral agreement between operators/Internet 1056 Service providers) In general any value may be used as long as it 1057 is routable in your own subnet and that you or somebody else is 1058 able to route it further over its own net. 1060 Also maybe the portnumber may become part of the input/output to 1061 the GTT function. 1063 Draft Signalling Transport over SCTP applicability statementJuly 2000 1065 (1) IPv4 Considerations 1067 When coding a Ipv4 address, the length of the address (32 bits) 1068 should then be 8 digits(always fixed). The GT number of digits in 1069 the SCCP header should allow for at least 32 digits (some extra 1070 digits may need to be inserted for proper routing). The result 1071 attached to a certain translation must be or a MTP PC(14,24) or a 1072 Ipv4 PC or a Ipv6 PC. 1074 (2) IPv6 Considerations 1076 When coding a IPv6, the length of the address (128 bits) should be 1077 32 digits. The GT number of digits in the SCCP header should allow 1078 for at least 32 digits (some extra digits may need to be inserted 1079 for proper routing). The result attached to a certain translation 1080 must be or a MTP PC(14,24) or a Ipv4 PC or a Ipv6 PC. 1082 (3) Routing SS7 messages and dynamic assigned adresses 1084 Problems may occur with dynamically assigned IP addresses. The node 1085 could obtain a IP address that is later reclaimed and/or replaced 1086 by another IP address out of a pool of IP addresses. The destina- 1087 tion address in the routing tables would have to be invalidated or 1088 changed. Therefore it is strongly recommended to use a fixed 1089 assigned IP address. Do not forget that the IP node which is work- 1090 ing in the SS7 net is supposed to be up all the time. It should not 1091 be regarded as a dial-up user(for which Dynamic assigned addresses 1092 are meant). 1094 Also, dynamically assigned address may invalidate security features 1095 of SCTP. If transport addresses may change during the lifetime of 1096 a SCTP association, it is impossible to reliably ensure that the 1097 current transport address is the transport address which was used 1098 in the setup of the association. 1100 If this practice should turn out to be unavoidable, then a Q3/SNMP 1101 Management msg would be required to be exchanged between DHCP and 1102 SCCP network element configuration part so that the pointcode 1103 attached to a certain GT must be updated, deleted or added. The 1104 same solution is also feasible for working in NAT's with dynamical 1105 assigned addresses. 1107 (4) Routing SS7 message and Network address Translators. 1109 Network Address Translator(NAT) are boxes which map a private IP 1111 Draft Signalling Transport over SCTP applicability statementJuly 2000 1113 net address to a globally assigned IP address. This happens because 1114 there are many more users within the private IP net than there a 1115 globally assigned IP addresses allocated to that private IP net. 1116 That means that the mapping is ALWAYS dynamic. The mapping must be 1117 both ways and via the same NAT and the NAT is always the final des- 1118 tination. Also the association is based on state(thus breaking the 1119 end-to-end principle). This amounts to crossing a network border. 1120 It should be envisioned to use a static private address in the NAT. 1122 It would be advisiable to termination the association from the pub- 1123 lic network at the NAT, and have separate association(s) within the 1124 private network. Then there is a clear network border at the cross- 1125 ing between the NAT and that internet. 1127 Endpoint Endpoint Endpoint 1128 A(NAT) B (NAT) C 1129 +------+ +------+ +----+ 1130 | ISEP |----------| SG |----------| SG |--- 1131 +------+ +------+ +----+ 1132 association 1 ! association 2 ! 1133 ! ! 1134 NAT ! internet ! PSTN 1135 ! ! 1137 Fig 5.x: use of SCTP associations with NAT's 1139 Another solution is the use of name option for setting up the SCTP 1140 association. 1142 (5) Routing SS7 messages and routing protocols 1144 The term routing protocols has a much broader sense in the Internet 1145 than in the SS7 world. SS7 designates such protocols as Management 1146 protocols(SCCP management, MTP management...) The scope of SS7 1147 management protocols is much smaller. They only exchange informa- 1148 tions of links in service and nodes in service(mostly only the own 1149 links and the adjacend nodes) The topology of the network is NOT 1150 exchanged between SS7 nodes. In general most nodes haven't got the 1151 faintest idea how even the topology of its own subnet may look 1152 like.(and they don't care). 1154 The interaction between IP routing protocols and SS7 routing may 1155 require some study especially in the case that routes start chang- 1156 ing due to routing recomputation. The loadsharing and 1157 primary/backup systems of GTT seems not to be impacted as it relies 1158 on destinations and not on links. As long as a destination is 1159 accessible/avialable in the IP net, then messages may be send to 1161 Draft Signalling Transport over SCTP applicability statementJuly 2000 1163 it. If the destination is no longer avialable, then GTT must per- 1164 form according to its own rules. Beware of changing conditions 1165 being triggered by routing updates. 1167 (6) Routing SS7 messages and automatic renumbering 1169 Automatic renumbering is the process of changing the IP addresses 1170 of one or more nodes in a network so that the prefix of the address 1171 (which is then common for all the changed nodes) allows to have a 1172 routing table with a reduced number of entries. This renumbering is 1173 mainly of interest in IPv6 networks. 1175 If this happens, a similar solution(management request of the GT 1176 tree) should be used to change the pointcode derived from GT. 1178 6.0 Security 1180 The following aspects of security are : 1182 Authentication: 1184 Information is sent/received from a known and/or trusted partner. 1185 Until recently the number of interconnects of a SS7 node with 1186 another SS7 node belonging to another operator was relativily lim- 1187 ited and those other operators were implicitly known (and sometimes 1188 trusted). Due to the increasing interconnect demands between dif- 1189 ferent operators on a voluntary or mandatory basis, the trusted 1190 relation does not longer exist. That mean that a operator will not 1191 accept all SS7 msg send to him by another operator. This is done 1192 using MTP and SCCP screening: depending on the inormation in the 1193 different MTP fields(example OPC...) and/or SCCP fields(example 1194 Calling party address, SSN...) a msg may be rejected or accepted 1195 for transport across or termination into the network. In the worst 1196 case it may try to screen up to the application level(example: the 1197 user info in a IAM msg or in a TC INVOKE component, Application 1198 Context name screening). See [16]. 1200 A SS7 gateway using screening does behave like a firewall. 1202 Intergrity: 1204 Information may not be modified while in transit. The integrity of 1205 a msg in a public network is not guaranteed. If it is transported 1207 Draft Signalling Transport over SCTP applicability statementJuly 2000 1209 over a IP network the integrity may be guaranteed at 2 levels. (1) 1210 the IP level using IPSEC: which is equivalent to providing 1211 integrity on on SS7 link level basis. Keydistribution is at most 1212 limited to the network of that operator. (2) End-To-End integrity 1213 using TCAP: For further study in the ITU. 1215 Confidentiality: 1217 Confidentiality of the user data must be ensured. User data can 1218 not be examined by unauthorized users. 1220 Availability: 1222 The communicating endpoint must remain in service in all circon- 1223 stances. All SS7 nodes have to remain active for the 99.999% of the 1224 time. 1226 The description of the internet security architecture and the use of it 1227 is described in [18]. 1229 10 References and related work 1231 [SCTP] Stewart, R. R., Xie, Q., Morneault, K., Sharp, C. , , 1232 Schwarzbauer, H. J., Taylor, T., Rytina, I., Kalla, M., Zhang, L. 1233 and Paxson, V."Stream Control Transmission Protocol", , April 2000. Work In Progress. 1236 [Q1400] SG11, ITU-T Recommendation Q.1400, " architecture framework for 1237 the development of signaling and OA&M protocols using OSI concepts 1238 ",1993 1240 [RFC2719] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 1241 Lin, H., Juhasz, I., Holdrege, M., Sharp, C., "Framework Architec- 1242 ture for Signaling Transport", RFC2719, October 1999 1244 [IANA] Internet Assigned Numbers Authority, http://www.iana.org/, April 1245 2000 1247 Draft Signalling Transport over SCTP applicability statementJuly 2000 1249 [RFC814] Clark, D.D., "Names, addresses, ports and routes", RFC 0814, 1250 July 1982. 1252 [M2UA] Morneault, K., Kalla, M., Sidebottom, G., Dantu, R., George, T., 1253 "SS7 MTP2-User Adaptation Layer (M2UA)", ,Work in progress 1256 [M3UA] Sidebottom,G., Ong, L., Mousseau, G., Rytina, I., Schwarzbauer, 1257 HJ., Morneault, K., Kalla, M., "SS7 MTP3-User Adaptation Layer 1258 (M3UA)", ,Work in progress 1260 [IUA] Kalla, M., Rengasami, S., Morneault, K., Sidebottom, G. "ISDN 1261 Q.921-User Adaptation Layer(IUA)", 1262 ,Work in progress 1264 [RFCSCTPAS] Coene, L., Loughney, J., Rytina, I., Ong, L., "Stream Con- 1265 trol Transmission Protocol Applicability Statement", , Work in progress 1268 [Q700] ITU-T Recommendation Q.700, "Introduction to CCITT Signaling Sys- 1269 tem No.7", March, 1993 1271 [Q70X] ITU-T Recommendation Q.701-705, "Message Transfer part No. 7", 1272 1996 1274 [Q71X] ITU-T Recommendation Q.710-715, "Signaling Connection Control 1275 Part No. 7", 1996 1277 [Q77x] ITU-T Recommendation Q.770-775, "Transaction Capabilities Appli- 1278 cation Part No. 7", 1996 1280 [Q1400] ITU-T Recommendation Q.1400, " architecture framework for the 1281 development of signaling and OA&M protocols using OSI concepts 1282 ",1993 1284 [RFC1035] Mockapetris, P., "Domain Names, Implementation and specifica- 1285 tion", RFC1035, November 1987 1287 Draft Signalling Transport over SCTP applicability statementJuly 2000 1289 11 Author's Address 1291 Lode Coene 1292 Siemens Atea 1293 Atealaan 34 1294 B-2200 Herentals 1295 Belgium 1297 Phone: +32-14-252081 1298 EMail: lode.coene@siemens.atea.be 1300 John Loughney 1301 Nokia 1302 Research centre 1303 Itamerenkatu 11-13 1304 FIN-00180 Helsinki 1305 Finland 1307 Phone: +358-9-43761 1308 EMail: john.loughney@nokia.com 1310 Ian Rytina 1311 Ericsson Australia 1312 37/360 Elizabeth Street 1313 Melbourne, Victoria 3000 1314 Australia 1316 Phone : - 1317 EMail:ian.rytina@ericsson.com 1319 Lyndon Ong 1320 Nortel Networks 1321 4401 Great America Parkway 1322 Santa Clara, CA 95054 1323 USA 1325 Phone: - 1326 EMail: long@nortelnetworks.com 1328 Expires: December 2000 1330 Full Copyright Statement 1332 Copyright (C) The Internet Society (2000). All Rights Reserved. 1334 Draft Signalling Transport over SCTP applicability statementJuly 2000 1336 This document and translations of it may be copied and furnished 1337 to others, and derivative works that comment on or otherwise 1338 explain it or assist in its implementation may be prepared, 1339 copied, published and distributed, in whole or in part, without 1340 restriction of any kind, provided that the above copyright notice 1341 and this paragraph are included on all such copies and derivative 1342 works. However, this document itself may not be modified in any 1343 way, such as by removing the copyright notice or references to the 1344 Internet Society or other Internet organizations, except as needed 1345 for the purpose of developing Internet standards in which case the 1346 procedures for copyrights defined in the Internet Standards 1347 process must be followed, or as required to translate it into 1348 languages other than English. 1350 The limited permissions granted above are perpetual and will not 1351 be revoked by the Internet Society or its successors or assigns. 1353 This document and the information contained herein is provided on 1354 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1355 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1356 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1357 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1358 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.