idnits 2.17.1 draft-ietf-sigtran-m2ua-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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 11 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 1999) is 8990 days in the past. Is this intentional? -- 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: '7' is mentioned on line 441, but not defined == Unused Reference: '1' is defined on line 1161, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1167, 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' ** Downref: Normative reference to an Informational draft: draft-ietf-sigtran-framework-arch (ref. '4') == Outdated reference: A later version (-13) exists of draft-ietf-sigtran-sctp-00 ** Downref: Normative reference to an Informational draft: draft-huitema-megaco-mgcp-v1 (ref. '6') Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ken Morneault 2 INTERNET-DRAFT Cisco Systems 3 Malleswar Kalla 4 Telcordia 5 Greg Sidebottom 6 Nortel Networks 8 Expires in six months September 1999 10 SS7 MTP2-User Adaptation Layer 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 backhauling of SS7 MTP2 41 User signaling messages over IP using the Sigtran Common Transport 42 Protocol (SCTP). This protocol would be used between a Signaling 43 Gateway (SG) and Media Gateway Controller (MGC). It is assumed that 44 the SG receives SS7 signaling over a standard SS7 interface using the 45 SS7 Message Transfer Part (MTP) to provide transport. 47 TABLE OF CONTENTS 49 1. Introduction..............................................2 50 1.1 Scope..................................................2 51 1.2 Terminology............................................3 52 1.3 Signaling Transport Architecture.......................3 53 1.4 Services Provide by the M2UA Adaptation Layer..........4 54 1.5 Function Provided by the M2UA Layer....................6 55 1.6 Definition of the M2UA Boundaries......................7 56 2. Protocol Elements.........................................8 57 2.1 Common Message Header..................................8 58 2.2 M2UA Message Header....................................9 59 2.3 M2UA Messages.........................................10 60 3. Procedures...............................................17 61 3.1 Procedures to Support Service in Section 1.4.1........17 62 3.2 Procedures to Support Service in Section 1.4.2........17 63 3.3 Procedures to Support Service in Section 1.4.3........17 64 4. Examples of MTP2 User Adaptation (M2UA) Procedures.......21 65 4.1 Establishment of associations between SG and MGC......21 66 examples 67 4.2 MTP Level 2 / MTP Level 3 Boundary Examples...........22 68 4.3 Layer Management Communication Examples................24 69 5. Security.................................................24 70 6. Acknowledgements.........................................24 71 7. References...............................................24 72 8. Author's Addresses.......................................25 74 1. Introduction 76 1.1 Scope 78 There is a need for SCN signaling protocol delivery from an Signaling 79 Gateway (SG) to a Media Gateway Controller (MGC). The delivery 80 mechanism should meet the following criteria: 82 * Support for MTP Level 2 / MTP Level 3 interface boundary 83 * Support for communication between Layer Management modules on SG and 84 MGC 85 * Support for management of active associations between the SG and MGC 87 In other words, the Signaling Gateway will terminate MTP Level 1 and MTP 88 Leve 2 and will transport MTP Level 3 messages to a Media Gateway 89 Controller (MGC). 91 1.2 Terminology 93 MTP2-User - A protocol that normally uses the services of MTP Level 2 94 (i.e. MTP3). 96 Interface - For the purposes of this document, an interface is a SS7 97 signaling link. 99 Association - An association refers to a SCTP association. The 100 association will provide the transport for the delivery of protocol 101 data units for one or more interfaces. 103 Stream - A stream refers to a SCTP stream. For the purposes of this 104 document, a stream will be mapped to a SS7 signaling link, or interface. 106 Backhaul - Refers to the transport of signaling from the point of 107 interface for the associated data stream (i.e., SG function in the MGU) 108 back to the point of call processing (i.e., the MGCU), if this is not 109 local [4]. 111 Application Server Process - A process instance of an Application Server. 112 Up to 3 processes can be defined (Primary, Secondary and Tertiary). 113 Examples of Application Server Processes are primary or backup MGC 114 instances. 116 Application Server Process Path (or just Path) - A Path to a remote 117 Application Server Process instance. A Path maps 1:1 to an SCTP 118 association). 120 Application Server - Groups all the Application Server Processes 121 associated with an application (e.g., primary, secondary, tertiary). 122 Examples of Application Servers are virtual MGCs or IP Databases. 124 Fail-over - The capability to re-route signaling traffic as required 125 between related Application Server Processes in the event of failure or 126 unavailability of the currently used Application Server Process (e.g., 127 from primary MGC to back-up MGC). Fail-over also applies upon the 128 return to service of a previously unavailable Process. 130 Signaling Link Terminal (SLT) - Refers to the means of performing all 131 of the functions defined at MTP level 2 regardless of their 132 implementation [2]. 134 1.3 Signaling Transport Architecture 136 The architecture that has been defined for SCN signaling transport 137 over IP uses multiple components, including an IP transport 138 protocol, a signaling common transport protocol (SCTP) and an adaptation 139 module to support the functions expected by a particular SCN signaling 140 protocol from its underlying protocol layer. 142 In reference to the SIGTRAN framework architecture [4], this document 143 defines a SCN adaptation module that is suitable for the transport of 144 SS7 MTP2 User. The only SS7 MTP2 User is MTP3. 146 In a Signaling Gateway, it is expected that the SS7 signaling is 147 received over a standard SS7 network termination, using the SS7 Message 148 Transfer Part (MTP) to provide transport of SS7 signaling messages to 149 and from an SS7 Signaling End Point (SEP) or SS7 Signaling Transfer 150 Point (STP). In other words, the SG acts as a Signaling Link Terminal 151 (SLT) [2]. The SG then provides interworking of transport functions 152 with IP Signaling Transport, in order to transport the MTP3 signaling 153 messages to the MGC where the peer MTP3 protocol layer exists, as shown 154 below: 156 ****** SS7 ****** IP ******* 157 *SEP *-----------* SG *-------------* MGC * 158 ****** ****** ******* 160 +----+ 161 |S7UP| 162 +----+ 163 +----+ |MTP | 164 |S7UP| |L3 | 165 +----+ +----+----+ +----+ 166 |MTP | |MTP |M2UA| |M2UA| 167 |L3 | | +----+ +----+ 168 |L2 | |L2 |SCTP| |SCTP| 169 |L1 | |L1 +----+ +----+ 170 | | | |UDP | |UDP | 171 +----+ +---------+ +----+ 173 SEP - SS7 Signaling Endpoint 174 UDP - User Datagram Protocol 175 SCTP - Signaling Common Transport Protocol 176 (Refer to Reference [5]) 178 Figure 1: 180 Note: STPs may be present in the SS7 path between the SEP and the SG. 182 1.3.1 UDP port 184 A request will be made to IANA to assign a UDP port for M2UA. 186 1.4 Services Provided by the M2UA Adaptation Layer 188 The SS7 MTP3/MTP2(MTP2-User) interface is retained at the termination 189 point in the IP network, so that the M2UA protocol layer is required to 190 provide the equivalent set of services to its users as provided by the 191 MTP Level 2 to MTP Level 3. 193 This includes the following services: 195 1.4.1 Support for MTP Level 2 / MTP Level 3 interface boundary 197 Also provision is made for protocol elements that enable a seamless, or 198 as seamless as possible, operation of the MTP2-User peers in the SS7 and 199 IP domains. This includes 201 Data 203 Provides the ability to transport MTP2 User information (in this case, 204 MTP Level 3 PDUs). 206 Link Establish 208 Provides the ability to request MTP Level 2 to bring SS7 links 209 in-service. 211 Link Release 213 Provides the ability to request MTP Level 2 to take SS7 links out-of- 214 service. Also, provides mechanism for MTP2 to autonomously indicate 215 that SS7 link(s) have gone out-of-service. 217 Link State 219 Provides the ability to request state change or information on a 220 per link basis. Some examples would be the forcing of Local Processor 221 Outage or flushing buffers. 223 Link Status 225 Provides a means for asychronous notification of link state changes to 226 be reported to the upper layer (MTP Level 3). An examples would be the 227 reporting of remote processor 228 outage event. 230 Data Retrieval 232 Provides a mechanism to perform SS7 link changeover procedure in 233 the case of a SS7 link failure. 235 1.4.2 Support for communication between Layer Management modules 236 on SG and MGC 238 It is envisioned that the M2UA layer needs to provide some messages that 239 will facilitate communication between Layer Management modules on the SG 240 and MGC. 242 To facilitate reporting of errors that arise because of backhauling MTP 243 Level 3 scenario, the following primitive is defined: 245 M-ERROR 247 The M-ERROR message is used to indicate an error with a received 248 M2UA message (e.g., interface identifier value is not known to the SG). 250 1.4.3 Support for management of active associations between SG and MGC 252 The M2UA layer on the SG keeps the state of various ASPs it is associated 253 with. A set of primitives between M2UA layer and the Layer Management 254 are defined below to help the Layer Management manage the association(s) 255 between the SG and the MGC. 257 M-SCTP ESTABLISH 259 The M-SCTP ESTABLISH primitive is used to request, indicate and confirm 260 the establishment of SCTP association to a peer M2UA node. 262 The M2UA layer may also need to inform the status of the SCTP 263 association(s) to the Layer Management. This can be achieved using 264 the following primitive. 266 M-SCTP STATUS 268 The M-SCTP STATUS primitive is used to request and indicate the status 269 of underlying SCTP association(s). 271 The Layer Management may need to inform the M2UA layer of a user status 272 (i.e., failure, active, etc.), so that messages can be exchanged between 273 M2UA layer peers to stop traffic to the local M2UA user. This can be 274 achieved using the following primitive. 276 M-ASP STATUS 278 The M-ASP STATUS primitive is used by the Layer Management to indicate 279 the status of the local M2UA user to the M2UA layer. 281 1.5 Functions Provided by the M2UA Layer 283 1.5.1 Mapping 285 The M2UA layer must maintain a map of a Interface ID to a physical 286 interface on the Signaling Gateway. A physical interface would be a 287 V.35 line, T1 line/timeslot, E1 line/timeslot, etc. The M2UA layer 288 must also maintain a map of Interface ID to SCTP association and to a 289 stream within the association. 291 1.5.2 Status of ASPs 293 The M2UA layer on the Signaling Gateway must maintain the state of one or 294 more Application Server Process(es) it is associated with. The state of 295 an ASP changes because of reception of peer-to-peer messages or reception 296 of indications from the local SCTP association. ASP state transition 297 procedures are described in Section Section 3.3. 299 1.5.3 Flow Control / Congestion 301 It is possible for the M2UA layer to be informed of IP network congestion 302 by means of an implementation-dependent function (i.e. an indication 303 from the SCTP). If the M2UA layer receives this indication, the action(s) 304 taken are implementation dependent. 306 1.5.4 SCTP Stream Management 308 SCTP allows user specified number of streams to be opened during the 309 initialization. It is the responsibility of the M2UA layer to ensure 310 proper management of these streams. SCTP streams provide a means for 311 avoiding head of line blocking. For that reason, a stream will be used 312 per SS7 signaling link terminated by the Signaling Gateway. The SS7 313 signaling link is identified by the Interface Identifier in the message 314 header (refer to Section 2.3). 316 1.5.5 Seamless SS7 Network Management Interworking 318 If the SG loses the SCTP association to the MGC, it should follow 319 MTP 2 processor outage procedures [2]. 321 1.5.6 Management Inhibit/Uninhibit 323 Local Management may wish to stop traffic across an SCTP association in 324 order to temporarily remove the association from service or to perform 325 testing and maintenance activity. The function could optionally be used 326 to manage the start of traffic on to a newly-available SCTP association. 328 1.6 Definition of the M2UA Boundaries 330 1.6.1 Definition of the M2UA / MTP Level 3 boundary 332 DATA 333 ESTABLISH 334 RELEASE 335 STATE 336 STATUS 337 RETRIEVAL 338 DATA RETRIEVAL 339 DATA RETRIEVAL COMPLETE 340 1.6.2 Definition of the M2UA / MTP Level 2 boundary 342 DATA 343 ESTABLISH 344 RELEASE 345 STATE 346 STATUS 347 RETRIEVAL 348 DATA RETRIEVAL 349 DATA RETRIEVAL COMPLETE 351 1.6.3 Definition of the Lower Layer Boundary between M2UA and SCTP 353 The upper layer and layer management primitives provided by SCTP are 354 provided in Reference [6] Section 9. 356 1.6.4 Definition of Layer Management / M2UA Boundary 358 M-ERROR 359 M-SCTP ESTABLISH 360 M-SCTP STATUS 361 M-ASP STATUS 363 2.0 Protocol Elements 365 This section describes the format of various messages used in this 366 protocol. 368 2.1 Common Message Header 370 The protocol messages for MTP2 User Adaptation require a message header 371 structure which contains a version, message type and message length. This 372 message header is common among all SCN adaptation layers. 374 0 7 8 15 16 31 375 +---------------+---------------+ 376 | Vers | Spare | Msg Type | 377 +---------------+---------------+ 378 | Message Length | 379 +-------------------------------+ 381 Figure 2 Common Message Header 383 2.1.1 Version 385 The version field (vers) contains the version of the M2UA adapation 386 layer. The supported versions are: 388 01 Release 1.0 of M2UA adaptation protocol 390 2.1.2 Message Type 392 The valid message types are defined in Section 2.2.2 and the message 393 contents are described in Section 2.3. Each message can contain 394 parameters. 396 The following list contains the message types for the defined messages. 398 MTP2 User Adaptatation (MAUP) Messages 400 Data Request 0601 401 Data Indication 0602 402 Establish Request 0603 403 Establish Confirm 0604 404 Release Request 0605 405 Release Confirm 0606 406 Release Indication 0607 407 State Request 0608 408 State Confirm 0609 409 State Indication 060a 410 Data Retrieval Request 060b 411 Data Retrieval Confirm 060c 412 Data Retrieval Indication 060d 413 Data Retrieval Complete Indication 060e 415 Application Server Process Maintenance (ASPM) Messages 417 ASP Up (ASPUP) 0301 418 ASP Down (ASPDN) 0302 419 ASP Active (ASPAC) 0401 420 ASP Inactive (ASPIA) 0402 422 Management (MGMT) Messages 424 Error 0001 426 2.1.3 Message Length 428 The Message length defines the length of the message in octets, not 429 including the header. 431 2.2 M2UA Message Header 433 In addition to the common message header, there will be a M2UA specific 434 message header. The M2UA specific message header will immediately 435 follow the common message header, but will only be used with MAUP and 436 MGMT messages. 438 This message header will contain the Interface Identifier. The Interface 439 Identifier identifies the physical interface at the SG for which the 440 signaling messages are sent/received. The interface identifier follows 441 the same endpoint naming scheme provided in MGCP [7]. For example, if 442 a Signaling Gateway terminates a E1 and the SS7 signaling link is one 443 timeslot 16, the interface identifier could be the following: 445 e1/16@sgw1.example.net 447 The use of wildcards is not acceptable. 449 Note: The Interface Identifier string should be padded to 32-bit 450 boundaries. The length field indicates the end of the string. 452 0 15 16 31 453 +---------------+---------------+ 454 | Tag (0x1) | Length | 455 +-------------------------------+ 457 | Interface Identifier | 459 +-------------------------------+ 461 Figure 3 M2UA Message Header 463 The Tag value for Interface Identifier is 0x1. The length provides the 464 length of the Interface Identifier string in bytes. 466 2.3 M2UA Messages 468 The following section defines the messages and parameter contents. The 469 M2UA messages will use the command header and the M2UA specific header. 471 2.3.1 MTP2 User Adaptation Messages 473 2.3.1.1 Data (Request, Indication) 475 The Data message contains an SS7 MTP2-User Protocol Data Unit (PDU). The 476 Data message contains the protocol data. 478 The format for the Data Message parameters is as follows: 480 0 15 16 31 481 +-------------------------------+ 482 ... 483 | Protocol Data | 484 ... 485 +---------------+---------------+ 487 The Protocol Data field contains the MTP2-User application message. 489 2.3.1.2 Establish (Request, Confirmation) 491 The Establish Request message is used to establish the channel or to 492 indicate that the channel has been established. Note that the gateway 493 may already have the channel established at its layer. If so, upon 494 receipt of an Establish Request, the gateway takes no action except to 495 send an Establish Confirm. 497 0 15 16 31 498 +---------------+---------------+ 499 | State | 500 +---------------+---------------+ 502 The valid values for State are shown in the following table. 504 Define Value Description 505 ESTABLISH_NORMAL 0x0 Follow normal procedure for 506 establishing a SS7 link 507 ESTABLISH_EMERGENCY 0x1 Follow emergency procedure for 508 establishing a SS7 link 510 2.3.1.3 Release (Request, Indication, Confirmation) 512 This Release Request message is used to release the channel. The Release 513 Confirm and Indication messages are used to indicate that the channel has 514 been released. 516 0 15 16 31 517 +---------------+---------------+ 518 | Reason | 519 +---------------+---------------+ 521 The valid values for Reason are shown in the following table. 523 Define Value Description 524 RELEASE_MGMT 0x0 Management layer generated release. 525 RELEASE_PHYS 0x1 Physical layer alarm generated release. 526 RELEASE_SIOS 0x2 Receipt of SIOS 527 RELEASE_OTHER 0x3 Other reason SS7 link out-of-service 529 (should we keep it simple, or provide list of reasons that would 530 enable debugging) 532 2.3.1.4 State (Request, Confirm) 534 The State Request message can be sent from a MGC to cause an action 535 on a particular SS7 link supported by the Signaling Gateway. The gateway 536 sends a State Confirm to the MGC if the action has been successfully 537 completed. The State Confirm reflects that state value received in 538 the State Request message. 540 0 15 16 31 541 +---------------+---------------+ 542 | State | 543 +---------------+---------------+ 545 The valid values for State are shown in the following table. 547 Define Value Description 548 STATUS_LOC_PROC_SET 0x0 Request local processor outage. 549 STATUS_LOC_PROC_CLEAR 0x1 Request local processor outage recovered. 550 STATUS_EMER_SET 0x2 Request emergency alignment procedure. 551 STATUS_EMER_CLEAR 0x3 Request normal alignment (cancel 552 emergency) procedure. 553 STATUS_FLUSH_BUFFERS 0x4 Flush transmit and retransmit buffers. 554 STATUS_CONTINUE 0x5 Continue. 556 2.3.1.5 State Indication 558 The MTP2 State Indication message can be sent from a gateway to a call 559 agent to indicate a condition on a channel. 561 0 15 16 31 562 +---------------+---------------+ 563 | State | 564 +---------------+---------------+ 566 The valid values for State are shown in the following table. 568 Define Value Description 569 EVENT_ENTER_LPO 0x0 Entered local processor outage. 570 EVENT_EXIT_LPO 0x1 Exited local processor outage. 571 EVENT_ENTER_CONG 0x2 Entered a congested state. 572 EVENT_EXIT_CONG 0x3 Exited a congested state. 573 EVENT_PHYS_UP 0x4 Physical interface up. 574 EVENT_PHYS_DOWN 0x5 Physical interface down. 575 EVENT_PROTOCOL_ERR 0x6 Protocol error occurred. 576 EVENT_REM_ENTER_CONG 0xc Remote entered congestion. 577 EVENT_REM_EXIT_CONG 0xd Remote exited congestion. 578 EVENT_REM_ENTER_PO 0xe Remote entered processor outage. 579 EVENT_REM_EXIT_PO 0xf Remote exited processor outage. 581 2.3.1.6 Retrieval (Request, Confirm) 583 The MTP2 Retrieval Request message is used during the MTP Level 3 584 changeover procedure to request the BSN, to retrieve PDUs from the 585 retransmit queue or to flush PDUs from the retransmit queue. 587 0 15 16 31 588 +---------------+---------------+ 589 | Action | 590 +---------------+---------------+ 591 | fsn_bsn | 592 +---------------+---------------+ 594 The valid values for Action are shown in the following table. 596 Define Value Description 597 ACTION_RTRV_BSN 0x1 Retrieve the backward sequence number. 598 ACTION_RTRV_MSGS 0x2 Retrieve the PDUs from the retransmit 599 queue. 600 ACTION_DROP_MSGS 0x3 Drop the PDUs in the retransmit queue. 602 In the Retrieval Request message, the fsn_bsn field contains the FSN of 603 the far end if the action is ACTION_RTRV_MSGS. 605 When the Signaling Gateway sends a Retrieval Confirm to this request, 606 it echos the action and puts the BSN in the fsn_bsn field if the action 607 was ACTION_RTRV_BSN. 609 2.3.1.7 Retrieval Indication 611 The Retrieval Indication message is sent by the Signaling Gateway 612 with a PDU from the retransmit queue. The Retrieval Indication 613 message does not contain the Action or fsn_bsn fields, just a PDU from 614 the retransmit queue. 616 0 15 16 31 617 +---------------+---------------+ 618 | | 620 . PDU from retransmit . 621 . queue . 623 | | 624 +---------------+---------------+ 626 2.3.1.8 Retrieval Complete Indication 628 The MTP2 Retrieval Complete Indication message is exactly the same as 629 the MTP2 Retrieval Indication message except that it also indicates that 630 it contains the last PDU from the retransmit queue. 632 2.3.2 Application Server Process Maintenance (ASPM) Messages 634 The ASPM messages will only use the common header. 636 2.3.2.1 ASP UP (ASPUP) 637 The ASPUP message is used to indicate to a remote M2UA peer that the 638 layer is ready to receive traffic or maintenance messages. 640 The ASPUP message contains the following parameters: 642 Adaptation Layer Identifer (optional) 643 SCN Protocol Identifier (optional) 645 The Adaptation Layer Identifier is a string that identifies the 646 adaptation layer. This string must be set to "M2UA" which means 647 the length will be 4. 649 The Protocol Identifier field contains the identity of the specific SCN 650 signaling protocol being transported. The Protocol ID defines the 651 protocol type, variant, and version, and thereby specifies the components 652 and encoding of the PROTOCOL DATA field. The Protocol Identifier also 653 defines what SCN protocol message components are included in the PROTOCOL 654 DATA. 656 (Ed. Note: Need encoding of mime-type value or OID or fixed 657 string/integer that will be administered outside of this document 658 (IANA). Also, perhaps bring in text from Christian's mime document - See 659 "draft-ietf-sigtran-mime-isup.txt" for an example of an application/ISUP 660 media type defined according to the rules defined in RFC 2048.?) 662 The format for the ASPUP message is as follows: 664 0 15 16 31 665 +---------------+---------------+ 666 | Tag (0x2) | Length | 667 +---------------+---------------+ 669 | Adaptation Layer Identifier | 671 +---------------+---------------+ 672 | Tag (0x3) | Length | 673 +---------------+---------------+ 675 | Protocol Identifier | 677 +---------------+---------------+ 678 | Tag (0x4) | Length | 679 +---------------+---------------+ 681 | INFO String | 683 +---------------+---------------+ 685 Note: Strings are padded to 32-bit boundaries. The length field 686 indicates the end of the string. 688 2.3.2.2 ASP Down (ASPDN) 690 The ASPDN message is used to indicate to a remote M2UA peer that the 691 layer is not ready to receive traffic or maintenance messages. 693 The ASPDN message contains the following parameters: 695 INFO String 697 The format for the ASPDN message is as follows: 699 0 15 16 31 700 +---------------+---------------+ 701 | Tag (0x4) | Length | 702 +---------------+---------------+ 704 | INFO String | 706 +---------------+---------------+ 708 ##### 710 We discussed adding a reason code. Reason could be failure or 711 management inhibit. 713 ##### 715 2.3.2.3 ASP Active (ASPAC) 717 The ASPAC message is sent by an ASP to indicate to an SG that it is 718 the active ASP to be used from within a list of primary and back-up ASPs 719 for a particular signaling mapping relationship. 721 The ASPAC message contains the following parameters: 723 INFO String 725 The format for the ASPAC message is as follows: 727 0 15 16 31 728 +---------------+---------------+ 729 | Tag (0x4) | Length | 730 +---------------+---------------+ 732 | INFO String | 734 +---------------+---------------+ 736 2.3.2.4 ASP Inactive (ASPIA) 738 The ASPIA message is sent by an ASP to indicate to an SG that it is 739 no longer the the active ASP to be used from within a list of primary 740 and back-up ASP for a particular signaling mapping relationship. The 741 SG will respond with an ASPIA message and either buffer or discard 742 incoming messages for a timed period and then discard. 744 The ASPIA message contains the following parameters: 746 INFO String 748 The format for the ASPIA message is as follows: 750 0 15 16 31 751 +---------------+---------------+ 752 | Tag (0x4) | Length | 753 +---------------+---------------+ 755 | INFO String | 757 +---------------+---------------+ 759 2.3.3 Layer Management (MGMT) Messages 761 2.3.3.1 Error (ERR) 763 The ERR message is sent when an invalid value is found in an incoming 764 messages. 766 The ERR message contains the following parameters: 768 Error Code 770 The format for the ERR message is as follows: 772 0 7 8 15 16 31 773 +---------------+---------------+ 774 | Error Code | 775 +---------------+---------------+ 777 The Error Code can be one of the following values: 779 Invalid Version 0x1 780 Invalid Interface Identifier 0x2 781 Invalid SCN Version 0x3 782 Invalid Adaptation Layer Identifier 0x4 783 Invalid Stream Identifier 0x5 784 Invalid Message Type 0x6 786 3.0 Procedures 788 The M2UA layers needs to respond to various primitives it receives from 789 other layers as well as messages it receives from the peer-to-peer 790 messages. This section describes various procedures involved in 791 response to these events. 793 3.1 Procedures to Support Service in Section 1.4.1 795 These procedures achieve the M2UA layer's "Transport of MTP Level 2 / 796 MTP Level 3 boundary" service. 798 3.1.1 MTP Level 2 / MTP Level 3 Boundary Procedures 800 On receiving a primitives from the local layer, the M2UA layer will 801 send the corresponding MAUP message (see Section 2) to its peer. The 802 M2UA layer must fill in various fields of the common and specific headers 803 correctly. In addition the message needs to be sent on the SCTP stream 804 that corresponds to the SS7 link. 806 3.1.2 MAUP Message Procedures 808 On receiving MAUP messages from a peer M2UA layer, the M2UA layer on an 809 SG or MGC needs to invoke the corresponding layer primitives to the 810 local MTP Level 2 or MTP Level 3 layer. 812 3.2 Procedures to Support Service in Section 1.4.2 814 3.2.1 LM primitives procedures 816 On receiving these primitives from the local layer, the M2UA layer will 817 send the corresponding LM message (Error) to its peer. The M2UA layer 818 must fill in the various fields of the common and specific headers 819 correctly. 821 3.2.2 LM message procedures 823 Upon receipt of LM messages the M2UA layer must invoke the corresponding 824 Layer Management primitives (M-ERROR) to the local layer management. 826 3.3 Procedures to Support Service in Section 1.4.3 828 These procedures achieve the M2UA layer's "Support for management of 829 active associations between SG and MGC" service. 831 3.3.1 AS and ASP State 833 The state of the each ASP is maintained in the M2UA layer on the SG. The 834 state of an ASP changes due to events. The events include: 836 * Reception messages from peer M2UA layer 837 * Reception of indications from layers below 839 The ASP state transition diagram is shown in Figure 4. 841 The possible states of an ASP are: 843 ASP-DOWN: Application Server Process is unavailable. Initially all ASPs 844 are in this state. 846 ASP-UP: Application Server Process is available but application traffic is 847 stopped. 849 ASP-ACTIVE: Application Server Process is available and application traffic 850 is active. At most one ASP per AS can be in the active state. 852 +-------------+ 853 |-------->| | 854 | | ASP-ACTIVE | 855 | | | 856 | | | 857 | +-------------+ 858 | ^ | 859 | ASP | | ASP 860 | Active | | Inactive 861 | | v 862 | +-------------+ 863 | | | 864 ASP Down / | | | 865 SCTP CDI | | ASP-UP | 866 | | | 867 | | | 868 | +-------------+ 869 | ^ | 870 | ASP | | ASP Down / 871 | Up | | SCTP CDI 872 | | v 873 | +-------------+ 874 | | | 875 |-------->| | 876 | ASP-DOWN | 877 | | 878 | | 879 +-------------+ 881 SCTP CDI: Local SCTP layer's Communication Down Indication to the Upper Layer 882 Protocol (M2UA) on an SG. SCTP will send this indication when it 883 detects the loss of connectivity to ASP's SCTP layer. 885 Figure 4: ASP State Transition Diagram 887 The possible states of an AS are: 889 AS-DOWN: Application Server is unavailable. This state implies that all 890 ASPs are in the ASP-DOWN state for this AS. 892 AS-UP: One or more ASPs are in the ASP-UP state. 894 AS-ACTIVE: Application Server is available and application traffic is 895 active. This state implies that one ASP is in the ASP-ACTIVE state. 897 AS-PENDING: Currently Active ASP became inactive or SCTP association with it 898 is lost. A Recovery timer will be started and in coming SCN messages will 899 be queuedby the SG. If an ASP becomes Active before the recovery timer 900 expires, AS will move to AS-ACTIVE state and all the queued messages will 901 be sent to the active ASP. If the recovery timer expires before an ASP 902 becomes active, SG stops queuing messages and discards all queued messages. 903 AS will move to AS-UP if at least one ASP is in ASP-UP state, otherwise it 904 will move to AS-DOWN state. 906 Note: If AS moves from AS-PENDING state to AS-UP or AS-DOWN states, the Layer 907 Management on MG may take appropriate SCN notification actions. 909 +----------+ one ASP trans ACTIVE +-------------+ 910 | |------------------------>| | 911 | AS-UP | | AS-ACTIVE | 912 | | | | 913 | |< -| | 914 +----------+ \ / +-------------+ 915 ^ | \ Tr Trigger / ^ | 916 | | \ at least one / | | 917 | | \ ASP in UP / | | 918 | | \ / | | 919 | | \ / | | 920 | | \ /---/ | | 921 one ASP | | \ / one ASP | | ACTIVE ASP 922 trans | | all ASP \-/----\ trans | | trans to UP or 923 to UP | | trans to / \ ACTIVE | | ACTIVE ASP 924 | | DOWN / \ | | SCTP CDI 925 | | / \ | | 926 | | / \ | | 927 | | /all ASP \ | | 928 | v / trans to \ | v 929 +----------+ / DOWN \ +-------------+ 930 | |<--/ -| | 931 | AS-DOWN | | AS-PENDING | 932 | | | (queueing) | 933 | |<------------------------| | 934 +----------+ Tr Trigger no ASP +-------------+ 935 in UP state or 936 prev ACTIVE ASP trans 937 to DOWN state 939 Tr = Recovery Timer 941 Figure 5: AS State Transition Diagram 943 3.3.2 ASP UP 945 3.3.2.1 SG Operation 947 The SG will mark the path as up if an explicit ASP UP (ASPUP) message is 948 received and internally the path is allowed to come up (i.e., not in a 949 locked local maintenance state). An ASP UP (ASPUP) message will be sent 950 to acknowledge the received ASPUP. The SG will respond to a ASPUP with a 951 ASPDN message if the path is in a locked maintenance state. 953 The SG will send a ASPUP message in response to a received ASPUP message 954 from the MGC even if that path was already marked as UP at the SG. 956 The paths are controlled by the MGC. The SG will only send ASPUP in 957 response to the reception of a ASPUP message. 959 3.3.2.2 MGC Operation 961 The MGC will send ASPUP messages every 2 (add text regarding this being 962 a configurable timer) seconds until the path comes up (i.e. until it 963 receives a ASPUP message from the SG for that path). The MGC may decide 964 to reduce the frequency (say to every 5 seconds) if the an acknowledge- 965 ment is not received after a few tries. 967 The MGC should wait for the ASPUP message from the SG before transmitting 968 ASP maintenance messages (ASPIA or ASPAC) or M2UA messages or it will 969 risk message loss. The ASPUP message received from the SG is not 970 acknowledged by the MGC. 972 3.3.3 ASP Down 974 3.3.3.1 SG Operation 976 The SG will mark the ASP as down and send a ASPDN message to the MGC if 977 one of the following events occur: 979 - a ASP Down(ASPDN) message is received from the MGC, 980 - the ASP is locked by local maintenance. 982 The SG will also send a ASPDN message when the ASP is already down and 983 a ASPDN) message is received from the MGC. 985 3.3.3.2 MGC Operation 987 The MGC will send ASPDN whenever it wants to take down a ASP. Since the 988 ASPDN messages to the SG or the ASPDN responses from the SG can be lost 989 (for example, during a MGC node failover), the MGC can send ASPDN messages 990 every 2 seconds until the path comes down (i.e. until it receives a ASPDN 991 message from the SG for that path). 993 3.3.4 ASP Version Control 995 If a ASP Up message with an unknown version is received, the receiving 996 end will respond with an Error message. This will indicate to the 997 sender which version the receiving node supports. 999 This is useful when protocol version upgrades are being performed. A 1000 node with the newer version should support the older versions used on 1001 other nodes it is communicating with. 1003 The version field in the Error message header associated with the will 1004 indicate the version supported by the node. 1006 3.3.5 ASP Inactive 1008 When a ASPIA message is received, message transmission to that ASP ceases. 1009 The SG will either discard all incoming messages or start buffering the 1010 incoming messages for N seconds after which messages will be discarded. 1012 If the ASP is down, all of the Paths that were supported by that ASP 1013 are, by default, down. 1015 3.3.6 ASP Active 1017 When a ASP Active (ASPAC) message is received, the SG will start routing 1018 to that ASP. Reception of a ASPAC message overrides any previous ASPAC 1019 messages and results in the ASP associated with the ASPAC message to 1020 become the newly active ASP. 1022 4.0 Examples of MTP2 User Adaptation (M2UA) Procedures 1024 4.1 Establishment of associations between SG and MGC examples 1026 An example of the message flows for establishing active associations between 1027 SG and MGC is shown below. 1029 SG ASP1 1031 <----------- ASP Up 1032 ASP Up ----------> 1033 (ACK) 1034 <----------- ASP Active 1035 ASP Active ----------> 1036 (ACK) 1038 An example of message flows for establishment of associations with two 1039 ASPs and the message flows for take-over of the primary (ASP1) by the 1040 secondary (ASP2). 1042 SG ASP1 ASP2 1044 <----------- ASP Up 1045 ASP Up ----------> 1046 (ACK) 1047 <------------------------------ ASP Up 1048 ASP Up ------------------------------> 1049 (ACK) 1050 <----------- ASP Active 1051 ASP Active ----------> 1052 (ACK) 1053 ... 1055 <----------- ASP Inactive 1056 ASP Inactive ----------> 1057 (ACK) 1059 (this message is optional) 1060 ASP Inactive ------------------------------> 1061 <------------------------------ ASP Active 1062 ASP Active ------------------------------> 1063 (ACK) 1065 4.2 MTP Level 2 / MTP Level 3 Boundary Examples 1067 4.2.1 SS7 Link Alignment 1069 The MGC can request that a SS7 link be brought into alignment using the 1070 normal or emergency procedure. An example of the message flow to bring 1071 a SS7 link in-service using the normal alignment procedure is shown 1072 below. 1074 SG MGC 1076 <----------- Establish Request (ESTABLISH_START) 1077 Establish Response ----------> 1079 An example of the message flow to bring a SS7 link in-service using the 1080 emergency alignment procedure. 1082 SG MGC 1084 <----------- Establish Request (ESTABLISH_EMER) 1085 Establish Response ----------> 1086 4.2.2 SS7 Link Release 1088 The MGC can request that a SS7 link be taken out-of-service. It uses 1089 the Release Request message as shown below. 1091 SG MGC 1093 <------------ Release Request (RELEASE_MGMT) 1094 Release Response ------------> 1096 The SG can autonomously indicate that a SS7 link has gone out-of-service 1097 as shown below. 1099 SG MGC 1101 Release Indication ------------> 1102 (RELEASE_PHYS) 1104 4.2.3 Set and Clear Local Processor Outage 1106 to be added 1108 4.2.4 Notification of Processor Outage (local or remote) 1110 to be added 1112 4.2.5 Flush Buffers or Continue 1114 to be added 1116 4.2.6 SS7 Link Changeover 1118 An example of the message flow for a changeover is shown below. 1120 SG MGC 1122 <---------- Retrieval Request (MTP2_RTRV_BSN) 1123 Retrieval Confirm ----------> 1124 (with BSN) 1125 <---------- Retrieval Request (MTP2_RTRV_MSGS 1126 with FSN) 1127 Retrieval Confirm ----------> 1129 Retrieval Ind -----------> 1130 Retrieval Ind -----------> 1131 Rtrvl Complete Ind ----------> 1133 Note: The number of Retrieval Indication is dependent on the number of 1134 messages in the retransmit queue that have been requested. Only one 1135 Retrieval Complete Indication should be sent. 1137 4.3 Layer Management Communication Examples 1139 An example of the message flows for communication between Layer Manage- 1140 ment modules between SG and MGC is shown below. An active association 1141 between MGC and SG is established (section 4.1) prior to the following 1142 message flows. 1144 SG MGC 1146 <----------- Establish Request 1147 Error ----------> 1148 (Invalid Interface Id) 1150 5.0 Security 1152 SCN adaptation layers rely on SCTP to provide security. 1154 6.0 Acknowledgements 1156 The authors would like to thank commenters for their valuable comments and 1157 suggestions. 1159 7.0 References 1161 [1] ITU-T Recommendation Q.700, 'Introduction To ITU-T Signalling 1162 System No. 7 (SS7)' 1164 [2] ITU-T Recommendation Q.701-Q.705, 'Signalling System No. 7 (SS7) - 1165 Message Transfer Part (MTP)' 1167 [3] Bellcore GR-246-CORE 'Bell Communications Research Specification 1168 of Signaling System Number 7', Volume 1, December 1995 1170 [4] Framework Architecture for Signaling Transport, draft-ietf-sigtran- 1171 framework-arch-03.txt, June 1999 1173 [5] Signaling Common Transport Protocol, draft-ietf-sigtran-sctp-00.txt, 1174 August 1999 1176 [6] Media Gateway Control Protocol (MGCP), draft-huitema-megaco-mgcp- 1177 v1-03.txt, August 1999 1179 8.0 Author's Addresses 1181 Ken Morneault Tel: +1-703-484-3323 1182 Cisco Systems Inc. EMail: kmorneau@cisco.com 1183 13615 Dulles Technology Drive 1184 Herndon, VA. 20171 1185 USA 1187 Malleswar Kalla Tel: +1-973-829-5212 1188 Telcordia Technologies EMail: kalla@research.telcordia.com 1189 MCC 1J211R 1190 445 South Street 1191 Morristown, NJ 07960 1192 USA 1194 Greg Sidebottom Tel: +1-613-763-7305 1195 Nortel Networks EMail: gregside@nortelnetworks.com 1196 3685 Richmond Rd, 1197 Nepean, Ontario 1198 Canada K2H5B7 1200 This Internet Draft expires April 2000.