idnits 2.17.1 draft-ietf-sigtran-itun-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1063 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 37 instances of too long lines in the document, the longest one being 337 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 458 has weird spacing: '... SG has deter...' == Line 847 has weird spacing: '... decide to re...' -- 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.) -- The document date (18 June 1999) is 9072 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 886, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Normative reference to a draft: ref. '5' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Sidebottom, L. Ong 2 INTERNET-DRAFT Nortel Networks 3 Ian Rytina 4 Ericsson 5 Hanns-Juergen Schwarzbauer 6 Siemens 8 Expires in six months 18 June 1999 10 SS7 ISUP Tunneling 11 13 Status of This Memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC 2026. 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 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 To learn the current status of any Internet-Draft, please check the 33 '1id-abstracts.txt' listing contained in the Internet- Drafts Shadow 34 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 35 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 36 ftp.isi.edu (US West Coast). 38 Abstract 40 This Internet Draft defines a protocol for tunneling of SS7 41 signaling over IP using the Sigtran Common Transport Protocol. This 42 protocol would be used between a Signaling Gateway (SG) and Media 43 Gateway Controller (MGC) but could also be used between two SGs 44 if desired. It is assumed that the SG receives SS7 signaling 45 over a standard SS7 interface using the SS7 Message Transfer Part 46 (MTP) to provide transport. 48 1 49 TABLE OF CONTENTS 51 1. Introduction..............................................3 52 2. Protocol Elements.........................................8 53 3. Procedures...............................................17 54 4. References...............................................19 55 5. Author's Addresses.......................................19 57 2 58 1. Introduction 60 1.1 Scope 62 There is a need for SCN signaling protocol delivery from an SS7 Signaling Gateway (SG) to a Media Gateway Controller (MGC). The 63 delivery mechanism should meet the following criteria: 64 * Support for SS7 MTP-User Part protocols 65 * Support for the MTP-User service interface 66 * Support for a request/response mechanism to open and close the 67 transport associations between SG and MGC 68 * Support for the asynchronous reporting of any status changes of the signalling channel 70 1.2 Signaling Transport Architecture 72 The architecture that has been defined for SCN signaling transport 73 over IP uses multiple components, including an IP transport 74 protocol, a signaling common transport protocol and an adaptation 75 module to support the functions expected by a particular SCN signaling 76 protocol from its underlying protocol layer. 78 This document defines an adaptation module that is suitable for the 79 transport of SS7 ISDN User Part (ISUP) but could be used equally to 80 transport other SS7 MTP-3 User Parts such as, for example, SCCP (together with its subsystems e.g., INAP/TC and TUP. 82 The figure below shows how the SS7 Gateway Module fits within the 83 Sigtran architecture. 85 +-------------------------------+ 86 | | 87 | SS7 ISUP | 88 +-------------------------------+ 89 | ITUN | 90 | Adaptation Module | 91 |-------------------------------| 92 | Signaling Common Transport | 93 |-------------------------------| 94 | IP Transport | 95 +-------------------------------+ 97 In a Signaling Gateway, it is expected that the SS7 ISUP signaling 98 is received over a standard SS7 network termination, using the SS7 99 Message Transfer Part (MTP) to provide transport of ISUP signaling 100 messages to and from an SS7 Signaling End Point (SEP). The 101 SG then provides interworking of transport functions with 102 IP Signaling Transport, in order to transport the ISUP signaling 103 messages to the MGC where the peer ISUP protocol layer exists, as 104 shown below: 106 3 107 ****** SS7 ****** IP ******* 108 *SEP *---------* SG *------------* MGC * 109 ****** ****** ******* 111 +----+ +-----+ 112 |ISUP| | ISUP| 113 +----+ +---------+ +-----+ 114 |MTP | |MTP |ITUN| | ITUN| 115 |L3 | |L3 +----+ +-----+ 116 |L2 | |L2 |SCTP| | SCTP| 117 |L1 | |L1 +----+ +-----+ 118 | | | |U/T | | U/T | 119 +----+ +---------+ +-----+ 121 SEP - SS7 Signaling Endpoint 122 U/T - UDP/TCP 123 SCTP - Signaling Common Transport Protocol (aka MDTP [5]) 125 Note: The use of MTP Level 2 signaling links in the SS7 network is shown 126 as an example. ATM-based High Speed Links could also be used, using 127 SSCF/SSCOP [3,4]. Also, STPs may be present in the SS7 path between the 128 SEP and the SG. 130 1.2 Services Provided by the ITUN Layer 132 The SS7 ISUP/MTP (MTP-User) interface is retained at the termination 133 point in the IP network, so that the ITUN protocol layer is required to 134 provide the equivalent set of services to its users as provided by the 135 MTP Level 3. 137 This includes the following services [2]: 139 TRANSFER 141 Providing the ability to transport MTP-User information (in this 142 Case, ISUP PDUs). 144 PAUSE 146 Providing an indication to the MTP-User that the remote MTP-User is not 147 reachable. 149 RESUME 151 Providing an indication to the MTP-User that the remote MTP-User is now 152 reachable. 154 STATUS 156 Providing an indication to the MTP-User that messages to the remote MTP- 157 User are experiencing congestion or other conditions. 159 5 160 1.3 Functions Provided by the ITUN Layer 162 1.3.1 Internal Functions 164 a) Mapping. 166 The ITUN layer maps primitives received from the MTP-User Layer (i.e., 167 ISUP) to the SCTP (MDTP) reliable transport upper layer boundary and 168 maps signals received from the SCTP to the MTP-User lower layer 169 boundary. For example, the MTP-Transfer request primitive received from 170 the MTP-User is mapped to an MDTP-Send.Data primitive and the MDTP- 171 Receive.Data primitive is mapped to an MTP-Transfer indication primitive 172 to the MTP-User. 174 The ITUN layer must additionally maintain a current network address 175 mapping table of relevant SS7 address information to SCTP associations/streams. 176 This is required in order to route the SS7 messages incoming from the 177 SS7 network domain to the appropriate MGC in the IP network domain, or 178 to route SS7 messages originated at an MGC to the appropriate SG. This 179 mapping could be dynamic given the availability status of the individual 180 SCTP associations, configuration changes, and possible MGC fail-over 181 mechanisms. 183 Possible SS7 information to be considered includes, for example, the 184 OPC, DPC, SLS and/or ISUP CIC. The mapping function in effect defines 185 the SS7 address representation of the network elements within the IP 186 domain. As such, the implementation of this function must be flexible 187 enough to handle the SS7 numbering plan vision of network operator(s). 188 For example, some network operators may choose to represent a SG/MGC 189 pair as a SS7 SEP with a single point code. Other operators may choose 190 to represent logical groups of MGCs with point codes. 192 >From the perspective of the ITUN instance at the MGC, it is possible 193 that the MGC could route signaling messages destined to SS7 SEPs through 194 more than one SG. A primary/back-up case is possible where the 195 transport unavailability of a primary SG (or routing unavailability of 196 the SS7 SEP from the primary SG) could be used to reroute to a next- 197 preferred SG). Also, a loadsharing case is possible where the signaling 198 messages are load-shared across two (or more) SGs. 200 b) Flow Control. 202 The ITUN Layer is informed of congestion by means of an implementation- 203 dependent function. Congestion is indicated to local MTP-Users by means 204 of an MTP-Status primitive. 206 c) Reporting to Layer Management. 208 Certain events are reported to Layer management. For example, the ITUN 209 may inform Layer Management of the reason for the release of an SCTP 210 association, determined either locally within the ITUN layer or by a primitive from the SCTP. 212 5 213 d) Change Link Status 215 The ITUN layer maintains local state variables pertaining to the status 216 of the SCTP transport associations. 218 e) Seamless Network Management Interworking. (Ed. Note: It is ffs if 219 this function is in the ITUN layer at an SG or is part of an independent 220 relay function at the SG that is a user of the ITUN layer and MTP-3 221 layer.) 223 The SG must maintain knowledge of the SS7 and IP network management 224 status in the respective domains in order to perform as seamless as 225 possible interworking of the two domains. For example, SG knowledge of 226 the transport availability of the MGCs and SS7 SEPs must be maintained 227 and disseminated in the respective networks so that end-to-end operation is transparent to the communicating ISUP peers at the SS7 SEP and the 228 MGC. 230 Where an SG determines that the transport of SS7 messages to an MGC is 231 encountering congestion, the SG may in some cases issue MTP-3 TFC 232 messages to SS7 SEPs which are generating signalling traffic to the 233 affected MGC, as per current MTP procedures [2]. Triggering of the MTP-3 flow control procedure is an implementation dependent function. 235 1.3.2 Functions with peer-to-peer Messages 237 Some functions performed by the ITUN layer utilize per-to-peer protocol. 239 a) ITUN-User Failure 241 The ITUN layer is informed of a local ITUN-User failure by means of an 242 indication from Layer Management. In response, peer protocol is invoked 243 with the remote ITUN layer to stop traffic in over the SCTP association 244 until recovery of the local ITUN-User. The layer maintains status of 245 the local ITUN-User availability. 247 Also, reception of PDUs from the remote ITUN peer may indicate failure 248 of the remote ITUN-User, causing the function to stop traffic to the 249 remote peer and report an indication of the reason to Layer Management. The ITUN layer at the SG passes this indication to the local MTP-3. 251 b) Management Inhibit/Uninhibit 253 Local Management may wish to stop traffic across an SCTP association in 254 order to temporarily remove the association from service or to perform 255 testing and maintenance activity. The function could optionally be used 256 to manage the start of traffic on to a newly-available SCTP association. 258 c) Active Association Control 260 In some cases, an MGC process can have a back-up MGC process. If a 261 primary and secondary instances are available across different SCTP 262 associations, then peer protocol is required to control which process, 263 6 264 and hence SCTP association, is currently active. The SS7 to IP mapping 265 table is updated to reflect the current MGC process instance currently 266 used. 268 1.4 Definition of the Upper Layer Boundary between ITUN and ISUP 270 >From ITU Q.701 [2]: 272 MTP-Transfer Request 273 MTP-Transfer Indication 274 MTP-Pause Indication 275 MTP-Resume Indication 276 MTP-Status Indication 278 1.5 Definition of the Lower Layer Boundary between ITUN and SCTP 280 Note: the upper layer boundary primitives identified here are from the 281 latest issue of the MDTP draft [5]. Note: These primitives are 282 potentially subject to change, as are any related MDTP and ITUN 283 procedures. 285 MDTP-Init.MDTP 286 MDTP-Init.Association 287 MDTP-Term.Association 288 MDTP-Send.Data 289 MDTP-Receive.Data 290 MDTP-Data.Arrive notification 291 MDTP-Send.Failure notification 292 MDTP-Network.Status.Change notification 293 MDTP-Communication.Up notification 294 MDTP-Communication.Lost notification 295 MDTP-Change.Network.Rotation 296 MDTP-Open.Stream 297 MDTP-Close.Stream 299 (Ed. Note: Are some of these primitives actually between SCTP and the 300 Layer Management (e.g., MDTP-Change.Network.Rotation, MDTP- 301 Init.MDTP,...). If so, they should not be defined in this document.) 303 1.6 Definition of the Boundary between ITUN and the Layer Management 304 (Optional) 306 M-Open request 307 M-Release request 308 M-Local Stop request 309 M-Local Stop confirm 310 M-Remote Stop indication 311 M-Local Resume request 312 M-Remote Resume indication 313 M-Report indication 315 7 316 2.0 Protocol Elements 318 2.1 Message Header 320 The messages passed between the SG and the MGC require a message 321 structure which contains the protocol version, a message type, message 322 length and message contents. The message header includes the protocol 323 version, type and length (ed. Note: Protocol ID req'd? Is length 324 necessary?). 326 The valid message types are defined in Section 2.2.2 and the message 327 contents are described in Section 2.3. The general message format is 328 shown in Figure 1. Each message can contain multiple parameters as 329 indicated in Figure 1 331 0 7 8 15 16 31 332 +---------------+---------------+ 333 | Vrsn | Spare | Msg Type | 334 +-------------------------------+ 335 | Message Length | 336 +---------------+---------------+ 337 | | 338 Parameter 1 339 | | 340 +---------------+---------------+ 341 . . . 342 +---------------+---------------+ 343 | | 344 Parameter n 345 | | 346 +---------------+---------------+ 348 Figure 1: Message Format 350 2.2.1 Protocol Version 352 The supported versions are: 354 01 Release 1.0 protocol 356 If a message with an unknown protocol version is received, the 357 receiving node will respond to the sender with an Path Version 358 message (see Section 2.3.3.3). This will inform the sender that a 359 message with an unsupported version has been received and will 360 indicate to the sender the supported version. 362 8 363 2.2.2 Message Types 365 The following list contains the message types for the defined messages. 367 ISUP Tunneling (ITUN) Messages 369 Transfer Message 0101 371 SS7 Signalling Network Management (SSNM) Messages 373 Destination Unavailable (DUNA) 0201 374 Destination Available (DAVA) 0202 Destination State Audit (DAUD) 0203 375 Destination Partially Available (DPAV) 0204 376 SS7 Network Congestion State (SCON) 0205 377 Destination User Part Unavailable (DUPU) 0206 379 IP Transport Path Availability Management (TPAM) Messages 381 Path-up (PTUP) 0301 382 Path-Down (PTDN) 0302 383 Path Version (PTVR) 0304 385 IP Node Maintenance (IPNM) Messages 387 Node Up (NDUP) 0401 388 Node Down (NDDN) 0402 390 2.2.3 Message Length 392 The Message length defines the length of the message in octets, not 393 including the header. 395 2.3 Message Types 397 The following section defines the message types and parameter contents. 399 2.3.1 ISUP Tunneling (ITUN) Messages 401 2.3.1.1 Transfer Message 403 The Transfer message contains an SS7 MTP-User Protocol Data Unit (PDU). 404 In addition, it may contain information from the MTP 3 routing label in 405 order to distinguish the interface being controlled. The TRANSFER 406 message contains the following parameters: 408 9 409 PROTOCOL IDENTIFIER 410 INTERFACE IDENTIFIER 411 PROTOCOL DATA 413 The format for the Transfer Message parameters is as follows: 414 0 15 16 31 415 +---------------+---------------+ 417 | Protocol Identifier* | 419 +---------------+---------------+ 420 | Interface Identifier | 421 +-------------------------------+ 422 ... 423 | Protocol Data | 424 ... 425 +---------------+---------------+ 427 * The Protocol Identifier format is for further study. The protocol 428 identifier values should be maintained outside of this document to allow 429 addition/deletion of values without re-issuing the adaptation layer 430 protocol document. 432 The Protocol Identifier field contains the identity of the specific 433 SCN signaling protocol being transported. The Protocol ID defines 434 the protocol type, variant, and version, and thereby specifies the 435 components and encoding of the PROTOCOL DATA field. The Protocol 436 Identifier also defines what SCN protocol message components are 437 included in the PROTOCOL DATA (e.g., whether or not the DATA contains the MTP routing label). 439 (Ed. Note: Need encoding of mime-type value or OID or fixed 440 string/integer that will be administered outside of this document 441 (IANA). Also, perhaps bring in text from Christian's mime document - See 442 "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP 443 media type defined according to the rules defined in RFC 2048.?) 445 The Interface Identifier identifies the physical interface, or network at the SG for which the signaling messages are sent/received. The format is for further study, while the values assigned according to network operator policy. This knowledge can be very useful at MGCs that are receiving signaling from multiple national networks and cannot rely on the SS7 NI value to tell their signalling traffic apart. 447 The PROTOCOL DATA field contains the MTP-User application message. As 448 defined for a specific value of the Protocol Identifier, this will 449 include the MTP-User Data and includes the MTP Routing Label (SS7 450 OPC, DPC, SLS), and the SIO (Network Indicator & optional Message 451 Priority Codes). 453 2.3.2 SS7 Signaling Network Management (SSNM) Messages 455 2.3.2.1 Destination Unavailable (DUNA) 457 The DUNA message is sent from the SG to the MGC to indicate that 458 the SG has determined that an SS7 destination is unreachable. The MTP- 459 User at the MGC is expected to stop traffic to the affected destination 460 through the SG initiating the DUNA. 462 10 463 The DUNA message contains the following parameters: 465 Protocol Identifier 466 INFO STRING 467 AFFECTED Destination Point Code 469 The format for DUNA parameter is as follows: 471 0 7 8 15 16 31 472 +---------------+---------------+ 474 | Protocol Identifier* | 476 +---------------+---------------+ 478 |Length | INFO String | 480 . . . 482 + +-------+---------------+ 483 | | Affected DPC* | 484 +---------------+---------------+ 486 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 487 determine the format of the Affected DPC parameter. By identifying the 488 protocol type, variant, and version, the point code size (e.g., 14- or 489 24-bit) and sub-field definitions (e.g., ANSI network/cluster/member, 490 ITU-international zone/region/signal_point, many national field 491 variants, ...) can be determined. 493 The INFO String parameter can carry any meaningful 8-BIT ASCII character 494 string along with the message. Length of the INFO String parameter is 495 from 0 to 255 characters. If an INFO String is not included, a length 496 of "0" is used. 498 The Affected DPC is provisionally a three-octet parameter to allow 14- 499 and 24-bit SS7 formatted SS7 Point Codes. 501 2.3.2.2 Destination Available (DAVA) 503 The DAVA message can be sent from the SG to the MGC to indicate that 504 the SG has determined that an SS7 destination is now reachable. The 505 MGC ISUP is expected to resume traffic to the affected destination 506 through the SG initiating the DUNA. 508 The DAVA message contains the following parameters: 510 Protocol Identifier 511 INFO String 512 AFFECTED Destination Point Code 514 11 515 The format for DAVA parameter is the same as for the DUNA message (See 516 Section 2.3.2.1.) 518 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 519 determine the format of the Affected DPC parameter. By identifying the 520 protocol type, variant, and version, the point code size (e.g., 14- or 521 24-bit) and sub-field definitions (e.g., ANSI network/cluster/member, 522 ITU-international zone/region/signal_point, many national field 523 variants, ...) can be determined. This knowledge can be very useful at 524 MGCs that are receiving signaling from multiple national networks and 525 cannot rely on the SS7 NI value to tell their signalling traffic apart. 527 The INFO String parameter can carry any meaningful 8-BIT ASCII character 528 string along with the message. Length of the INFO String parameter is 529 from 0 to 255 characters. If an INFO String is not included, a length 530 of "0" is used. 532 The Affected DPC is provisionally a three-octet parameter to allow 14- 533 and 24-bit SS7 formatted SS7 Point Codes. 535 2.3.2.3 Destination State Audit (DAUD) 537 The DAUD message can be sent from the MGC to the SG to query the 538 availability state of the route to an affected destination 539 state is unavailable or stale (e.g., the transport path to the SG has 540 been interrupted) 542 Protocol Identifier 543 INFO String 544 Affected Destination Point Code 546 The format for DAUD parameter is the same as for the DUVA message (See 547 Section 2.3.2.1. It is for further study whether multiple Affected 548 Destination Point Codes can be included in one DAUD message. 550 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 551 determine the format of the Affected DPC parameter. By identifying the 552 protocol type, variant, and version, the point code size (e.g., 14- or 553 24-bit) and sub-field definitions (e.g., ANSI network/cluster/member, 554 ITU-international zone/region/signal_point, many national field 555 variants, ...) can be determined. This knowledge can be very useful at 556 MGCs that are receiving signaling from multiple national networks and 557 cannot rely on the SS7 NI value to tell their signalling traffic apart. 558 The INFO String parameter can carry any meaningful 8-BIT ASCII character 559 string along with the message. Length of the INFO String parameter is 560 from 0 to 255 characters. If an INFO String is not included, a length 561 of "0" is used. 563 The Affected DPC is provisionally a three-octet parameter to allow 14- 564 and 24-bit SS7 formatted SS7 Point Codes. 566 12 567 The SG receiving the DAUD should reply with the availability state of 568 the queried destination in a DUNA,DAVA, or DPAV message. 570 2.3.2.4 Destination Partially Available (DPAV) - Optional 572 The Optional DPAV message can be sent from the SG to the MGC to indicate 573 that the SG is using a secondary route to the destination. 575 The DPAV message contains the following parameters: 577 Protocol Identifier INFO String 578 Affected Destination Point Code 580 The format for DPAV parameter is the same as for the DUVA message (See 581 Section 2.3.2.1). 583 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 584 determine the format of the Affected DPC parameter. By identifying the 585 protocol type, variant, and version, the point code size (e.g., 14- or 586 24-bit) and sub-field definitions (e.g., ANSI network/cluster/member, 587 ITU-international zone/region/signal_point, many national field 588 variants, ...) can be determined. This knowledge can be very useful at 589 MGCs that are receiving signaling from multiple national networks and 590 cannot rely on the SS7 NI value to tell their signalling traffic apart. 591 The INFO String parameter can carry any meaningful 8-BIT ASCII character 592 string along with the message. Length of the INFO String parameter is 593 from 0 to 255 characters. If an INFO String is not included, a length 594 of "0" is used. 596 The Affected DPC is provisionally a three-octet parameter to allow 14- 597 and 24-bit SS7 formatted SS7 Point Codes. 599 The MGC receiving the DPAV should, if possible, re-route the affected 600 signalling traffic to an alternate SG, assuming the alternate SG is 601 still using its normal route. 603 2.3.2.5 SS7 Network Congestion (SCON) 605 The SCON message can be sent from the SG to the MGC to indicate that 606 the congestion level in the SS7 network to a specified destination has 607 changed. 609 The SCON message contains the following parameters: 611 Protocol Identifier 612 INFO String 613 AFFECTED Destination Point Code 614 CONGESTION LEVEL 616 The format for optional CONGESTION parameter is as follows: 618 13 619 0 7 8 15 16 31 620 +---------------+---------------+ 622 | Protocol Identifier* | 624 +---------------+---------------+ 626 |Length | INFO String | 628 . . . 630 + +-------+---------------+ 631 | | Affected DPC* | 632 +---------------+---------------+ 633 | Congestion Level | 634 +-------------------------------+ 636 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 637 determine the format of the Affected DPC parameter. By identifying the 638 protocol type, variant, and version, the point code size (e.g., 14- or 639 24-bit) and sub-field definitions (e.g., ANSI network/cluster/member, 640 ITU-international zone/region/signal_point, many national field 641 variants, ...) can be determined. This knowledge can be very useful at 642 MGCs that are receiving signaling from multiple national networks and 643 cannot rely on the SS7 NI value to tell their signalling traffic apart. 645 The INFO String parameter can carry any meaningful 8-BIT ASCII character 646 string along with the message. Length of the INFO String parameter is 647 from 0 to 255 characters. If an INFO String is not included, a length 648 of "0" is used. 650 The Affected DPC is provisionally a three-octet parameter to allow 14- 651 and 24-bit SS7 formatted SS7 Point Codes. 653 The valid values for CONGESTION LEVEL are shown in the following table. 655 Define Value Description 656 Level 0 0000 No Congestion or Undefined 657 Level 1 0001 Congestion Level 1 658 Level 2 0002 Congestion Level 2 659 Level 3 0003 Congestion Level 3 661 The MGC receiving the SCON message is expected to follow the currently 662 defined MTP-User protocol reaction to an indication of network 663 congestion. 665 2.3.2.6 Destination User Part Unavailable (DUPU) 667 The DUPU message is used by a SG to inform an MGC that a remote peer 668 ISUP User Part at an SS7 node is unavailable. 670 14 671 The DUPU message contains the following parameters: 673 Protocol Identifier 674 INFO String 675 AFFECTED Destination Point Code 676 Reason 678 The format for optional DUPU is as follows: 680 0 7 8 15 16 31 681 +---------------+---------------+ 683 | Protocol Identifier* | 685 +---------------+---------------+ 687 |Length | INFO String | 689 . . . 691 + +-------+---------------+ 692 | | Affected DPC* | 693 +---------------+---------------+ 694 | Reason | 695 +-------------------------------+ 697 The Protocol Identifier parameter (see Section 2.3.1.1) is used here to 698 determine the format of the Affected DPC parameter and User Part. By 699 identifying the protocol type, variant, and version, the point code size 700 (e.g., 14- or 24-bit) and sub-field definitions (e.g., ANSI 701 network/cluster/member, ITU-international zone/region/signal_point, many 702 national field variants, ...) can be determined. This knowledge can be 703 very useful at MGCs that are receiving signaling from multiple national 704 networks and cannot rely on the SS7 NI value to tell their signalling 705 traffic apart. 707 The INFO String parameter can carry any meaningful 8-BIT ASCII character 708 string along with the message. Length of the INFO String parameter is 709 from 0 to 255 characters. If an INFO String is not included, a length 710 of "0" is used. 712 The Affected DPC is provisionally a three-octet parameter to allow 14- 713 and 24-bit SS7 formatted SS7 Point Codes. 715 The valid values for Reason are shown in the following table. 717 Define Value Description 718 UPU-Unknown 0x4 MTP User Part Unavailable, No Reason Given 719 UPU-Unequipped 0x5 MTP User Part Unavailable, Unequipped 720 UPU-Inaccessible 0x6 MTP User Part Unavailable, Inaccessible 722 15 723 The MGC receiving the DUPU message is expected to follow the currently 724 defined MTP-User protocol reaction to an indication of remote user part 725 unavailabilty. 727 2.3.3 IP Transport Path Availability Management (TPAM) Messages 729 2.3.3.1 Path-up (PTUP) 731 The PTUP message is used to indicate to a remote ITUN peer that the layer is ready to receive traffic or maintenance messages 733 The PTUP message contains the following parameters: 735 INFO String 737 The format for the PTUP message is as follows: 739 0 7 8 15 16 31 740 +---------------+---------------+ 741 |Length | INFO String | 743 . . . 745 + +-------+---------------+ 746 | | Spare | 747 +---------------+---------------+ 749 2.3.3.2 Path-Down (PTDN) 751 The PTDN message is used to indicate to a remote ITUN peer that the layer is not ready to receive traffic or maintenance messages. 753 The PTDN message contains the following parameters: 755 INFO String 757 The format for the PTDN message is as follows: 759 0 7 8 15 16 31 760 +---------------+---------------+ 761 |Length | INFO String | 763 . . . 765 + +-------+---------------+ 766 | | Spare | 767 +---------------+---------------+ 769 2.3.3.3 Path Version (PTVR) 771 The PTVR message is used in response to a PTUP or PTDN message to indicate that the indicated version is not supported. The message header of the PTVR will indicate the version supported. 773 The PTVR message contains the following parameters: 774 INFO String 776 The format for the PTVR message is as follows: 778 0 7 8 15 16 31 779 +---------------+---------------+ 780 |Length | INFO String | 782 . . . 784 + +-------+---------------+ 785 | | Spare | 786 +---------------+---------------+ 788 2.3.4 IP Node Maintenance (IPNM) Messages 790 2.3.4.1 Node Up (NDUP) 792 The NDUP message is sent by an MGC to indicate to an SG that it is the active MGC to be used from within a list of primary and back-up MGCs for a particular signalling mapping relationship. 794 The NDUP message contains the following parameters: 796 INFO String 798 The format for the NDUP message is as follows: 800 0 7 8 15 16 31 801 +---------------+---------------+ 802 |Length | INFO String | 804 . . . 806 + +-------+---------------+ 807 | | Spare | 808 +---------------+---------------+ 810 2.3.4.2 Node Down (NDDN) 811 The NDDN message is sent by an MGC to indicate to an SG that it is no longer the the active MGC to be used from within a list of primary and back-up MGCs for a particular signalling mapping relationship. The SG will respond with an NDDN message and either buffer or discard incoming messages for a timed period and then discard. 813 The NDUP message contains the following parameters: 815 INFO String 817 The format for the NDUP message is as follows: 819 0 7 8 15 16 31 820 +---------------+---------------+ 821 |Length | INFO String | 823 . . . 825 + +-------+---------------+ 826 | | Spare | 827 +---------------+---------------+ 829 3.0 Procedures 831 3.1 IP Transport Path Availability Management (TPAM) Procedures 833 3.1.1 Path State 835 The possible states of a path are: 836 Down: Path down. 837 Up: Path up. The transport association is active and node maintenance messages can be exchanged when the path is up. 838 Active: MTP-User PDUs can be carried over the path. 840 3.1.2 Path up 842 3.1.2.1 SG Operation 843 The SG will mark the path as up if an explicit path-up (PTUP) message is received and internally the path is allowed to come up (i.e., not in a locked local maintenance state). A path-up (PTUP) message will be sent to acknowledge the received PTUP. The SG will respond to a PTUP with a PTDN message if the path is in a locked maintenance state. 844 The SG will send a PTUP message in response to a received PTUP message from the MGC even if that path was already marked as UP at the SG. 845 The paths are controlled by the MGC. The SG will only send PTUP in response to the reception of a PTUP message. 846 3.1.2.2 MGC Operation 847 The MGC will send PTUP messages every 2 seconds until the path comes up (i.e. until it receives a PTUP message from the SG for that path). The MGC may decide to reduce the frequency (say to every 5 seconds) if the path does not come up after a few tries. 848 The MGC should wait for the PTUP message from the SG before transmitting Node maintenance messages (NDDN or NDUP) or ITUN messages or it will risk message loss. The PTUP message received from the SG is not acknowledged by the MGC. 849 The PTUP messages will be sent by the MGC until the path comes up or until the paths are manually locked on the MGC side. 851 3.1.3 Path Down 853 3.1.3.1 SG Operation 855 The SG will mark the path as down and send a PTDN message to the SS if one of the following events occur: 856 - a Path-down (PTDN) message is received from the MGC, 857 - the path is locked by local maintenance. 859 The SG will also send a PTDN message when the path is already down and a PTDN) message is received from the MGC. 861 3.1.3.2 MGC Operation 863 The MGC will send PTDN whenever it wants to take down a path. 864 Since the PTDN messages to the SG or the PTDN responses from the SG can be lost, the MGC can send PTDN messages every 2 seconds until the path comes down (i.e. until it receives a PTDN message from the SG for that path). 866 3.1.4 Path Version Control 868 If a message with an unknown version is received, the receiving node will respond with a path version (PTVR) message. This will indicate to the sender which version the receiving node supports. 869 This is useful when protocol version upgrades are being performed. A node with the newer version should support the older versions used on other nodes it is communicating with. 870 The version field in the PTVR message header associated with the will indicate the version supported by the node. 872 3.2 IP Node Maintenance (IPNM) Messages 874 3.2.1 Node State 875 Two MGC states are possible: Node down and Node up. 876 NDDN and NDUP messages are sent by the MGC to the SG, which will acknowledge by returning an NDDN or NDUP message. 877 These messages are only accepted by a node if the path the message is received on is up. If the path is down the SG will respond to either message with a PTDN message. 878 Only one MGC from a list of primary and back-up MGCs (for a particular signalling mapping relationship) can be active at any one time. Reception of a NDUP will cause the other MGCs in the list to be forced down. 879 3.2.2 Node Down 880 When a NDDN message is received, message transmission to that MGC ceases. The SG will either discard all incoming messages or start buffering the incoming messages for b seconds after which messages will be discarded. 881 3.2.3 Node Up 882 When a node up (NDUP) message is received, the SG will start routing to that MGC. Reception of a NDUP message overrides any previous NDUP messages and results in the MGC associated with the NDUP message to become the newly active MGC. 884 4.0 References 886 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 887 System No. 7 (SS7)' 889 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - Message Transfer Part (MTP)' 891 [3] ITU-T Recommendation Q.2140 'B-ISDN ATM Adaptation Layer - 892 Service Specific Coordination Function for signaling at the Network 893 Node Interface (SSCF at NNI) 895 [4] ITU-T Recommendation Q.2110 'B-ISDN ATM Adaptation Layer - 896 Service Specific Connection Oriented Protocol (SSCOP) 898 [5] Multi-Network Datagram Transmission Protocol 899 draft-ietf-sigtran-mdtp-06.txt, June 1999 901 5.0 Author's Addresses 903 Lyndon Ong 904 Nortel Networks 905 4401 Great America Pkwy 906 Santa Clara, CA 907 USA 95054 908 long@nortelnetworks.com 910 Greg Sidebottom 911 Nortel Networks 912 3685 Richmond Rd, 913 Nepean, Ontario 914 Canada K2H5B7 915 gregside@nortelnetworks.com 917 Ian Rytina 918 Ericsson Australia 919 37/360 Elizabeth StreetMelbourne, Victoria 3000, Australiaian.rytina@ericsson.com 920 Hanns Juergen Schwarzbauer 921 SIEMENS AGHofmannstr. 5181359 Munich, GermanyHannsJuergen.Schwarzbauer@icn.siemens.de