idnits 2.17.1 draft-ong-rsgp-ss7-info-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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 4) being 67 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 22 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 22 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 41 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 92 has weird spacing: '... |Data e...' -- 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. 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? 'RFC 1826' on line 867 looks like a reference -- Missing reference section? '1827' on line 867 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES FEB 1999 INTERNET DRAFT 2 Internet Draft Matt Holdrege 3 Aug 1998 Ascend Communications 4 Jiri Matousek 5 Lyndon Ong 6 Bay Networks 8 Reliable Signaling Gateway Protocol (RSGP) 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net, ftp.nis.garr.it 26 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), 27 or ftp.isi.edu (US West Coast). 29 Abstract 31 This memo describes a combined message set and function set for the 32 Control Protocol used between a Network Access Server (NAS) and a 33 Signaling Gateway (SG), based on the ASP and RSGCP drafts previously 34 submitted [asp, rsgcp]. The Control Protocol supports Call Control, 35 Circuit Maintenance and Resource Management. 37 Table of Contents 38 1. Overview.................................................1 39 2. Bearer Services..........................................2 40 3. Messages and Coding......................................3 41 4. Protocol Procedures......................................9 42 5. Detailed Procedures.....................................15 43 6. Transport...............................................16 44 7. Security Considerations.................................16 45 8. Message Flow Examples...................................16 46 9. Acronyms................................................21 47 10. Authors' Contact Information............................22 48 11. References..............................................22 50 1.0 Overview 52 This document defines a protocol for interface between a Signaling 53 Gateway (SG) and Network Access Server (NAS), which serves to 54 integrate Internet access and the Public Switched Telephone Network 55 (PSTN) using Signaling System 7 (SS7). 56 The SG has two fundamental interfaces. One is to the SS7 network 57 speaking standard SS7 protocols as defined in the ITU-T Q.700 series. 59 The other interface is TCP/IP speaking to the SG's defined NAS 60 population. This document describes the protocol that is carried 61 between the SG and the NAS. 63 Since there is no existing protocol that fits the requirements 64 completely, a new protocol has been derived from the ITU-T protocol 65 Q.931. Q.931 has the following advantages: 66 -- it is a very reliable protocol that has been used for many years 67 for ISDN call control, and is used for call control in H.323 68 -- Q.931 has well defined procedures and a message set that is 69 extensible to allow additional functionality to be added easily. 70 -- Q.931 has already been incorporated into NAS's to support ISDN, 71 minimizing the modifications required to implement a new Control 72 Protocol. A subset is also used in H.323 for call setup between 73 voice or multimedia over IP systems. 75 The following diagram shows the use of the SS7 Gateway and the RSGP 76 for interworking of SS7 and Internet. 78 ........................ ...... 79 . . . 80 . +------+ . . +-------+ 81 . SS7 | / | . SS7 . | SS7 | 82 . Network | STP |------------|Gateway| 83 . /| / | . . +-------+ 84 . / +------+ . . | 85 .........../.../........ . R| 86 / / . S| I 87 __________ / / A-link . G| n 88 / / . P| t 89 / / . | e 90 +------+ +------+ . +-----+ r 91 | PSTN | | PSTN |-----TDM---------------| NAS |-------n 92 | SCP | |Switch|-----------------------| |Data e 93 +------+ +------+ Circuits . +-----+ t 94 . 95 . 97 Figure 1: SS7-Internet Interworking for Call Setup 99 It is assumed that the implementer has access to the Q.931 protocol 100 specification as well as an understanding of SS7 messages. 102 2.0 Bearer Services 104 The following describes the bearer services and interface configura- 105 tions that are supported from the Q.931 specification. 107 Bearer Services 108 Four (4) bearer services are supported in the Control Protocol: 109 1. Circuit Mode, 64-kbps, 8-khz structured, Speech 110 2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio 111 3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 112 Transmission-Rate Adapted from 56-kbps 113 4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital 114 Transmission 116 Circuit Mode, 64-kbps, 8-khz structured, Speech The speech present at 117 the inter-machine trunk is coded by the standardized Mu-law or a-law 118 pulse code modulation (PCM) technique specified by CCITT 119 Recommendation G.711. 121 Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio The 3.1-khz 122 audio signal present at the inter-machine trunk is coded by the 123 standardized Mu-law or a-law PCM technique specified by CCITT 124 Recommendation G.711. 126 Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 127 Transmission-Rate Adapted from 56-kbps An information transfer rate 128 of 56-kbps over a B channel is possible by rate adapting the user 129 data rate of 56-kbps to 64-kbps. The transmitting side shall set bit 130 eight (8) of each byte on the B-channel to a binary one, while the 131 other bits are populated from the 56 kbps data stream. Conversely, 132 the receiving side shall ignore the eighth bit of each byte. 134 Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 135 Transmission This bearer service is used to originate and terminate 136 circuit-mode data calls at 64-kbps. 138 Interface Configuration: The Control Protocol is considered non- 139 facility associated signaling, where the signaling for specific B- 140 channels occur over a different physical facility. The bearer 141 channels are carried over inter machine trunks which are connected 142 between NAS units and central office exchanges. The control channel 143 is carried over an IP network. 145 3. Messages and Coding 147 3.1 Message Set 149 This section defines the messages the SG and NAS use for call 150 processing, maintenance, and management. Messages for call processing 151 are based on the ITU-T Recommendation Q.931 message set, and in most 152 cases use the standard Q.931 information elements and codings. 153 The call processing message set consists of: 155 Function Message Value 157 setup confirm CONNECT 0x07 158 optional CONNECT ACKNOWLEDGE 0x0f 159 optional DISCONNECT 0x45 160 release request RELEASE 0x4d 161 release confirm RELEASE COMPLETE 0x5a 162 call reset request RESTART 0x46 163 call reset confirm RESTART ACKNOWLEDGE 0x4e 164 setup request SETUP 0x05 165 status confirm STATUS 0x7d 166 status request STATUS ENQUIRY 0x73 167 data request/confirm FACILITY 0x62 169 The following messages are required for supporting voice connections, 170 in addition to connections for remote access: 172 call progress ALERTING 0x01 173 tones and announcements PROGRESS 0x03 174 New messages have been added to support registration and resource 175 management functions between the SG and NAS. These messages are 176 sent with Protocol Discriminator set to 0x43 (Maintenance). The new 177 messages are as follows: 179 Function Message Value 181 initialize request NAS STATUS 0x7f 182 initialize confirm NAS STATUS ACKNOWLEDGE 0x7f 183 continuity result CONTINUITY 0x11 184 result confirm CONTINUITY ACKNOWLEDGE 0x13 185 resource register req RESOURCE STATUS 0x1f 186 resource register conf RESOURCE STATUS ACKNOWLEDGE 0x17 187 action request SERVICE 0x0f 188 action confirm SERVICE ACKNOWLEDGE 0x07 190 3.2 Message Contents 192 Contents of standard Q.931 call control messages used in RSGP are 193 not shown in this document for brevity. The contents are a subset 194 of those used in the ITU-T Recommendation Q.931 specification. 196 The locking shift procedure of Q.931 is used with new information 197 elements in order to indicate an information element not defined in 198 ITU-T Recommendation Q.931. 200 3.2.1 CONTINUITY 202 The CONTINUITY message shall be formatted as shown: 204 Information Element Direction Inclusion Condition Length 206 Protocol Discriminator NAS -> SG Mandatory 1 208 Call Reference NAS -> SG Mandatory 3 210 Message Type NAS -> SG Mandatory 1 212 Channel Identification NAS -> SG Mandatory 4-* 214 Locking Shift (codeset 7) NAS -> SG Mandatory 1 216 Continuity Indicator NAS -> SG Mandatory 3 218 The CONTINUITY message is used by the NAS to indicate the outcome of 219 a continuity test. 221 3.2.2 CONTINUITY ACKNOWLEDGE 223 Information Element Direction Inclusion Condition Length 225 Protocol Discriminator SG -> NAS Mandatory 1 227 Call Reference SG -> NAS Mandatory 3 229 Message Type SG -> NAS Mandatory 1 231 Channel Identification SG -> NAS Mandatory 4-* 232 The CONTINUITY ACKNOWLEDGE message is used by the SG to acknowledge 233 the receipt of a CONTINUITY message from the NAS. 235 3.2.3 RESOURCE STATUS 237 The RESOURCE STATUS message shall be formatted as shown below: 239 Information Element Direction Inclusion Cond. Length 241 Protocol Discriminator NAS -> SG Mandatory 1 243 Call Reference NAS -> SG Mandatory 3 245 Message Type NAS -> SG Mandatory 1 247 Locking Shift (codeset 7) NAS -> SG Mandatory 1 249 Interface Status NAS -> SG Optional 7+ 251 Resource NAS -> SG Optional 7+ 253 The RESOURCE STATUS message is sent by the NAS to register associated 254 interface and user port resources with the SG. 256 3.2.4 RESOURCE STATUS ACKNOWLEDGE 258 The RESOURCE STATUS ACKNOWLEDGE message shall be formatted as shown 259 below: 261 Information Element Direction Inclusion Cond. Length 263 Protocol Discriminators SG -> NAS Mandatory 1 265 Call Reference SG -> NAS Mandatory 3 267 Message Type SG -> NAS Mandatory 1 269 The RESOURCE STATUS ACKNOWLEDGE message is sent by the SG to acknowledge 270 confirmation of a resource registration. The RESOURCE STATUS ACKNOWLEDGE 271 message is not part of the basic Q.931 message set. 273 3.2.5 SERVICE 275 The SERVICE message shall be formatted as shown below: 277 Information Element Direction Inclusion Cond. Length 279 Protocol Discriminator BOTH Mandatory 1 281 Call Reference BOTH Mandatory 3 283 Message Type BOTH Mandatory 1 285 Channel Identification BOTH Mandatory 4-* 287 Locking Shift (codeset 7) BOTH Mandatory 1 289 Change Status BOTH Mandatory 3 290 The SERVICE message is sent by the SG or to request a change in interface 291 or channel status. 293 3.2.6 SERVICE ACKNOWLEDGE 295 The SERVICE ACKNOWLEDGE message shall be formatted as shown below: 297 Information Element Direction Inclusion Cond. Length 299 Protocol Discriminator BOTH Mandatory 1 301 Call Reference BOTH Mandatory 3 303 Message Type BOTH Mandatory 1 305 Channel Identification BOTH Mandatory 4-* 307 Locking Shift (codeset 7) BOTH Mandatory 1 309 Change Status BOTH Mandatory 3 311 The SERVICE ACKNOWLEDGE message is sent by either the SG or the NAS 312 to indicate that the state of the specified interface or channel has 313 been changed. 315 The Change Status and Channel Identification IE's should be 316 equivalent to the corresponding values sent in the SERVICE Message. 318 3.2.7 NAS STATUS 320 The NAS STATUS message shall be formatted as shown below: 322 Information Element Direction Inclusion Cond. Length 324 Protocol Discriminator BOTH Mandatory 1 326 Call Reference BOTH Mandatory 3 328 Message Type BOTH Mandatory 1 330 Locking Shift (codeset 7) BOTH Mandatory 1 332 NAS Status BOTH Mandatory 3 334 The NAS STATUS message is used to notify the remote end of a change in 335 status, such as NAS logon from a cold start, or NAS shutdown. The 336 receiving end replies with NAS STATUS ACKNOWLEDGE. 338 3.2.8 NAS STATUS ACKNOWLEDGE 340 The NAS STATUS ACKNOWLEDGE message shall be formatted as shown below: 342 Information Element Direction Inclusion Cond. Length 344 Protocol Discriminator BOTH Mandatory 1 346 Call Reference BOTH Mandatory 3 348 Message Type BOTH Mandatory 1 350 Cause BOTH Mandatory 1 352 The NAS STATUS ACKNOWLEDGE message is sent to confirm receiving 353 the NAS STATUS message. 355 3.3 Information Element Coding 357 Information Elements unchanged from ITU-T Q.931 are not re- 358 defined here for brevity. 360 The following new Information Elements are defined: 362 Information Element IE Identifier 364 Change Status 05 365 Continuity Indicator 07 366 Interface Status 04 367 NAS Status 02 368 Resource 03 370 The following existing Information Elements have additional 371 codepoints allocated: 373 Cause 375 3.3.1 Change Status 377 The format of the Change Status information element is as follows: 379 +---+---------------------------+ 380 | 0 | 0 0 0 0 1 0 1 | IE Identifier 381 +---+---------------------------+ 382 | Information Element Length | 383 +---+---------------+-----------+ 384 | 1 | 0 0 0 0 | Status | 385 +---+---------------+-----------+ 387 Status: 388 000 In Service 389 001 Loop Back 390 010 Out of Service 391 011 Request Continuity Check 392 100 Graceful Shutdown 393 else spare 395 3.3.2 Continuity Indicator 397 The format of the Continuity Indicator information element is as follows: 399 +---+---------------------------+ 400 | 0 | 0 0 0 0 1 1 1 | IE Identifier 401 +---+---------------------------+ 402 | Information Element Length | 403 +---+-----------------------+---+ 404 | 1 | 0 0 0 0 0 0 | C | 405 +---+-----------------------+---+ 407 C: Continuity Result 408 0 Continuity Check failed 409 1 Continuity Check successful 411 3.3.3 Interface Status 413 The format of the Resource information element is as follows: 415 +---+---------------------------+ 416 | 0 | 0 0 0 0 1 0 0 | IE Identifier 417 +---+---------------------------+ 418 | Information Element Length | 419 +---+---------------------------+ 420 | 1 | Interface | 421 +---+-------------------+-------+ 422 | 1 | 0 0 0 0 0 | State | 423 +---+-------------------+-------+ 424 | 1 | Channel Count | 425 +---+-----------+---------------+ 426 | Chan 1 State | Chan 2 State | 427 +---------------+---------------+ 428 | Chan 3 State | Chan 4 State | 429 +---------------+---------------+ 431 Interface: 432 Binary Interface number 434 State: 435 00 reserved 436 01 Maintenance (loopback) 437 10 Out of service (down) 438 11 In service (up) 440 Channel Count: 441 Binary count of channels supported by this interface 443 Channel State: 444 0000 Reserved/Filler 445 0001 Unavailable - blocked 446 0010 Call in progress 447 0011 Idle - no existing calls 448 other spare 450 3.3.4 NAS Status 452 The format of the NAS Status information element is as follows: 454 +---+---------------------------+ 455 | 0 | 0 0 0 0 0 1 0 | IE Identifier 456 +---+---------------------------+ 457 | Information Element Length | 458 +---+-------------------+-------+ 459 | 1 | 0 0 0 0 0 | State | 460 +---+-------------------+-------+ 462 State: 463 00 Cold start: NAS reboot 464 01 Warm start: NAS reestablishing connectivity to SG 465 10 Hot shutdown: NAS will disconnect abruptly, terminate all calls 466 11 Soft shutdown: NAS will shutdown when all calls have terminated 468 3.3.5 Resource 470 The format of the Resource information element is as follows: 472 +---+---------------------------+ 473 | 0 | 0 0 0 0 0 1 1 | IE Identifier 474 +---+---------------------------+ 475 | Information Element Length | 476 +---+-----------+---------------+ 477 | 1 | Category | State | 478 +---+-----------+---------------+ 479 | 1 | Capacity | 480 +---+---------------------------+ 482 Category: 483 001 Modems 484 010 HDLC Channels 485 other spare 487 State: 488 0001 Available 489 other spare 491 Capacity: 492 Binary count of resources 494 3.3.6 Cause 496 The following new Cause information element codings are included: 498 125 NAS registered for calls 499 126 NAS registered for incoming and outgoing calls 500 127 NAS registration rejected 502 4. Protocol Procedures 504 This section describes the protocol procedures required for call 505 processing and resource management in RSGP. 507 Timers are defined in ITU-T Q.931 and are not re-defined here for 508 brevity. 510 4.1 Call Scenarios 512 The call scenarios defined in this section provide examples of the 513 main procedures used in the protocol, but do not describe all possible 514 cases. For more detailed information, see ITU-T Recommendation Q.699. 516 4.1.1 Network Initiated Call Origination 518 4.1.1.1 IAM Initiated with No COT Required 520 This scenario describes the signaling that proceeds when a call is 521 initiated by the reception of an IAM from the SS7 network and a 522 continuity test is not required. 524 * When the SG receives an IAM from the SS7 network, the Nature of 525 Connection indicators shall be examined to determine if COT is 526 required on the specified circuit. If COT is not required, the SG 527 shall send a SETUP message to the NAS. 529 * Once the NAS has determined that the call can be completed and the 530 specified channel has been connected to the called party, it shall 531 send a CONNECT message to the SG. 533 * Upon receipt of the CONNECT message, the SG shall send an ANM 534 message to the SS7 network, and may optionally send a CONNECT ACK- 535 NOWLEDGE message to the NAS. 537 4.1.1.2 IAM Initiated with Continuity Check Required 539 This scenario describes the signaling that proceeds when a call is 540 initiated by the reception of an IAM from the SS7 network and a 541 continuity test is required. 543 * When the SG receives an IAM from the SS7 network, the Nature of 544 Connection indicators shall be examined to determine if COT is 545 required on the specified circuit. If COT is required, the SG shall 546 send a SERVICE message to the NAS indicating that the specified 547 circuit should be placed in a loopback mode, and start timer Tserv. 549 * When the NAS receives the SERVICE message indicating the specified 550 circuit should be placed in loopback mode, the circuit shall be 551 marked as busy, placed in a loopback mode, and a SERVICE ACKNOWLEDGE 552 message indicating the circuit was successful placed in a loopback 553 mode, shall be sent to the SG. 555 * When the SG receives the SERVICE ACKNOWLEDGE message indicating the 556 circuit was successfully placed in a loopback mode, timer Tserv shall 557 be stopped. 559 * When the SG receives a COT message from the SS7 network indicating 560 the continuity test was successful, the SG shall send a SETUP message 561 to the NAS. 563 * Once the NAS has determined that the call can be completed and the 564 specified channel has been connected to the called party, it shall 565 send a CONNECT message to the SG. 567 * Upon receipt of the CONNECT message, the SG shall send an ANM 568 message to the SS7 network, and may optionally send a CONNECT ACK- 569 NOWLEDGE message to the NAS. 571 4.1.1.3 IAM Initiated with Continuity Check on Previous Circuit Required 573 This scenario describes the signaling that proceeds when a call is 574 initiated by the reception of an IAM from the SS7 network that 575 specifies a continuity test on a previous circuit is required. 577 * When the SG receives an IAM from the SS7 network, the Nature of 578 Connection indicators shall be examined to determine if continuity 579 check is required. If continuity check is required on a previous 580 circuit, then the SG does not send a SETUP message until a COT 581 is received indicating continuity check successful. 583 * Once the NAS has determined that the call can be completed and the 584 specified channel has been connected to the called party, it shall 585 send a CONNECT message to the SG. The NAS shall start timer T313 when 586 the CONNECT message is sent. 588 * Upon receipt of the CONNECT message, the SG shall send a CONNECT 589 ACKNOWLEDGE message to the NAS. 591 * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop 592 timer T313. 594 4.1.2 Call Clearing 596 4.1.2.1 Network Initiated Call Clearing 598 This scenario describes the signaling that proceeds when a call 599 clearing is initiated by the SS7 network. 601 * Call clearing is initiated by the SS7 network when a REL is 602 received by the SG from the SS7 network. When the SG receives a REL 603 from the SS7 network, a corresponding RELEASE message shall be 604 sent to the NAS, and timer T308 shall be initiated. 606 * When the NAS receives a RELEASE message the associated circuit 607 shall be disconnected, and a RELEASE COMPLETE shall be sent to the SG. 609 * When the SG receives the RELEASE COMPLETE message timer T308 shall 610 be stopped, the channel shall be released, and the call reference 611 shall be released. 613 * The NAS shall also be capable of receiving a DISCONNECT message 614 from the SG, in which case the procedures in Section 4.1.2.2 are 615 followed. 617 4.1.2.2 NAS Initiated Call Clearing 619 This scenario describes the signaling that proceeds when a call 620 clearing is initiated by the NAS. 622 * When the NAS detects that an active call has been terminated by the 623 local subscriber, the NAS shall disconnect the associated circuit, 624 send a RELEASE message to the SG, and initiate timer T308. 626 * When the SG receives the RELEASE message, a RLS message shall be 627 sent out to the SS7 network, the circuit and call reference shall be 628 released, and a RELEASE COMPLETE shall be sent to the NAS. 630 * When the NAS receives the RELEASE COMPLETE message timer T308 shall 631 be stopped. 633 * The SG shall be capable of receiving a DISCONNECT message from the 634 NAS, in which case the procedures in section 4.1.2.1 are followed. 636 4.1.3 Call Failures and CCR 638 * message timer Tserv shall be stopped and a RLC shall be sent out to 639 the SS7 network. 641 4.1.3.1 IAM Initiated with Continuity Check on Previous Circuit Failed 643 This scenario describes the signaling that proceeds when a call is 644 initiated by the reception of an IAM from the SS7 network that 645 specifies a continuity test on a previous circuit is required and 646 consequently the continuity test fails. 648 * When the SG receives an IAM from the SS7 network, the Nature of 649 Connection indicators shall be examined to determine if COT is 650 required on the specified circuit, or on a previous circuit. If COT 651 is required on a previous circuit, the SG delays sending SETUP 652 out to the NAS. 654 * When the SG receives a REL message from the SS7 network, which 655 indicates the continuity test failed, the SG releases the circuit 656 and call without sending an indication to the NAS. 658 4.2 Management Procedures 660 4.2.1 Registration 662 This scenario describes the message flow that proceeds when a NAS 663 unit registers the available hardware interfaces. 665 * When the NAS detects that a resource has changed operational 666 states, a RESOURCE STATUS message is sent to the SG and Timer T350 shall 667 be initiated. Multiple RESOURCE STATUS messages may be send to carry 668 information about the interface status and resource status. 670 * When the SG receives the RESOURCE STATUS message, the indicated 671 resource states are updated and a RESOURCE STATUS ACKNOWLEDGE is 672 sent to the NAS. The Resource information elements in the 673 RESOURCE STATUS ACKNOWLEDGE must be identical to those received in 674 the original RESOURCE STATUS message. 676 * When the NAS receives the RESOURCE STATUS ACKNOWLEDGE message, timer 677 T350 shall be stopped. 679 4.2.2 Registration - T350 Timeout 681 This scenario describes the message flow that proceeds when a timeout 682 of Timer T350 occurs after the NAS has initiated registration of the 683 available hardware interfaces. It is important to note that the NAS 684 should continue to re-send the RESOURCE STATUS message and restart Timer 685 T350 until a corresponding RESOURCE STATUS ACKNOWLEDGE is received. 687 * When the NAS detects that a resource has changed operational 688 states, a RESOURCE STATUS message is sent to the SG and Timer T350 shall 689 be initiated. 691 * When Timer T350 expires on the NAS, the NAS shall re-send the 692 RESOURCE STATUS message and restart timer T350. 694 * When the SG receives the RESOURCE STATUS message, the indicated 695 resource states are updated and a RESOURCE STATUS ACKNOWLEDGE is 696 sent to the NAS. 698 * When the NAS receives the RESOURCE STATUS ACKNOWLEDGE message, timer 699 T350 shall be stopped. 701 4.2.3 SG Initiated Restart 703 This scenario describes the message flow that proceeds when a Restart 704 Request is initiated by the SG. 706 * When the SG initiates restart, it sends a RESTART message to the NAS and 707 timer T317 is initiated. 709 * When the NAS receives a RESTART message from the SG, the specified 710 interface or channel shall be restarted and a RESTART 711 ACKnowledgment shall be sent to the SG. 713 * When the SG Control Protocol receives a RESTART ACKNOWLEDGE from 714 the NAS, timer T317 shall be stopped. 716 4.2.4 NAS Initiated Restart 718 This scenario describes the message flow that proceeds when a RESTART 719 message is received by the SG Control Protocol from the NAS. 721 * If the NAS determines that a restart of a single DS0, or an entire 722 interface is necessary, a RESTART message shall be sent to the SG and 723 timer T317 shall be initiated. 725 * When the SG Control Protocol receives a RESTART message from the 726 NAS, a Restart Indication primitive shall be sent to the call control 727 and a RESTART ACKNOWLEDGE shall be sent to the NAS. 729 * When the NAS receives a RESTART ACKNOWLEDGE from the SG, timer 730 T317 shall be stopped, and the associated equipment shall be 731 restarted. 733 4.2.5 Service Message Procedures 734 The Service message is used to initiate circuit management procedures 735 at the NAS or Gateway for functions such as circuit blocking and loop 736 back (prior to remote continuity check). The procedures are as follows: 738 * When the SG or NAS initiates a Service procedure, it sends the Service 739 message and initiates timer Tserv. 741 * When the initiating SG or NAS receives the Service Acknowledge message, 742 timer Tserv is stopped. 744 * The following tables describe the detailed procedures for the NAS 745 in response to receipt of a Service message from the SG: 747 +------------+--------------------------+-------------------------+ 748 | | Interface Specified | Channel Specified | 749 +------------+--------------------------+-------------------------+ 750 | In Service | The NAS will attempt to | The NAS will mark the | 751 | | bring the T1/E1 into ser-| channel as available. | 752 | | vice. The NAS will | Established calls will | 753 | | respond with 'Out of | not be affected. | 754 | | Service' if the T1/E1 is | | 755 | | down (not framing). | | 756 +------------+--------------------------+-------------------------+ 757 | Loop Back | The T1/E1 will be placed | The NAS will place the | 758 | | into loopback. All esta-| DS0 into loopback state | 759 | | blished calls will be | if there is no esta- | 760 | | torn down. | blished call. The NAS | 761 | | | will respond with 'In | 762 | | | Service' if a call is | 763 | | | in progress. | 764 +------------+--------------------------+-------------------------+ 765 | Out of | The NAS will place the | The NAS will mark the | 766 | Service | T1/E1 into this state. | DS0 and tear down any | 767 | | All established calls | if there is no esta- | 768 | | will be torn down. | established calls. | 769 +------------+--------------------------+-------------------------+ 770 | Request | The NAS will reject this | The NAS will execute the| 771 | Continuity | message and send STATUS | continuity check if | 772 | Check | message. | there is no established | 773 | | | call. The NAS will res-| 774 | | | pond with 'In Service' | 775 | | | if a call is in progress| 776 +------------+--------------------------+-------------------------+ 777 | Graceful | The NAS will mark the | The NAS will mark the | 778 | Shutdown | T1/E1. It will not tear | DS0, but will not tear | 779 | (Blocking) | down any established | down any established | 780 | | calls. | calls. | 781 +------------+--------------------------+-------------------------+ 783 * Upon completion of the action specified, the NAS responds to the SG 784 with a Service Acknowledge message. 786 * The following table describes the procedures at the SG upon receipt of 787 a Service message from the NAS: 789 +------------+--------------------------+-------------------------+ 790 | | Interface Specified | Channel Specified | 791 +------------+--------------------------+-------------------------+ 792 | In Service | The NAS will send this | The NAS can send this | 793 | | message when the T1/E1 | request for Channels it | 794 | | framing is achieved. The | previously took "Out of | 795 | | Gateway should not change| Service". The Gateway | 796 | | the state of any esta- | should not change the | 797 | | blished call. | state of any | 798 | | | established call. | 799 +------------+--------------------------+-------------------------+ 800 | Loop Back | The NAS will not generate| The NAS will not gene- | 801 | | this request. The Gate- | rate this request. The | 802 | | way should respond with | Gateway should respond | 803 | | STATUS. | with STATUS. | 804 +------------+--------------------------+-------------------------+ 805 | Out of | The NAS will place the | The NAS will send this | 806 | Service | T1/E1 into this state if | message in the case of | 807 | | T1/E1 framing is lost or | modem failure. Any | 808 | | if requested by the | established call will | 809 | | operator. All esta- | be torn down. | 810 | | blished calls will be | | 811 | | torn down. | | 812 +------------+--------------------------+-------------------------+ 813 | Request | The NAS will not send | The NAS will use this | 814 | Continuity | this message. The Gate- | request as a result of | 815 | Check | way should respond with | an operator request. | 816 | | STATUS. | | 817 +------------+--------------------------+-------------------------+ 818 | Graceful | The NAS will issue this | The NAS will not issue | 819 | Shutdown | request as a result of an| this message. The Gate-| 820 | (Blocking) | operator request. Any | way should reject this | 821 | | call in progress should | message using the | 822 | | not be affected. | STATUS message. | 823 +------------+--------------------------+-------------------------+ 825 * Upon completion of the action specified, the SG responds to the NAS 826 with the Service Acknowledge message. 828 5. Detailed Procedures 830 This section provides detailed information that describes the 831 operation of the SG Control Protocol. A call progresses through 832 different states as various events occur, and this section describes 833 how the SG and NAS should process calls in each state. The table 834 below shows the call states that apply to the SG Control Protocol. 836 State Name Value 837 Null 0 838 Call Initiated 1 839 Call Present 6 840 Connect Request 8 841 Active 10 842 Disconnect Request 11 843 Disconnect Indication 12 844 Release Request 19 846 Additional procedures to be provided. 848 6. Transport 850 Detailed procedures to be provided. 852 Additional procedures may be added, for example, in order to monitor 853 performance of the connection between NAS and SG, and initiate recovery 854 procedures if it is determined that the connection has failed. 856 7. Security Considerations 858 SS7 protocol does not support internal authentication and encryption 859 functions. This is taken into consideration in current SS7 860 networks. Signaling gateways should be designed to protect the SS7 861 network and should employ thoughtful thresholds to make sure a NAS or 862 malicious intermediate entity cannot adversely affect the SS7 network 863 or any SS7 connected nodes. 865 If the network operator wishes to add IP level security functions it is 866 recommended but not required that the TCP/IP link from the NAS to the SG 867 be protected by IPsec AH and ESP [RFC 1826, 1827]. In the case that 868 the physical network between the NAS and SG is private, such security 869 techniques are optional. In the case that the network used is 870 shared with other applications and/or nodes, IPsec security is 871 strongly recommended. This is to prevent Denial of Service attacks 872 and false message attacks. 874 8. Message Flow Examples 876 8.1 NAS Registers with Gateway for Service 878 The following timing diagram shows the message flow during initial 879 NAS registration with the SG. 881 NAS Gateway 882 | | 883 | NAS STATUS (cold start) | 884 |------------------------------>| 885 | NAS STATUS ACK | 886 |<------------------------------| 887 | | 888 | | 889 | RESOURCE STATUS | 890 |------------------------------>| 891 | RESOURCE STATUS ACK | 892 |<------------------------------| 894 Note: multiple Resource Statue messages may be sent and acknowledged. 896 8.2 Gateway Originated Normal Call Setup and Release 898 The following diagram shows successful Call establishment and tear 899 down for a gateway originated call. 901 NAS Gateway 902 | | 903 | SETUP (Channel ID = n) | 904 |<------------------------------| 905 | CONNECT | 906 |------------------------------>| 907 | | 908 | RELEASE | 909 |<------------------------------| 910 | RELEASE COMPLETE | 911 |------------------------------>| 913 Note: The tear down sequence can be initiated by either the NAS or 914 by the gateway to hang-up the call. 916 8.3 NAS Originated Normal Call Setup 918 The following diagram shows successful Call establishment and tear 919 down for NAS originated calls. For NAS originated calls, the Gateway 920 selects the channel to be used in the call. 922 NAS Gateway 923 | | 924 | SETUP(channel not specified) | 925 |------------------------------>| 926 | CONNECT ( Channel ID = n ) | 927 |<------------------------------| 928 | | 929 | RELEASE | 930 |<------------------------------| 931 | RELEASE COMPLETE | 932 |------------------------------>| 934 Note: The tear down sequence can be initiated by either the NAS or 935 by the gateway to hang-up the call. Disconnection can be initiated 936 by either the DISCONNECT or RELEASE message. 938 8.4 Unsuccessful Call Establishment Sequence 940 The following sequence illustrates when a call is rejected by the 941 NAS. 943 NAS Gateway 944 | | 945 | SETUP | 946 |<------------------------------| 947 | RELEASE COMPLETE | 948 |------------------------------>| 950 8.5 Continuity check test as part of Incoming Call Setup - Success 952 The following sequence illustrates when the gateway receives an IAM 953 message indicating that a continuity test should be performed on 954 the circuit prior to the call establishment. 956 NAS Gateway 957 | | 958 | SERVICE (chan n loop back) | 959 |<------------------------------| 960 | SERVICE ACK | 961 |------------------------------>| 962 | | 963 | SETUP | 964 |<------------------------------| 965 | CONNECT | 966 |------------------------------>| 968 Per Q.699 (3.1.18) continuity checking should be performed before 969 the SETUP is sent to the terminating end-point. SERVICE message 970 from the gateway to the NAS is used to initiate the loopback. If 971 the remote end-point indicates to the gateway that the continuity 972 check succeeded, the gateway proceeds with SETUP. 974 8.6 Continuity check test as part of Incoming Call Setup - Failure 976 If the remote end indicates failure, the gateway will send SERVICE 977 message to the NAS requesting that the channel be placed into the 978 in-service state. 980 NAS Gateway 981 | | 982 | SERVICE (chan n loop back) | 983 |<------------------------------| 984 | SERVICE ACK | 985 |------------------------------>| 986 | | 987 | SERVICE (chan n in-service) | 988 |<------------------------------| 989 | SERVICE ACK | 990 |------------------------------>| 992 8.7 Continuity check test as part of Outgoing Call Setup - Success 994 The following sequence illustrates when the NAS initiates call 995 setup and the SS7 Gateway determines that continuity test should be 996 performed on the circuit prior to the call establishment. 998 NAS Gateway 999 | | 1000 | SETUP (channel not specified) | 1001 |------------------------------>| 1002 | | 1003 | SERVICE (chan n request | 1004 | continuity check) | 1005 |<------------------------------| 1006 | SERVICE ACK | 1007 |------------------------------>| 1008 | CONTINUITY | 1009 |------------------------------>| 1010 | CONTINUITY ACK | 1011 |<------------------------------| 1012 | | 1013 | CONNECT (Channel ID = n) | 1014 |<------------------------------| 1016 8.8 Continuity check test initiated by the SG operator 1018 The gateway sends a SERVICE message to initiate the continuity 1019 check. The NAS performs continuity check and reports the result 1020 using the CONTINUITY message. 1022 Not shown in this diagram is the corresponding action of the SG. 1023 Upon receipt of the Service Ack from the NAS, the SG generates a 1024 CCR message into the SS7 network, initiating loopback at the 1025 remote switch. 1027 NAS Gateway 1028 | | 1029 | SERVICE (chan n request | 1030 | continuity check) | 1031 |<------------------------------| 1032 | SERVICE ACK | 1033 |------------------------------>| 1034 | | 1035 | CONTINUITY | 1036 |------------------------------>| 1037 | CONTINUITY ACK | 1038 |<------------------------------| 1040 8.7 NAS detects bearer T1/E1 line down (LOS, Red Alarm) 1042 If the NAS detects that a particular T1/E1 line failed, it sends a 1043 SERVICE message to the gateway. Established calls will be torn down 1044 as part of normal processing - i.e the NAS modems will detect loss 1045 of connection and the NAS will disconnect the call. The gateway 1046 will request blocking of CICs associated with the particular T1/E1 1047 using an SS7 Blocking or Circuit Group Blocking Message. 1049 NAS Gateway 1050 | | 1051 | SERVICE (i/f 1 out-of-service)| 1052 |------------------------------>| 1053 | SERVICE ACK | 1054 |<------------------------------| 1056 8.8 Individual bearer channel taken out-of-service by NAS 1058 NAS Gateway 1059 | | 1060 | SERVICE(chan n out-of-service)| 1061 |------------------------------>| 1062 | SERVICE ACK | 1063 |<------------------------------| 1065 8.9 Individual bearer channel taken out-of-service by Gateway 1066 operator 1068 NAS Gateway 1069 | | 1070 | SERVICE(chan n out-of-service)| 1071 |<------------------------------| 1072 | SERVICE ACK | 1073 |------------------------------>| 1075 8.10 Bearer T1/E1 trunk abrupt shutdown initiated by Gateway 1076 operator 1078 NAS Gateway 1079 | | 1080 | SERVICE (i/f n out-of-service)| 1081 |<------------------------------| 1082 | SERVICE ACK | 1083 |------------------------------>| 1085 8.11 Bearer T1/E1 trunk abrupt shutdown initiated by NAS 1087 NAS Gateway 1088 | | 1089 | SERVICE (i/f n out-of-service)| 1090 |------------------------------>| 1091 | SERVICE ACK | 1092 |<------------------------------| 1094 8.12 Bearer T1/E1 trunk graceful shutdown initiated by Gateway 1095 operator 1097 NAS Gateway 1098 | | 1099 | SERVICE (i/f n graceful shutdown) | 1100 |<----------------------------------| 1101 | SERVICE ACK | 1102 |---------------------------------->| 1104 8.13 Bearer T1/E1 trunk graceful shutdown initiated by NAS 1106 NAS Gateway 1107 | | 1109 | SERVICE (i/f n graceful shutdown) | 1110 |---------------------------------->| 1111 | SERVICE ACK | 1112 |<----------------------------------| 1114 9. Acronyms 1116 ANM Answer Message 1118 SG Signaling Gateway 1120 CCR Continuity Check Request 1122 COT Continuity 1124 CPE Customer Premises Equipment 1126 IAM Initial Address Message 1128 IE Information Element 1130 IP Internet Protocol 1132 ISDN Integrated Services Digital Network 1134 ISP Internet Service Provider 1136 ISUP ISDN User Part 1138 MTP Message Transfer Part 1140 NAS Network Access Server 1142 PCM Pulse Code Modulation 1144 PSTN Public Switched Telephone Network 1146 SCP Service Control Point 1148 STP Signal Transfer Point 1150 SS7 Signaling System Number 7 1152 UL Upper Layer 1154 10. Authors Addresses 1156 Matt Holdrege Lyndon Ong Jiri Matousek 1157 1701 Harbor Bay Pkwy 4401 Gt America Pkwy 5 Federal Street 1158 Alameda, CA 94502 Santa Clara, CA 95054 Billerica, MA 01821 1159 matt@ascend.com long@baynetworks.com jiri@baynetworks.com 1161 11. References 1163 [asp] Bay Networks SS7-Internet Access Signaling Protocol, , work in progress 1166 [rsgcp] Reliable Signaling Gateway Control Protocol (RSGCP), , work in progress 1169 Q.931 ITU-T Recommendation Q.931 DIGITAL SUBSCRIBER SIGNALLING SYSTEM 1170 No. 1 (DSS 1) - ISDN USER-NETWORK INTERFACE LAYER 3 SPECIFICATION FOR BASIC 1171 CALL CONTROL 1173 Q.699 ITU-T Recommendation Q.699 Interworking between ISDN access and 1174 non-ISDN access over ISDN User Part of Signalling System No. 7 1176 Full Copyright Statement 1178 Copyright (C) The Internet Society (1998). All Rights Reserved. 1180 This document and translations of it may be copied and furnished to 1181 others, and derivative works that comment on or otherwise explain it 1182 or assist in its implementation may be prepared, copied, published 1183 and distributed, in whole or in part, without restriction of any 1184 kind, provided that the above copyright notice and this paragraph are 1185 included on all such copies and derivative works. However, this 1186 document itself may not be modified in any way, such as by removing 1187 the copyright notice or references to the Internet Society or other 1188 Internet organizations, except as needed for the purpose of 1189 developing Internet standards in which case the procedures for 1190 copyrights defined in the Internet Standards process must be 1191 followed, or as required to translate it into languages other than 1192 English. 1193 The limited permissions granted above are perpetual and will not be 1194 revoked by the Internet Society or its successors or assigns. 1196 This document and the information contained herein is provided on an 1197 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1198 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1199 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1200 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1201 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.