idnits 2.17.1 draft-rfced-info-holdrege-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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. == There are 2 instances 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. -- 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) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT EXPIRES DEC 1998 INTERNET DRAFT 2 Internet Draft Matt Holdrege 3 June 1998 Ascend Communications 5 The Reliable Signaling Gateway Control Protocol (RSGCP) 6 draft-rfced-info-holdrege-00.txt 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstract.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net, ftp.nis.garr.it 23 (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), 24 or ftp.isi.edu (US West Coast). 26 Copyright Notice 28 Copyright (C) The Internet Society (1998). All Rights Reserved. 30 Abstract 32 This memo describes the Control Protocol used between a Network 33 Access Server (NAS) and a Signaling Gateway (SG). The requirements of 34 this protocol are Call Control, Circuit Maintenance and Resource 35 Management. This protocol must be reliable in nature and support 36 redundant links between the NAS and SG. It's important to note that 37 the NAS could be handling either packetized voice or data for access 38 to the Internet. 40 Introduction 42 A need has arisen to better integrate Internet access and the Public 43 Switched Telephone Network (PSTN). To accomplish this daunting task, 44 several new techniques are being developed. One such technique is to 45 establish communications between the main PSTN signaling network, 46 known as Signaling System 7 (SS7) and dial-in internet NAS's. This 47 allows multiple NAS access ports to collectively appear as a virtual 48 resource of a PSTN switch. Another way to look at it is that the 49 NAS's appear as a egress PSTN switch to an ingress PSTN switch. 51 The communication between the NAS and SS7 is facilitated by the SG. 52 The SG has two fundamental interfaces. One is to the SS7 network 53 speaking standard SS7 protocols as defined in the ITU-T Q.700 series. 55 I-D The Reliable Signaling Gateway Control Protocol June 1998 57 The other interface is TCP/IP speaking to the SG's defined NAS 58 population. This document describes the protocol that is carried 59 between the SG and the NAS. 61 Since there is no existing protocol that fits the requirements 62 completely, a new protocol will be derived from the ITU-T protocol 63 Q.931. Q.931 is a very reliable protocol that has been used for years 64 mainly as an ISDN call control protocol. Q.931 has well defined 65 procedures and a message set that is extensible to allow additional 66 functionality to be added easily. Additionally, Q.931 has already 67 been incorporated into NAS's minimizing the modifications required to 68 implement the new Control Protocol. 70 Due to the requirement for reliability and redundancy, a lower layer 71 protocol is defined which is similar in nature to Q.921 or the link 72 layer protocol. 74 It is assumed that the implementer has access to the Q.931 protocol 75 specification as well as an understanding of SS7 messages. 77 2.0 Bearer Services 79 Bearer Services and Interface Configuration 80 Bearer Services 81 Four (4) bearer services are supported in the Control Protocol: 82 1. Circuit Mode, 64-kbps, 8-khz structured, Speech 83 2. Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio 84 3. Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 85 Transmission-Rate Adapted from 56-kbps 86 4. Circuit Mode, 64-kbps, 8-khz structure, Unrestricted Digital 87 Transmission 89 Circuit Mode, 64-kbps, 8-khz structured, Speech The speech present at 90 the inter-machine trunk is coded by the standardized Mu-law or a-law 91 pulse code modulation (PCM) technique specified by CCITT 92 Recommendation G.711. 94 Circuit Mode, 64-kbps, 8-khz structured, 3.1-khz, Audio The 3.1-khz 95 audio signal present at the inter-machine trunk is coded by the 96 standardized Mu-law or a-law PCM technique specified by CCITT 97 Recommendation G.711. 99 Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 100 Transmission-Rate Adapted from 56-kbps An information transfer rate 101 of 56-kbps over a B channel is possible by rate adapting the user 102 data rate of 56-kbps to 64-kbps. The transmitting side shall set bit 103 eight (8) of each byte on the B-channel to a binary one, while the 104 other bits are populated from the 56 kbps data stream. Conversely, 105 the receiving side shall ignore the eighth bit of each byte. 107 Circuit Mode, 64-kbps, 8-khz structured, Unrestricted Digital 108 Transmission This bearer service is used to originate and terminate 109 circuit-mode data calls at 64-kbps. 111 I-D The Reliable Signaling Gateway Control Protocol June 1998 113 Interface Configuration The Control Protocol is considered non- 114 facility associated signaling, where the signaling for specific B- 115 channels occur over a different physical facility. The bearer 116 channels are carried over inter machine trunks which are connected 117 between NAS units and central office exchanges. The control channel 118 is carried over an IP network. 120 3.1 Format and Coding 122 3.2.1 Message Structure 124 This section defines the messages the SG and NAS use for call 125 processing, maintenance, and management. These messages are based on 126 the ITU-T Recommendation Q.931 message set, and in most cases are 127 simply specific codings of standard Q.931 messages. However, because 128 the requirements of the SG based systems differ from those of ISDN 129 access for which the Q.931 message set was developed, some messages 130 described in this section are extensions of standard Q.931 messages. 131 The Control Protocol message set consists of: 133 Message Value 135 CONNect 0x07 136 CONNect ACKnowledge 0x0f 137 CONTinuity 0x11 138 CONTinuity ACKnowledge 0x13 139 DISConnect 0x45 140 REGistration 0x1f 141 REGistration ACKnowledge 0x17 142 RELease 0x4d 143 RELease COMplete 0x5a 144 RESTart 0x46 145 RESTart ACKnowledge 0x4e 146 SERVice 0x0f 147 SERVice ACKnowledge 0x07 148 SETUP 0x05 149 STATus 0x7d 150 STATus ENQuiry 0x73 151 LOGon 0x7f 153 Of the above messages, most are standardized in ITU-T Q.931. A few 154 are added to meet the requirements of this protocol. They are: 155 CONTinuity 156 CONTinuity ACKnowledge 157 REGistration 158 REGistration ACKnowledge 159 SERVice 160 SERVice ACKnowledge 161 LOGon 163 3.2.1.1 CONTinuity 165 I-D The Reliable Signaling Gateway Control Protocol June 1998 167 The Continuity message shall be formatted as shown: 169 Information Element Direction Inclusion Condition Length 171 Protocol Discriminator NAS -> SG Mandatory 1 173 Call Reference NAS -> SG Mandatory 5 175 Message Type NAS -> SG Mandatory 1 177 Channel Identification NAS -> SG Mandatory 8 179 Continuity Indicator NAS -> SG Mandatory 3 181 The Continuity message is used by the NAS to indicate the outcome of 182 a continuity test. 184 3.2.1.2 CONTinuity ACKnowledge 186 Information Element Direction Inclusion Condition Length 188 Protocol Discriminator SG -> NAS Mandatory 1 190 Call Reference SG -> NAS Mandatory 5 192 Message Type SG -> NAS Mandatory 1 194 Channel Identification SG -> NAS Mandatory 8 196 The Continuity Acknowledge message is used by the SG to acknowledge 197 the receipt of a Continuity message from the NAS. 199 3.2.1.3 REGistration 201 The Registration message shall be formatted as shown below: 203 Information Element Direction Inclusion Cond. Length 205 Protocol Discriminator NAS -> SG Mandatory 1 207 Call Reference NAS -> SG Mandatory 5 209 Message Type NAS -> SG Mandatory 1 211 Resource NAS -> SG Mandatory 3-5 213 Channel Identification NAS -> SG Optional 7+ 215 Channel State ID NAS -> SG Optional 7+ 217 The Registration message is sent by the NAS to register associated 218 trunk and user port resources. For each Resource information element 219 that specifies a trunk resource, there must be a corresponding 220 Channel State Identification information element, immediately 222 I-D The Reliable Signaling Gateway Control Protocol June 1998 224 following. If no trunk resources are specified in the Resource 225 information element, the Channel Identification State information 226 element may be omitted. When the NAS detects both links fail between 227 the SG, if at least one link comes back up again, it will send the 228 Registration message to inform the Gateway the available resources. 229 The protocol discriminator of the Registration message is 0x43 230 (Maintenance Protocol Discriminator). 232 3.2.1.4 REGistration ACKnowledge 234 The Registration Acknowledge message shall be formatted as shown 235 below: 237 Information Element Direction Inclusion Cond. Length 239 Protocol Discriminators SG -> NAS Mandatory 1 241 Call Reference SG -> NAS Mandatory 5 243 Message Type SG -> NAS Mandatory 1 245 The Registration Acknowledge message is sent by the SG to acknowledge 246 confirmation of a resource registration. For each Resource 247 information element that specifies a trunk resource, there must be a 248 corresponding Channel State Identification information element, 249 immediately following. The Registration Acknowledge message is not 250 part of the basic Q.931 message set. The protocol discriminator of 251 the Registration Ack is 0x43 (Maintenance Protocol Discriminator). 253 3.2.1.5 SERVice 255 The Service message shall be formatted as shown below: 257 Information Element Direction Inclusion Cond. Length 259 Protocol Discriminator BOTH Mandatory 1 261 Call Reference BOTH Mandatory 5 263 Message Type BOTH Mandatory 1 265 Resource BOTH Mandatory 3 267 Channel Identification BOTH Mandatory 7+ 269 The Service message is sent by the SG to request a change in channel 270 status and by the NAS to indicate a change in channel status. 272 3.2.1.6 SERVice ACKnowledge 274 The Service ACKnowledge message shall be formatted as shown below: 276 Information Element Direction Inclusion Cond. Length 278 I-D The Reliable Signaling Gateway Control Protocol June 1998 280 Protocol Discriminator BOTH Mandatory 1 282 Call Reference BOTH Mandatory 5 284 Message Type BOTH Mandatory 1 286 Resource BOTH Mandatory 3 288 Channel Identification BOTH Mandatory 7+ 290 The Service Acknowledge message is sent by either the SG or the NAS 291 to indicate that the state of the specified channel has been changed. 292 The Change Status and Channel Identification IE's should be 293 equivalent to the corresponding values sent in the Service Message. 295 3.2.1.7 LOGon 297 The Logon message shall be formatted as shown below: 299 Information Element Direction Inclusion Cond. Length 301 Protocol Discriminator NAS -> SG Mandatory 1 303 Call Reference NAS -> SG Mandatory 5 305 Message Type NAS -> SG Mandatory 1 307 When the NAS cold restarts, it will send a LOGon message to notify 308 the SG. Then the NAS will send REGistration messages to inform the SG 309 of the available resources. The Protocol Discriminator of the Logon 310 message is 0x43 (Maintenance Protocol Discriminator). 312 Details 314 Information Elements are defined in ITU-T Q.931 and are not re- 315 defined here for brevity. 317 Timers are defined in ITU-T Q.931 and are not re-defined here for 318 brevity. 320 4. Basic Call Control 322 This section describes the basic call control capabilities required 323 for processing calls in the SG based NAS system. 325 4.1 Call Scenarios 327 4.1.1 Network Initiated Call Origination 329 4.1.1.1 IAM Initiated with No COT Required 331 This scenario describes the signaling that proceeds when a call is 332 initiated by the reception of an IAM from the SS7 network and a 333 continuity test is not required. 335 I-D The Reliable Signaling Gateway Control Protocol June 1998 337 * When the SG receives a IAM from the SS7 network, the Nature of 338 Connection indicators shall be examined to determine if COT is 339 required on the specified circuit. If COT is not required, the SG 340 shall send a SETUP message to the NAS. 342 * Once the NAS has determined that the call can be completed and the 343 specified channel has been connected to the called party, it shall 344 send a CONNECT message to the SG. The NAS shall start timer T313 345 when the CONNECT message is sent. 347 * Upon receipt of the CONNECT message, the SG shall send a CONNECT 348 ACKNOWLEDGE message to the NAS and an ANM message out to the SS7 349 network. 351 * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop 352 timer T313. 354 4.1.1.2 IAM Initiated with COT Required 356 This scenario describes the signaling that proceeds when a call is 357 initiated by the reception of an IAM from the SS7 network and a 358 continuity test is required. 360 * When the SG receives a IAM from the SS7 network, the Nature of 361 Connection indicators shall be examined to determine if COT is 362 required on the specified circuit. If COT is required, the SG shall 363 send a SERVICE message to the NAS indicating that the specified 364 circuit should be placed in a loopback mode, and start timer Tserv. 366 * When the NAS receives the SERVICE message indicating the specified 367 circuit should be placed in loopback mode, the circuit shall be 368 marked as busy, placed in a loopback mode, and a SERVICE ACKNOWLEDGE 369 message indicating the circuit was successful placed in a loopback 370 mode, shall be sent to the SG. 372 * When the SG receives the SERVICE ACKNOWLEDGE message indicating the 373 circuit was successfully placed in a loopback mode, timer Tserv shall 374 be stopped. 376 * When the SG receives a COT message from the SS7 network indicating 377 the continuity test was successful, the SG shall send a SETUP message 378 to the NAS. 380 * Once the NAS has determined that the call can be completed and the 381 specified channel has been connected to the called party, it shall 382 send a CONNECT message to the SG. The NAS shall start timer T313 when 383 the CONNECT message is sent. 385 * Upon receipt of the CONNECT message, the SG shall send a CONNECT 386 ACKNOWLEDGE message to the NAS and an ANM message out to the SS7 387 network. 389 * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop 390 timer T313. 392 I-D The Reliable Signaling Gateway Control Protocol June 1998 394 4.1.1.3 IAM Initiated with COT on Previous Circuit Required 396 This scenario describes the signaling that proceeds when a call is 397 initiated by the reception of an IAM from the SS7 network that 398 specifies a continuity test on a previous circuit is required. 400 * When the SG receives a IAM from the SS7 network, the Nature of 401 Connection indicators shall be examined to determine if COT is 402 required on the specified circuit, or on a previous circuit. If COT 403 is required on a previous circuit, the SG shall send a SETUP message 404 out to the control link. 406 * Once the NAS has determined that the call can be completed and the 407 specified channel has been connected to the called party, it shall 408 send a CONNECT message to the SG. The NAS shall start timer T313 when 409 the CONNECT message is sent. 411 * Upon receipt of the CONNECT message, the SG shall send a CONNECT 412 ACKNOWLEDGE message to the NAS. 414 * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop 415 timer T313. 417 * When the SG receives a COT message from the SS7 network indicating 418 the continuity test was successful, the SG shall send a ANM message 419 out to the SS7 network. 421 4.1.2 Call Clearing 423 4.1.2.1 Network Initiated Call Clearing 425 This scenario describes the signaling that proceeds when a call 426 clearing is initiated by the SS7 network. 428 * Call clearing is initiated by the SS7 network when a REL is 429 received by the SG from the SS7 network. When the SG receives a REL 430 from the SS7 network, a DISCONNECT message with a Cause Value of 16, 431 "normal clearing", is sent to the NAS. 433 * When the NAS receives a DISCONNECT message the associated circuit 434 shall be disconnected, a RELEASE shall be sent to the SG, and timer 435 T308 shall be initiated. 437 * When the SG receives the RELEASE message, a RELEASE COMPLETE shall 438 be sent to the NAS and a RLC shall be sent out to the SS7 network. 440 * When the NAS receives the RELEASE COMPLETE message timer T308 shall 441 be stopped, the channel shall be released, and the call reference 442 shall be released. 444 4.1.2.2 NAS Initiated Call Clearing This scenario describes the 445 signaling that proceeds when a call clearing is initiated by the NAS. 447 * When the NAS detects that an active call has been terminated by the 449 I-D The Reliable Signaling Gateway Control Protocol June 1998 451 local subscriber, the NAS shall disconnect the associated circuit, 452 send a DISCONNECT message to the SG, and initiate timer T305. 454 * When the SG receives a DISCONNECT from the NAS, a RELEASE message 455 shall be sent to the NAS, and a RLS message shall be sent out to the 456 SS7 network. 458 * When the NAS receives the RELEASE message timer T305 shall be 459 stopped, the circuit shall be released, the call reference shall be 460 released, and a RELEASE COMPLETE shall be sent to the SG. 462 * When the NAS receives the RELEASE COMPLETE message timer T308 shall 463 be stopped, the B-channel shall be release, and the call reference 464 shall be released. 466 4.1.3 Call Failures and CCR 468 * message timer Tserv shall be stopped and a RLC shall be sent out to 469 the SS7 network. 471 4.1.3.1 IAM Initiated with COT on Previous Circuit Failed 473 This scenario describes the signaling that proceeds when a call is 474 initiated by the reception of an IAM from the SS7 network that 475 specifies a continuity test on a previous circuit is required and 476 consequently the continuity test fails. 478 * When the SG receives a IAM from the SS7 network, the Nature of 479 Connection indicators shall be examined to determine if COT is 480 required on the specified circuit, or on a previous circuit. If COT 481 is required on a previous circuit, the SG shall send a SETUP message 482 out to the control link. 484 * Once the NAS has determined that the call can be completed and the 485 specified channel has been connected to the called party, it shall 486 send a CONNECT message to the SG. The NAS shall start timer T313 when 487 the CONNECT message is sent. 489 * Upon receipt of the CONNECT message, the SG shall send a CONNECT 490 ACKNOWLEDGE message to the NAS. 492 * Upon receipt of the CONNECT ACKNOWLEDGE message, the NAS shall stop 493 timer T313. 495 * When the SG receives a REL message from the SS7 network, which 496 indicates the continuity test failed, a DISCONNECT message with a 497 Cause Value of 16, "normal clearing", is sent to the NAS. 499 * When the NAS receives a DISCONNECT message the associated circuit 500 shall be disconnected, a RELEASE shall be sent to the SG, and timer 501 T308 shall be initiated. 503 * When the SG receives the RELEASE message, a RELEASE COMPLETE shall 504 be sent to the NAS and a RLC shall be sent out to the SS7 network. 506 I-D The Reliable Signaling Gateway Control Protocol June 1998 508 * When the NAS receives the RELEASE COMPLETE message timer T308 shall 509 be stopped, the channel shall be released, and the call reference 510 shall be released. 512 4.1.4 Resource Registration 514 4.1.4.1 Registration 516 This scenario describes the message flow that proceeds when a NAS 517 unit registers the available hardware interfaces. 519 * When the NAS detects that a resource has changed operational 520 states, a REGistration message is sent to the SG and Timer T350 shall 521 be initiated. 523 * When the SG receives the REGistration message, the indicated 524 resource states are updated and a REGistration ACKnowledgement is 525 sent to the NAS. The Resource information elements in the 526 REGistration ACKnowledgement must be identical to those received in 527 the original REGistration message. 529 * When the NAS receives the REGistration ACKnowledge message, timer 530 T350 shall be stopped. 532 4.1.4.2 Registration - T350 Timeout 534 This scenario describes the message flow that proceeds when a timeout 535 of Timer T350 occurs after the NAS has initiated registration of the 536 available hardware interfaces. It is important to note that the NAS 537 should continue to re-send the REGistration message and restart Timer 538 T350 until a corresponding REGistration ACKnowledge is received. 540 * When the NAS detects that a resource has changed operational 541 states, a REGistration message is sent to the SG and Timer T350 shall 542 be initiated. 544 * When Timer T350 expires on the NAS, the NAS shall re-send the 545 REGistration message and restart timer T350. 547 * When the SG receives the REGistration message, the indicated 548 resource states are updated and a REGistration ACKnowledgement is 549 sent to the NAS. The Resource information elements in the 550 REGistration ACKnowledgement must be identical to those received in 551 the original REGistration message. 553 * When the NAS receives the REGistration ACKnowledge message, timer 554 T350 shall be stopped. 556 4.1.4.3 SG Initiated Restart 558 This scenario describes the message flow that proceeds when a Restart 559 Request primitive is received by the SG Control Protocol from the 560 call control. 562 I-D The Reliable Signaling Gateway Control Protocol June 1998 564 * When the SG Control Protocol receives a Restart Request primitive 565 from the call control, a RESTart message is sent to the NAS and timer 566 T317 is initiated. 568 * When the NAS receives a RESTart message from the SG Control 569 Protocol, the specified device shall be restarted and a RESTart 570 ACKnowledgment shall be sent to the SG. 572 * When the SG Control Protocol receives a RESTart ACKnowledgment from 573 the NAS, timer T317 shall be stopped. 575 4.1.4.4 NAS Initiated Restart 577 This scenario describes the message flow that proceeds when a RESTart 578 message is received by the SG Control Protocol from the NAS, as shown 579 in figure Figure 28 - NAS Initiated Restart. 581 * If the NAS determines that a restart of a single DS0, an entire 582 DS1/E1, or the entire NAS system is necessary, a RESTART message 583 shall be sent to the SG and timer T317 shall be initiated. 585 * When the SG Control Protocol receives a RESTart message from the 586 NAS, a Restart Indication primitive shall be sent to the call control 587 and a RESTart ACKnowledgment shall be sent to the NAS. 589 * When the NAS receives a RESTart ACKnowledgment from the SG, timer 590 T317 shall be stopped, and the associated equipment shall be 591 restarted. 593 4.2 Detailed Procedures 595 This section provides detailed information that describes the 596 operation of the SG Control Protocol. A call progresses through 597 different states as various events occur, and this section describes 598 how the SG and NAS should process calls in each state. The table 599 below shows the call states that apply to the SG Control Protocol. 601 State Name Value 602 Null 0 603 Call Initiated 1 604 Call Present 6 605 Connect Request 8 606 Active 10 607 Disconnect Request 11 608 Disconnect Indication 12 609 Release Request 19 611 5.0 Redundancy 613 For redundancy support, the SG and the NAS are connected via two 614 independent links, a primary link (D1) and a secondary link (D2). The 615 D1 and D2 entities on the NAS will attempt to establish sessions with 616 their peers on the SG. When a session is established or lost, the 617 Data Link Layer Entity (DLLE) will notify the Link Selection Control 619 I-D The Reliable Signaling Gateway Control Protocol June 1998 621 (LS) entity. 623 The LS entity selects an available link (based on the reports from D1 624 and D2) and directs all NMI messages to that link. When an active 625 link fails or is administratively declared inactive, the LS entity 626 looks for an alternate link. 628 In general, the NAS Messaging Interface (NMI) is unaware of the link 629 selection mechanism. As far as the NMI is concerned, there is a 630 single pipe between the Gateway and the NAS. Therefore, the queue of 631 outgoing messages (including those that are still unacknowledged) 632 must be shared between the two D1 and D2 entities. 634 The message exchange between the Gateway and the NAS will use TCP 635 over IP. The TCP port to be used should be user settable. 637 The usual physical connection between the Gateway and the NAS will be 638 Ethernet. Transmission of IP over Ethernet follows the usual rules. 639 Other physical connections are possible. 641 All numbers should be in binary, encoded in Network Byte Order (Big 642 Endian). 644 Sequence numbers follow the rules defined in RFC 1982 ("Serial Number 645 Arithmetic"). 647 The procedures have been designed assuming that the Gateway will 648 listen for TCP connections, while the NAS will initiate the TCP 649 connections. 651 Piggy-back acknowledgments are allowed and encouraged. 652 Acknowledgments should not be delayed excessively. 654 5.1 Formats 656 5.1.1 NMI packet format 658 The NMI packets are transported using the TCP protocol over IP. The 659 IP and TCP protocols are standard and are not defined in this 660 document. Refer to RFC791 and RFC793 for further details. 662 The NMI header is defined below. The Information field is optional 663 and it is used to carry NMI messages. 665 5.1.2 NMI header format 667 The NMI header is four bytes long. 669 7 6 5 4 3 2 1 0 670 +-+-+-+-+-+-+-+- 671 0 | N(r) 672 +-+-+-+-+-+-+-+- 673 1 | N(s) 674 +-+-+-+-+-+-+-+- 676 I-D The Reliable Signaling Gateway Control Protocol June 1998 678 2 |0 0 0 0 0 0 679 +-+-+-+-+-+-+-+- 680 3 | Info Field Lng 682 The N(r) field carries the received sequence number. The N(s) field 683 carries the send sequence number. These numbers are used to detect 684 duplicated data packets when using multiple links. Duplicate data 685 packets can occur on the receiver when the sender switches from one 686 active link to another. 688 The information field length indicates the length in bytes of the 689 information field following the NMI header, if any. If the 690 information field is not present, the length field is set to zero. 691 The field is encoded in big-endian format. 693 5.1.3 Packet types 695 Depending on the presence of the information field, there are two 696 kinds of packets: Information packets and ACK packets. 698 5.1.3.1 Information (I) packet 700 The function of the Information (I) packet is to transfer 701 sequentially numbered NMI messages. In this case, the header is 702 followed by an information field containing the NMI message. 704 I packets may also be used to acknowledge previously received I 705 packets numbered up to and including N(r) - 1. This function is 706 commonly referred to "piggy-back acknowledge". 708 5.1.3.2 Acknowledge (ACK) packet 710 The function of the Acknowledge (ACK) packet is to acknowledge 711 previously received I packets numbered up to and including N(r) - 1. 713 5.2 Recommended system parameters 715 5.2.1 Maximum number of outstanding data packets - k 717 The maximum number (k) of sequentially numbered data packets that may 718 be outstanding (that is, unacknowledged) at any given time should not 719 exceed 63. 721 5.2.2 Maximum number of received data packets pending acknowledgement - 722 m 724 The maximum number (m) of sequentially numbered data packets received 725 pending acknowledgement at any given time must be smaller or equal to 726 the value of k. 728 5.2.3 ACK delay timer - T1 730 The ACK delay timer (T1) specifies the maximum time that an 732 I-D The Reliable Signaling Gateway Control Protocol June 1998 734 acknowledge response can be delayed after correctly receiving an I 735 packet. 737 5.2.4 Transmission timeout timer - T2 739 The transmission timeout timer (T2) specifies the maximum time that 740 an end point should wait for an acknowledgement. 742 5.2.5 Persistent error timer - T3 744 The transmission timeout timer (T3) specifies the maximum time that 745 the Link Selection layer will wait for a link to establish. When 746 this timer expires, the LS layer will indicate the error with an L2- 747 ERROR indication. When the error condition is removed (i.e., a TCP 748 session is established), another L2-ERROR indication will be issued 749 with a "no error" indication. 751 5.3 Variables and sequence numbers 753 5.3.1 Sequence numbers 755 Each NMI message is sequentially numbered. The sequence numbers 756 cycle through the range 1 through 255. The number following 255 is 1, 757 the number before 1 is 255. The value 0 has special meaning. 759 Arithmetic operations on state variables representing sequence 760 numbers are affected by the fact that 0 is a forbidden value. 762 5.3.2 Link selection (LS) layer 764 5.3.2.1 Active link - L(a) 766 L(a) denotes an identifier associated with the currently selected 767 link. Valid values are system dependent. In UNIX systems, this value 768 could be the TCP socket number. 770 5.3.2.2 Inactive link - L(i) 772 L(i) denotes an identifier associated with the other link. Valid 773 values are system dependent. In UNIX systems, this value could be the 774 TCP socket number. 776 5.3.2.3 Send state variable - V(s) 778 V(s) denotes the sequence number of the next NMI message to be 779 transmitted. V(s) can take on the value 1 through 255. The value of 780 V(s) will be incremented by 1 with each successive NMI message 781 transmission, and will not exceed V(a) by more than the maximum 782 number of outstanding data packets k. The value of k (send window 783 size) must be in the range 1 less than or equal to k less than or 784 equal to 63. 786 5.3.2.4 Acknowledge state variable - V(a) 788 I-D The Reliable Signaling Gateway Control Protocol June 1998 790 V(a) identifies the last NMI message that has been acknowledged by 791 its peer [V(a) - 1 equals N(s) of the last acknowledged NMI message]. 792 V(a) can take on the value 1 through 255. The value of V(a) will be 793 updated by the valid N(r) values received from the peer. A valid N(r) 794 value is one that is in the range V(a) less than or equal to N(r) 795 less than or equal to V(s). 797 5.3.2.5 Receive state variable - V(r) 799 V(r) denotes the sequence number of the next in-sequence NMI message 800 expected to be received. V(r) can take on the value 0 through 255. 801 The value of V(r) will be incremented by one with the receipt of an 802 error-free, in-sequence NMI message whose N(s) equals V(r). 804 When the value of V(r) is 0, it will match any received N(s) exactly. 805 This is used during sequence synchronization. 807 5.3.2.6 Receive packets pending acknowledgement counter - RP 809 RP denotes the count of received packets that are pending 810 acknowledgement. RP can take on the value 0 through m - 1. The 811 value of RP will be incremented by one with the receipt of an error- 812 free, in-sequence NMI message whose N(s) equals V(r). It is reset to 813 0 when a packet is transmitted (either an I packet or an ACK packet). 815 5.3.3 Data link (DL) layer 817 5.3.3.1 Send sequence number - N(s) 819 All packets carry N(s), the send sequence number of transmitted NMI 820 messages. At the time that a packet is designated for transmission, 821 the value of N(s) is set equal to V(s). The valid range is 1 through 822 255. 824 5.3.3.2 Receive sequence number - N(r) 826 All packets carry N(r), the expected send sequence number of the next 827 received NMI message. At the time that a packet is designated for 828 transmission, the value of N(r) is set equal to V(r). N(r) indicates 829 that the DLLE transmitting the N(r) has correctly received all data 830 packets numbered up to and including N(r) - 1. 832 A valid N(r) value is one that is in the range V(a) less than or 833 equal to N(r) less than or equal to V(s). 835 The valid range of values is 0 through 255. The value 0 indicates 836 that the sender of the packet needs to synchronize sequence numbers. 838 5.4 Primitives 840 5.4.1 NP <-> LS primitives 842 5.4.1.1 L2-START 844 I-D The Reliable Signaling Gateway Control Protocol June 1998 846 The L2-START primitive is used to request the establishing of a 847 redundant session. 849 5.4.1.2 L2-STOP 851 The L2-STOP primitive is used to request the release of an 852 established redundant session. All pending outgoing data will be 853 delivered before the session is released. 855 5.4.1.3 L2-ABORT 857 The L2-ABORT primitive is used to request the immediate release of an 858 established session. All pending outgoing data is discarded. 860 5.4.1.4 L2-DATA 862 The L2-DATA primitives are used to request and indicate NMI messages 863 which are to be transmitted, or have been received, by the data link 864 layer. 866 5.4.1.5 L2-ERROR 868 The L2-ERROR primitive is used to indicate when an error condition 869 has occurred. Some of the possible conditions include: 871 Loss of communication with peer. 873 Persistent loss of communication with peer. 875 Error condition removed. 877 5.4.2 LS <-> DL primitives 879 5.4.2.1 DL-ESTABLISH 881 The DL-ESTABLISH primitives are used to request and confirm the 882 outcome of procedures for establishing a TCP session. 884 5.4.2.2 DL-RELEASE 886 The DL-RELEASE primitives are used to request, indicate and confirm 887 the release of an established TCP session. 889 5.4.2.3 DL-ACTIVE 891 The DL-ACTIVE primitives are used to request, indicate and confirm 892 the outcome of procedures for activating a link. 894 5.4.2.4 DL-DATA 896 The DL-DATA primitives are used to request and indicate NMI messages 897 which are to be transmitted, or have been received, by the data link 898 layer. 900 I-D The Reliable Signaling Gateway Control Protocol June 1998 902 5.4.2.5 DL-ERROR 904 The DL-ERROR primitive is used to indicate when an error has 905 occurred. 907 5.4.3 DL <-> DA primitives 909 5.4.3.1 DD-SYNC 911 The DD-SYNC primitive is used to request and indicate the 912 synchronization of a data link. 914 5.4.3.2 DD-LOSS 916 The DD-LOSS primitive is used to indicate that a data link is no 917 longer available. The TCP session should be closed and reestablished. 918 Some of possible reasons include: 920 Loss of TCP connection (such as reception of an RST or FIN flag). 922 Timeout while waiting for an acknowledge after sending an I packet. 924 Reception of an invalid N(r). 926 Reception of an invalid N(s). 928 5.4.3.3 DD-DATA 930 The DD-DATA primitives are used to request and indicate NMI messages 931 which are to be transmitted, or have been received, by the data link 932 layer. 934 5.4.4 TCP primitives 936 5.4.4.1 TCP-CONNECT 938 The TCP-CONNECT primitives are used to request and confirm 939 establishing a TCP session. 941 5.4.4.2 TCP-CLOSE 943 The TCP-CLOSE primitives are used to request and indicate the release 944 of an established TCP session. 946 5.4.4.3 TCP-ABORT 948 The TCP-ABORT primitives is used to request the immediate release of 949 a TCP session. 951 6. State transition tables 953 6.1 State machines overview 955 6.1.1 Layer 2 - Link selection state machine (LS) 957 I-D The Reliable Signaling Gateway Control Protocol June 1998 959 The link selection (LS) layer implements redundant data delivery, 960 link management and selection for both data links. The following is a 961 list of the Link Selection layer states: 963 State Name Comments 965 0 Inactive NMI layer 2 is disabled. 967 1 Selecting Layer 2 starting. Waiting for DL-ESTABLISH. 969 2 Active Layer 2 active: a link is active and data 970 transfer is possible. 972 3 Restarting Layer 2 restarting with new parameters. 973 Waiting for both links to be released. Any 974 pending data will be sent before the active 975 link is released. 977 4 Stopping Layer 2 stopping. Waiting for both links to 978 be released. 980 5 Stopping- Layer 2 stopping and restarting. Waiting for 981 restart both links to be released before the new 982 parameters are effected. 984 6.1.2 Link control state machine (LC) 986 Each redundant link is controlled by a 'Link Control State Machine'. 987 The following is a list of the Link Control states: 989 State Name Comments 991 0 Inactive 993 1 Unavailable Link establishment in progress. 995 2 Available Link established and ready. 997 3 Pending Link established and ready. Synchronization 998 activation pattern received. 1000 4 Active Link active. Data transfer occurs on this 1001 link. 1003 5 Stopping Active link stopping. Waiting for all pending 1004 outgoing data to be delivered. 1006 6 Closing Active link closing. Waiting for TCP 1007 confirmation of link closed. 1009 7 Releasing Inactive link closing. Waiting for TCP 1010 confirmation of link closed. 1012 6.1.3 Link state machine - active mode (LA) 1014 I-D The Reliable Signaling Gateway Control Protocol June 1998 1016 The following is a list of the link states while in active mode. A 1017 link is said to be in active mode if it is the currently selected 1018 link. A link that is in the active mode is enabled for data transfer. 1020 State Name Comments 1022 0 Idle Link control state is one of the following: 1023 INACTIVE, UNAVAILABLE, AVAILABLE, RELEASING 1024 and CLOSING. 1026 1 Sync sent Active link, synchronization request sent. 1027 Waiting for synchronization response. 1029 2 Established Active link, no data to send and no 1030 acknowledge pending. 1032 3 Acknowledge Active link, data has been received but a 1033 pending acknowledgement has not been sent. 1035 4 Data sent Active link, data sent but not acknowledged. 1037 5 Data sent, Active link, data sent but not acknowledged 1038 acknowledge and data has been received but an 1039 pending acknowledgement has not been sent. 1041 7. Security Considerations 1043 SS7 is a critical network component in the PSTN and must be protected 1044 at all costs. This is taken into consideration in all current SS7 1045 networks. Signaling gateways are designed also to protect the SS7 1046 network and should employ thoughtful thresholds to make sure a NAS or 1047 malicious intermediate entity cannot adversely affect the SS7 network 1048 or any SS7 connected nodes. 1050 Also, it is recommended but not required that the TCP/IP link from 1051 the NAS to the SG be protected by IPsec AH and ESP. In the case that 1052 the physical network between the NAS and SG is private, such security 1053 techniques are optional. In the case that the IP backbone used is 1054 shared with other applications and/or nodes, IPsec security is 1055 strongly recommended. This is to prevent Denial of Service attacks, 1056 and false message attacks which cannot be prevented by SG thresholds. 1058 8. Acronyms 1060 ANM Answer Message 1062 SG Signaling SG 1064 CCR Continuity Check Request 1066 COT Continuity 1068 CPE Customer Premises Equipment 1070 I-D The Reliable Signaling Gateway Control Protocol June 1998 1072 CRM Circuit Reservation Message 1074 IAM Initial Address Message 1076 ICD Interface Control Document 1078 IE Information Element 1080 IP Internet Protocol 1082 ISDN Integrated Services Digital Network 1084 ISP Internet Service Provider 1086 ISUP ISDN User Part 1088 MTP Message Transfer Part 1090 PCM Pulse Code Modulation 1092 PSTN Public Switched Telephone Network 1094 SPCS Stored Program Control System 1096 SS7 Signaling System Number 7 1098 UL Upper Layer 1100 10. Authors Address 1102 Matt Holdrege 1103 1701 Harbor Bay Pkwy 1104 Alameda, CA 94502 1105 510-747-2711 1106 matt@ascend.com 1108 Full Copyright Statement 1110 Copyright (C) The Internet Society (1998). All Rights Reserved. 1112 This document and translations of it may be copied and furnished to 1113 others, and derivative works that comment on or otherwise explain it 1114 or assist in its implementation may be prepared, copied, published 1115 and distributed, in whole or in part, without restriction of any 1116 kind, provided that the above copyright notice and this paragraph are 1117 included on all such copies and derivative works. However, this 1118 document itself may not be modified in any way, such as by removing 1119 the copyright notice or references to the Internet Society or other 1120 Internet organizations, except as needed for the purpose of 1121 developing Internet standards in which case the procedures for 1122 copyrights defined in the Internet Standards process must be 1123 followed, or as required to translate it into languages other than 1124 English. 1126 I-D The Reliable Signaling Gateway Control Protocol June 1998 1128 The limited permissions granted above are perpetual and will not be 1129 revoked by the Internet Society or its successors or assigns. 1131 This document and the information contained herein is provided on an 1132 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1133 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1134 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1135 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1136 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1138 INTERNET DRAFT EXPIRES DEC 1998 INTERNET DRAFT