idnits 2.17.1 draft-ietf-sigtran-iua-imp-guide-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 2317 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC3057]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 61: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 62: '... SHOULD NOT, RECOMMENDED, NOT RECOMM...' RFC 2119 keyword, line 90: '...arameter padding MUST be included in t...' RFC 2119 keyword, line 93: '...Note: A receiver SHOULD accept the mes...' RFC 2119 keyword, line 594: '...quires one. The ASP SHOULD resend the...' (41 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1291 has weird spacing: '...essages until...' -- 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 (Oct 2002) is 7835 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 16, but not defined == Missing Reference: 'RFC2119' is mentioned on line 65, but not defined -- Looks like a reference, but probably isn't: '2' on line 988 -- Looks like a reference, but probably isn't: '1' on line 984 -- Looks like a reference, but probably isn't: '3' on line 993 -- Looks like a reference, but probably isn't: '4' on line 997 -- Looks like a reference, but probably isn't: '5' on line 1001 -- Looks like a reference, but probably isn't: '6' on line 1004 -- Looks like a reference, but probably isn't: '7' on line 1007 -- Looks like a reference, but probably isn't: '8' on line 1010 -- Looks like a reference, but probably isn't: '9' on line 1013 ** Obsolete normative reference: RFC 3057 (Obsoleted by RFC 4233) Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Morneault 2 INTERNET-DRAFT Cisco Systems 4 Expires in six months Oct 2002 6 IUA (RFC 3057) Outstanding Issues 7 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026 [RFC2026]. Internet-Drafts 13 are working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 The list of current Internet-Drafts can be accessed at 18 http://www.ietf.org/ietf/1id-abstracts.txt 20 The list of Internet-Draft Shadow Directories can be accessed at 21 http://www.ietf.org/shadow.html. 23 Abstract 25 This document captures problems and issues discovered on the SIGTRAN 26 mailing list and at future interops for IUA [RFC3057]. This document 27 will be updated after each interop augmenting the existing draft to 28 include any new issues discovered during inter-operability testing. 29 Two basic sets of problems are identified by this draft: first, issues 30 that need to be addressed when the next revision of IUA is created, 31 i.e. issues that should be remembered in a BIS document; second, 32 issues that were found that are strictly implementation problems. 34 Table of Contents 36 1.0 Introduction................................................ 2 37 2.0 Conventions................................................. 2 38 3.0 Corrections to IUA [RFC3057]................................ 3 39 4.0 Acknowledgements............................................12 40 5.0 Authors Addresses...........................................13 41 6.0 References..................................................13 43 1. Introduction 45 This document contains a compilation of all defects found up until 46 May 2002 for the ISDN User Adaptation Layer (IUA) [RFC3057]. These 47 defects may be of an editorial or technical nature. This document may 48 be thought of as a companion document to be used in the 49 implementation of IUA to clarify errors in the original IUA 50 document. This document updates RFC3057 and text within this 51 document, where noted, supersedes the text found in RFC3057. Each 52 error will be detailed within this document in the form of: 54 - The problem description, 55 - The text quoted from RFC3057, 56 - The replacement text, 57 - A description of the solution. 59 2. Conventions 61 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 62 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 63 they appear in this document, are to be interpreted as described in 64 [RFC2119]. 66 3. Corrections to IUA [RFC3057] 68 3.1 Message Length in Common Header 70 3.1.1 Description of the problem 72 The RFC was not clear if message length in common header should 73 include padding bytes. 75 3.1.2 Text changes to the document 77 --------- 78 Old text: (Section 3.1.4) 79 --------- 81 The Message length defines the length of the message in octets, 82 including the Common header. 84 --------- 85 New text: (Section 3.2) 86 --------- 88 The Message Length defines the length of the message in octets, 89 including the Common Header. For messages with a final parameter 90 containing padding, the parameter padding MUST be included in the 91 Message Length. 93 Note: A receiver SHOULD accept the message whether or not the final 94 parameter padding is included in the message length. 96 3.1.3 Solution description 98 The message length must include padding bytes. 100 3.2 ASP Down Reason 102 3.2.1 Description of the problem 104 There is a need to synchronize IUA with other UAs by removing Reason 105 parameter from ASP Down and ASP Down Ack messages. The other UAs 106 removed the Reason parameter because a use could not be found for 107 this parameter. 109 3.2.2 Text changes to the document 111 --------- 112 Old text: (Section 3.3.2.3) 113 --------- 115 The ASPDN message contains the following parameters: 117 Reason 118 INFO String (Optional) 120 The format for the ASPDN message parameters is as follows: 122 0 1 2 3 123 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Tag (0xa) | Length | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | Reason | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Tag (0x4) | Length | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | INFO String* | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 The format and description of the optional Info String parameter is 137 the same as for the ASP Up message (See Section 3.3.3.1.). 139 The Reason parameter indicates the reason that the remote IUA 140 adaptation layer is unavailable. The valid values for Reason are 141 shown in the following table. 143 Value Description 144 0x1 Management Inhibit 146 If a ASP is removed from Management Inhibit, the ASP will send an ASP 147 Up message. 149 --------- 150 New text: (Section 3.3.2.3) 151 --------- 153 The ASPDN message contains the following parameters: 155 INFO String (Optional) 157 The format for the ASPDN message parameters is as follows: 159 0 1 2 3 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Tag (0x4) | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | INFO String* | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 The format and description of the optional Info String parameter is 170 the same as for the ASP Up message (See Section 3.3.2.1). 172 --------- 173 Old text: (Section 3.3.2.4) 174 --------- 176 The ASP Down Ack message is used to acknowledge an ASP Down message 177 received from a remote IUA peer. 179 The ASP Down Ack message contains the following parameters: 181 Reason 182 INFO String (Optional) 184 The format for the ASP Down Ack message parameters is as follows: 186 0 1 2 3 187 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Tag (0xa) | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Reason | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Tag (0x4) | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | INFO String* | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 The format and description of the optional Info String parameter is 201 the same as for the ASP Up message (See Section 3.3.2.1.). 203 The format of the Reason parameter is the same as for the ASP Down 204 message (See Section 3.3.2.3). 206 --------- 207 New text: (Section 3.3.2.4) 208 --------- 210 The ASP Down Ack message is used to acknowledge an ASP Down message 211 received from a remote IUA peer. 213 The ASP Down Ack message contains the following parameters: 215 INFO String (Optional) 217 The format for the ASP Down Ack message parameters is as follows: 219 0 1 2 3 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Tag (0x4) | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | INFO String* | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 The format and description of the optional Info String parameter is 230 the same as for the ASP Up message (See Section 3.3.2.1). 232 3.2.3 Solution description 234 The Reason parameter is removed from the ASP Down and ASP Down 235 Acknowledge messages. ASP and SG implementations should accept the 236 respective message without the Reason parameter. 238 3.3 ASP State Machine 240 3.3.1 Description of the problem 242 Handling of ASP Up when in ASP-ACTIVE state and SCTP Restart 243 indication are not specified. 245 3.3.2 Text changes to the document 247 --------- 248 Old text: (Section 4.3.1.1) 249 --------- 251 Figure 7 ASP State Transition Diagram 253 +-------------+ 254 +----------------------| | 255 | Alternate +-------| ASP-ACTIVE | 256 | ASP | +-------------+ 257 | Takeover | ^ | 258 | | ASP | | ASP 259 | | Active | | Inactive 260 | | | v 261 | | +-------------+ 262 | | | | 263 | +------>| ASP-INACT | 264 | +-------------+ 265 | ^ | 266 ASP Down/ | ASP | | ASP Down / 267 SCTP CDI | Up | | SCTP CDI 268 | | v 269 | +-------------+ 270 +--------------------->| | 271 | ASP-DOWN | 272 +-------------+ 274 SCTP CDI: The local SCTP layer's Communication Down Indication to 275 the Upper Layer Protocol (IUA) on an SG. The local SCTP will send 276 this indication when it detects the loss of connectivity to the ASP's 277 peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN 278 COMPLETE notification and COMMUNICATION LOST notification from the 279 SCTP. 281 --------- 282 New text: (Section 4.3.1.1) 283 --------- 285 Figure 7 ASP State Transition Diagram 287 +--------------+ 288 +----------------------| | 289 | Alternate +-------| ASP-ACTIVE | 290 | ASP | +--------------+ 291 | Takeover | ^ | 292 | | ASP | | ASP Inactive / 293 | | Active | | ASP Up 294 | | | v 295 | | +--------------+ 296 | | | | 297 | +------>| ASP-INACTIVE | 298 | +--------------+ 299 | ^ | 300 ASP Down/ | ASP | | ASP Down / 301 SCTP CDI/ | Up | | SCTP CDI / 302 SCTP RI | | v SCTP RI 303 | +--------------+ 304 +--------------------->| | 305 | ASP-DOWN | 306 +--------------+ 308 SCTP CDI: The local SCTP layer's Communication Down Indication to 309 the Upper Layer Protocol (IUA) on an SG. The local SCTP will send 310 this indication when it detects the loss of connectivity to the ASP's 311 peer SCTP layer. SCTP CDI is understood as either a SHUTDOWN 312 COMPLETE notification and COMMUNICATION LOST notification from the 313 SCTP. 315 SCTP RI: The local SCTP layer's Restart indication to the upper 316 layer protocol (IUA) on an SG. The local SCTP will send this 317 indication when it detects a restart from the ASP's peer SCTP layer. 319 3.3.3 Solution description 321 A SCTP Restart Indication is treated the same as a Communication 322 Down Indication with respect to the ASP state machine on the SG. 324 If the SG receives an ASP Up from an ASP in the ASP-ACTIVE state, it 325 should sends an ASP Up Acknowledgement and transition the ASP to the 326 ASP-INACTIVE state. 328 3.4 AS State Machine 330 3.4.1 Description of the problem 332 The AS state machine in the RFC has some editorial errors in the area 333 of naming ASP states. 335 3.4.2 Text changes to the document 337 --------- 338 Old text: (Section 4.3.1.2) 339 --------- 341 Figure 8 AS State Transition Diagram 343 +----------+ one ASP trans ACTIVE +-------------+ 344 | |------------------------>| | 345 | AS-INACT | | AS-ACTIVE | 346 | | | | 347 | |< | | 348 +----------+ \ +-------------+ 349 ^ | \ Tr Trigger ^ | 350 | | \ at least one | | 351 | | \ ASP in UP | | 352 | | \ | | 353 | | \ | | 354 | | \ | | 355 one ASP | | \ one ASP | | Last ACTIVE ASP 356 trans | | all ASP \------\ trans to | | trans to INACT 357 to | | trans to \ ACTIVE | | or DOWN 358 INACT | | DOWN \ | | (start Tr timer) 359 | | \ | | 360 | | \ | | 361 | | \ | | 362 | v \ | v 363 +----------+ \ +-------------+ 364 | | -| | 365 | AS-DOWN | | AS-PENDING | 366 | | | (queueing) | 367 | |<------------------------| | 368 +----------+ Tr Expiry and no +-------------+ 369 ASP in INACTIVE state 371 Tr = Recovery Timer 373 --------- 374 New text: (Section 4.3.1.2) 375 --------- 377 Figure 8: AS State Transition Diagram 379 +----------+ one ASP trans to ASP-ACTIVE +-------------+ 380 | AS- |---------------------------->| AS- | 381 | INACTIVE | | ACTIVE | 382 | |<--- | | 383 +----------+ \ +-------------+ 384 ^ | \ Tr Expiry, ^ | 385 | | \ at least one | | 386 | | \ ASP in ASP-INACTIVE | | 387 | | \ | | 388 | | \ | | 389 | | \ | | 390 one ASP | | all ASP \ one ASP | | Last ACTIVE 391 trans | | trans to \ trans to | | ASP trans to 392 to | | ASP-DOWN -------\ ASP- | | ASP-INACTIVE 393 ASP- | | \ ACTIVE | | or ASP-DOWN 394 INACTIVE| | \ | | (start Tr) 395 | | \ | | 396 | | \ | | 397 | v \ | v 398 +----------+ \ +-------------+ 399 | | --| | 400 | AS-DOWN | | AS-PENDING | 401 | | | (queueing) | 402 | |<----------------------------| | 403 +----------+ Tr Expiry and no ASP +-------------+ 404 in ASP-INACTIVE state) 406 Tr = Recovery Timer 408 3.4.3 Solution description 410 The AS state machine is clarified by providing the correct ASP 411 state names. 413 3.5 Remove Notify (AS Down) 415 3.5.1 Description of the problem 417 If AS transitions to AS-DOWN, there are no ASPs to send Notify 418 message. Therefore, there is no need for "Notify (AS Down)". 420 3.5.2 Text changes to the document 422 --------- 423 Old text: (Section 3.3.3.2) 424 --------- 426 The Status Identification parameter contains more detailed 427 information for the notification, based on the value of the Status 428 Type. If the Status Type is AS_State_Change the following Status 429 Identification values are used: 431 Value Description 432 1 Application Server Down (AS_Down) 433 2 Application Server Inactive (AS_Inactive) 434 3 Application Server Active (AS_Active) 435 4 Application Server Pending (AS_Pending) 437 --------- 438 New text: (Section 3.3.3.2) 439 --------- 441 The Status Identification parameter contains more detailed 442 information for the notification, based on the value of the Status 443 Type. If the Status Type is AS_State_Change the following Status 444 Identification values are used: 446 Value Description 447 1 Reserved 448 2 Application Server Inactive (AS-INACTIVE) 449 3 Application Server Active (AS-ACTIVE) 450 4 Application Server Pending (AS-PENDING) 452 3.5.3 Solution description 454 Removed Notify (AS-DOWN). 456 3.6 List Tag Values 458 3.6.1 Description of the problem 460 To improve readability, list the parameter values in one place. 462 3.6.2 Text changes to the document 464 --------- 465 Old text: (Section 3.1.5) 466 --------- 468 Parameter Tag: 16 bits (unsigned integer) 470 The Tag field is a 16 bit identifier of the type of parameter. It 471 takes a value of 0 to 65534. 473 --------- 474 New text: (Section 3.1.5) 475 --------- 477 Parameter Tag: 16 bits (unsigned integer) 479 The Tag field is a 16-bit identifier of the type of parameter. It 480 takes a value of 0 to 65534. Common parameters used by adaptation 481 layers are in the range of 0x00 to 0x3f. The parameter Tags defined 482 are as follows: 484 Common Parameters. These TLV parameters are common across the 485 different adaptation layers: 487 Parameter Name Parameter ID 488 ============== ============ 489 Reserved 0x0000 490 Interface Identifier (integer) 0x0001 491 Not Used in IUA 0x0002 492 Interface Identifier (text) 0x0003 493 INFO String 0x0004 494 DLCI 0x0005 495 Not Used in IUA 0x0006 496 Diagnostic Information 0x0007 497 Interface Identifer Range 0x0008 498 Heartbeat Data 0x0009 499 Not Used in IUA 0x000a 500 Traffic Mode Type 0x000b 501 Error Code 0x000c 502 Status 0x000d 503 Protocol Data 0x000e 504 Release Reason 0x000f 505 TEI Status 0x0010 506 ASP Identifier 0x0011 507 Not Used in IUA 0x0012 - 0x003f 509 The value of 65535 is reserved for IETF-defined extensions. Values 510 other than those defined in specific parameter description are 511 reserved for use by the IETF. 513 3.6.3 Solution description 515 Add a list of parameter tags. 517 3.7 Add ASP Identifier 519 3.7.1 Description of the problem 521 Add ASP Identifier parameter to ASP Up and Notify messages along 522 with associated procedures for using ASP Identifier. This change 523 further aligns IUA with the other UAs. 525 3.7.2 Text changes to the document 527 --------- 528 Old text: (Section 3.3.2.1) 529 --------- 531 The ASPUP message contains the following parameters: 533 Info String (optional) 535 The format for ASPUP Message parameters is as follows: 537 0 1 2 3 538 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Tag (0x4) | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | INFO String* | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 --------- 548 New text: (Section 3.3.2.1) 549 --------- 551 The ASPUP message contains the following parameters: 553 ASP Identifier Optional 554 Info String Optional 556 The format for ASPUP Message parameters is as follows: 558 0 1 2 3 559 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Tag = 0x0011 | Length = 8 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | ASP Identifier | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Tag (0x4) | Length | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | INFO String* | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 ASP Identifier: 32-bit unsigned integer 574 The optional ASP Identifier parameter contains a unique value that 575 is locally significant among the ASPs that support an AS. The SG 576 should save the ASP Identifier to be used, if necessary, with the 577 Notify message (see Section 3.8.2). 579 --------- 580 Old text: (Section 3.3.3.1) 581 --------- 583 None 585 --------- 586 New text: (Section 3.3.3.1) 587 --------- 589 0x0e ASP Identifier Required 590 0x0f Invalid ASP Identifier 592 The "ASP Identifier Required" is sent by a SG in response 593 to an ASP Up message which does not contain an ASP Identifier 594 parameter when the SG requires one. The ASP SHOULD resend the 595 ASP Up message with an ASP Identifier. 597 The "Invalid ASP Identifier" is send by a SG in response 598 to an ASP Up message with an invalid (i.e., non-unique) ASP 599 Identifier. 601 --------- 602 Old text: (Section 3.3.3.2) 603 --------- 605 The Notify message will only use the common message header. The 606 Notify message contains the following parameters: 608 Status Type 609 Status Identification 610 Interface Identifiers (Optional) 611 INFO String (Optional) 613 The format for the Notify message with Integer-formatted Interface 614 Identifiers is as follows: 616 0 1 2 3 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Tag (0xd) | Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Status Type | Status Identification | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Tag (0x1=integer) | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Interface Identifiers* | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Tag (0x8=integer range) | Length | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Interface Identifier Start1* | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Interface Identifier Stop1* | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Interface Identifier Start2* | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Interface Identifier Stop2* | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 . . 640 . . 641 . . 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Interface Identifier StartN* | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Interface Identifier StopN* | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Additional Interface Identifiers | 649 | of Tag Type 0x1 or 0x8 | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Tag (0x4) | Length | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | INFO String* | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 --------- 660 New text: (Section 3.3.3.2) 661 --------- 663 The Notify message will only use the common message header. The 664 Notify message contains the following parameters: 666 Status Type 667 Status Identification 668 ASP Identifier Optional 669 Interface Identifiers Optional 670 INFO String Optional 672 The format for the Notify message with Integer-formatted Interface 673 Identifiers is as follows: 675 0 1 2 3 676 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Tag (0xd) | Length | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Status Type | Status Identification | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Tag = 0x0011 | Length | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | ASP Identifier | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 | Tag (0x1=integer) | Length | 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Interface Identifiers* | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Tag (0x8=integer range) | Length | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Interface Identifier Start1* | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Interface Identifier Stop1* | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Interface Identifier Start2* | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Interface Identifier Stop2* | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 . . 703 . . 704 . . 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Interface Identifier StartN* | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Interface Identifier StopN* | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Additional Interface Identifiers | 712 | of Tag Type 0x1 or 0x8 | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Tag (0x4) | Length | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | INFO String* | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 3.7.3 Solution description 724 Added ASP Identifier to provide consistency with other UAs. 726 3.8 TEI Query 728 3.8.1 Description of the problem 730 There is a need for Q.931 or IUA on the ASP side to query for the 731 TEI(s). This need is based on scenarios (Q.931 restart or ASP 732 Override) in which Q.931 or IUA on the ASP side may lose the TEI 733 assignment. 735 3.8.2 Text changes to the document 737 --------- 738 Old text: (Section 3.1.2) 739 --------- 741 Management (MGMT) Messages 743 0 Error (ERR) 744 1 Notify (NTFY) 745 2 TEI Status Request 746 3 TEI Status Confirm 747 4 TEI Status Indication 748 5 to 127 Reserved by the IETF 749 128 to 255 Reserved for IETF-Defined MGMT extensions 751 --------- 752 New text: (Section 3.1.2) 753 --------- 755 Management (MGMT) Messages 757 0 Error (ERR) 758 1 Notify (NTFY) 759 2 TEI Status Request 760 3 TEI Status Confirm 761 4 TEI Status Indication 762 5 TEI Query Request 763 6 to 127 Reserved by the IETF 764 128 to 255 Reserved for IETF-Defined MGMT extensions 766 --------- 767 New text: (Section 3.3.3.4) 768 --------- 770 3.3.3.4 TEI Query Message (Request) 772 The TEI Query message is sent by the ASP to query the TEI(s). 773 This message consists of the common header and IUA header. 774 The DLCI in the IUA header MUST be ignored by the SG. The 775 SG will respond to this message with a TEI Status Indication(s). 777 3.8.3 Solution description 779 A TEI Query message is added to fulfill the need of the ASP 780 side to be able to query the TEI value. 782 3.9 Traffic Mode Text 784 3.9.1 Description of the problem 786 There is a potentially confusing statement in Section 3.3.2.5 787 about traffic mode. 789 3.9.2 Text changes to the document 791 --------- 792 Old text: (Section 3.3.2.5) 793 --------- 795 Within a particular Interface Identifier, only one Traffic Mode 796 Type can be used. 798 --------- 799 New text: (Section 3.3.2.5) 800 --------- 802 Within a particular AS, only one Traffic Mode Type can be used. 804 3.9.3 Solution description 806 Provided clarification that Traffic Mode is on a AS basis not 807 an Interface Identifier basis. 809 3.10 Operational Recommendations 811 3.10.1 Description of the problem 813 Operational recommendations should be in an Appendix instead of the 814 main body of the RFC. 816 3.10.2 Text changes to the document 818 --------- 819 Old text: (Section 1.3.3) 820 --------- 822 1.3.3 Signaling Network Architecture 824 A Signaling Gateway is used to support the transport of Q.921-User 825 signaling traffic to one or more distributed ASPs (e.g., MGCs). 826 Clearly, the IUA protocol is not designed to meet the performance and 827 reliability requirements for such transport by itself. However, the 828 conjunction of distributed architecture and redundant networks does 829 allow for a sufficiently reliable transport of signaling traffic over 830 IP. The IUA protocol is flexible enough to allow its operation and 831 management in a variety of physical configurations, enabling Network 832 Operators to meet their performance and reliability requirements. 834 To meet the ISDN signaling reliability and performance requirements 835 for carrier grade networks, Network Operators SHOULD ensure that 836 there is no single point of failure provisioned in the end-to-end 837 network architecture between an ISDN node and an IP ASP. 839 Depending of course on the reliability of the SG and ASP functional 840 elements, this can typically be met by the provision of redundant 841 QOS-bounded IP network paths for SCTP Associations between SCTP End 842 Points, and redundant Hosts, and redundant SGs. The distribution of 843 ASPs within the available Hosts is also important. For a particular 844 Application Server, the related ASPs SHOULD be distributed over at 845 least two Hosts. 847 An example logical network architecture relevant to carrier-grade 848 operation in the IP network domain is shown in Figure 2 below: 850 Host1 851 ******** ************** 852 * *_________________________________________* ******** * 853 * * _________* * ASP1 * * 854 * SG1 * SCTP Associations | * ******** * 855 * *_______________________ | * * 856 ******** | | ************** 857 | | 858 ******** | | 859 * *_______________________________| 860 * * | 861 * SG2 * SCTP Associations | 862 * *____________ | 863 * * | | Host2 864 ******** | | ************** 865 | |_________________* ******** * 866 |____________________________* * ASP1 * * 867 * ******** * 868 * * 869 ************** 870 . 871 . 872 . 874 Figure 2 - Logical Model Example 876 For carrier grade networks, the failure or isolation of a particular 877 ASP SHOULD NOT cause stable calls to be dropped. This implies that 878 ASPs need, in some cases, to share the call state or be able to pass 879 the call state between each other. However, this sharing or 880 communication of call state information is outside the scope of this 881 document. 883 --------- 884 New text: (Section 1.3.3) 885 --------- 887 None, all text moved to Appendix. Section and figure numbering 888 adjusted accordingly. 890 3.10.3 Solution description 892 Moved operational recommendations to Appendix. 894 3.11 Character Set for Text-Based Interface Identifier 896 3.11.1 Description of the problem 898 Currently, a character set for the text-based Interface Identifier 899 is not specified. 901 3.11.2 Text changes to the document 903 Replace a dated reference from the list with the reference for 904 ANSI X3.4-1986. 906 --------- 907 Old text: (Section 9) 908 --------- 910 [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a 911 Voice over Packet Network' 913 --------- 914 New text: (Section 9) 915 --------- 917 [2] Coded Character Set--7-Bit American Standard Code for 918 Information Interchange, ANSI X3.4-1986. 920 --------- 921 Old text: (Section 3.2) 922 --------- 924 The Tag value for the Text-based Interface Identifier is 0x3. The 925 length is variable. 927 --------- 928 New text: (Section 3.2) 929 --------- 931 The Tag value for the Text-based [2] Interface Identifier is 0x3. 932 The length is variable. 934 3.11.3 Solution description 936 Add reference to 7-bit ASCII character set for text-based Interface 937 Identifier. 939 3.12 References - Normative and Informative 941 3.12.1 Description of the problem 943 The references should be split between normative and informative. 945 3.12.2 Text changes to the document 947 --------- 948 Old text: (Section 9) 949 --------- 951 [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System 952 No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - 953 General Aspects' 955 [2] T1S1.7/99-220 Contribution, 'Back-hauling of DSS1 protocol in a 956 Voice over Packet Network' 958 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., 959 Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 960 "Stream Control Transmission Protocol", RFC 2960, October 2000. 962 [4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 963 Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural 964 Framework for Signaling Transport", RFC 2719, October 1999. 966 [5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 967 1997. 969 [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet 970 Protocol", RFC 2401, November 1998. 972 [7] Bradner, s., "Key words for use in RFCs to Indicate Requirement 973 Levels", BCP 14, RFC 2119, March 1997. 975 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 976 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 978 --------- 979 New text: (Section 3.3.2.5) 980 --------- 982 9.1 Normative 984 [1] ITU-T Recommendation Q.920, 'Digital Subscriber signaling System 985 No. 1 (DSS1) - ISDN User-Network Interface Data Link Layer - 986 General Aspects' 988 [2] Coded Character Set--7-Bit American Standard Code for 989 Information Interchange, ANSI X3.4-1986. 991 9.2 Informative 993 [3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., 994 Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, 995 "Stream Control Transmission Protocol", RFC 2960, October 2000. 997 [4] Ong, L., Rytina, I., Garcia, M., Schwarzbauer, H., Coene, L., 998 Lin, H., Juhasz, I., Holdrege, M., and C. Sharp, "Architectural 999 Framework for Signaling Transport", RFC 2719, October 1999. 1001 [5] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1002 1997. 1004 [6] Kent, S. and R. Atkinson, "Security Architecture for the Internet 1005 Protocol", RFC 2401, November 1998. 1007 [7] Bradner, s., "Key words for use in RFCs to Indicate Requirement 1008 Levels", BCP 14, RFC 2119, March 1997. 1010 [8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1011 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1013 [9] RFC 2719, "Framework Architecture for Signaling Transport", L. Ong 1014 et al, October 1999 1016 3.12.3 Solution description 1018 Separated the references into ormative and informative. 1020 3.13 ASP Up Procedures 1022 3.13.1 Description of the problem 1024 The ASP Up procedures need to be resynchronized with the other 1025 UAs. 1027 3.13.2 Text changes to the document 1029 --------- 1030 Old text: (Section 4.3.3.1) 1031 --------- 1033 After an ASP has successfully established an SCTP association to an 1034 SG, the SG waits for the ASP to send an ASP Up message, indicating 1035 that the ASP IUA peer is available. The ASP is always the initiator 1036 of the ASP Up exchange. 1038 When an ASP Up message is received at an SG and internally the remote 1039 ASP is not considered locked-out for local management reasons, the SG 1040 marks the remote ASP as "Inactive". The SG responds with an ASP Up 1041 Ack message in acknowledgement. The SG sends an ASP-Up Ack message 1042 in response to a received ASP Up message even if the ASP is already 1043 marked as "Inactive" at the SG. 1045 If for any local reason the SG cannot respond with an ASP Up, the SG 1046 responds to a ASP Up with a with an ASP-Down Ack message with Reason 1047 "Management Blocking". 1049 At the ASP, the ASP Up Ack message received from the SG is not 1050 acknowledged by the ASP. If the ASP does not receive a response from 1051 the SG, or an ASP Down Ack is received, the ASP MAY resend ASP Up 1052 messages every 2 seconds until it receives a ASP Up Ack message from 1053 the SG. The ASP MAY decide to reduce the frequency (say to every 5 1054 seconds) if an ASP Up Ack is not received after a few tries. 1056 The ASP MUST wait for the ASP Up Ack message from the SG before 1057 sending any ASP traffic control messages (ASPAC or ASPIA) or Data 1058 messages or it will risk message loss. If the SG receives QPTM, ASP 1059 Active or ASP Inactive messages before an ASP Up is received, the SG 1060 SHOULD discard these messages. 1062 --------- 1063 New text: (Section 4.3.3.1) 1064 --------- 1066 After an ASP has successfully established an SCTP association to an 1067 SG, the SG waits for the ASP to send an ASP Up message, indicating 1068 that the ASP IUA peer is available. The ASP is always the initiator 1069 of the ASP Up message. This action MAY be initiated at the ASP by 1070 an M-ASP_UP request primitive from Layer Management or MAY be 1071 initiated automatically by an IUA management function. 1073 When an ASP Up message is received at an SG and internally the 1074 remote ASP is in the ASP-DOWN state and not considered locked out 1075 for local management reasons, the SG marks the remote ASP in the 1076 state ASP-INACTIVE and informs Layer Management with an M-ASP_Up 1077 indication primitive. If the SG is aware, via current configuration 1078 data, which Application Servers the ASP is configured to operate in, 1079 the SG updates the ASP state to ASP-INACTIVE in each AS that it is 1080 a member. 1082 Alternatively, the SG may move the ASP into a pool of Inactive 1083 ASPs available for future configuration within Application Server(s), 1084 determined in a subsequent ASP Active procedure. If the ASP Up 1085 message contains an ASP Identifier, the SG should save the ASP 1086 Identifier for that ASP. The SG MUST send an ASP Up Ack message in 1087 response to a received ASP Up message even if the ASP is already 1088 marked as ASP-INACTIVE at the SG. 1090 If for any local reason (e.g., management lockout) the SG cannot 1091 respond with an ASP Up Ack message, the SG responds to an ASP Up 1092 message with an Error message with reason "Refused - Management 1093 Blocking". 1095 At the ASP, the ASP Up Ack message received is not acknowledged. 1096 Layer Management is informed with an M-ASP_UP confirm primitive. 1098 When the ASP sends an ASP Up message it starts timer T(ack). If 1099 the ASP does not receive a response to an ASP Up message within 1100 T(ack), the ASP MAY restart T(ack) and resend ASP Up messages until 1101 it receives an ASP Up Ack message. T(ack) is provisionable, with a 1102 default of 2 seconds. Alternatively, retransmission of ASP Up 1103 messages MAY be put under control of Layer Management. In this 1104 method, expiry of T(ack) results in an M-ASP_UP confirm primitive 1105 carrying a negative indication. 1107 The ASP must wait for the ASP Up Ack message before sending any 1108 other IUA messages (e.g., ASP Active). If the SG receives any other 1109 IUA messages before an ASP Up message is received (other than ASP 1110 Down - see Section 4.3.3.2), the SG MAY discard them. 1112 If an ASP Up message is received and internally the remote ASP is 1113 in the ASP-ACTIVE state, an ASP Up Ack message is returned, as well 1114 as an Error message ("Unexpected Message), and the remote ASP state 1115 is changed to ASP-INACTIVE in all relevant Application Servers. 1117 If an ASP Up message is received and internally the remote ASP is 1118 already in the ASP-INACTIVE state, an ASP Up Ack message is returned 1119 and no further action is taken. 1121 3.13.3 Solution description 1123 Updated ASP Up procedures based on other UAs. 1125 3.14 ASP Down Procedures 1127 3.14.1 Description of the problem 1129 The ASP Down procedures need to be resynchronized with the other 1130 UAs. 1132 3.14.2 Text changes to the document 1134 --------- 1135 Old text: (Section 4.3.3.2) 1136 --------- 1138 The ASP will send an ASP Down to an SG when the ASP is to be removed 1139 from the list of ASPs in all Application Servers that it is a member 1140 and no longer receive any IUA traffic or management messages. 1142 Whether the ASP is permanently removed from an AS is a function of 1143 configuration management. 1145 The SG marks the ASP as "Down" and returns an ASP Down Ack message to 1146 the ASP if one of the following events occur: 1148 - to acknowledge an ASP Down message from an ASP, 1149 - to reply to ASPM messages from an ASP which is locked out for 1150 management reasons. 1152 The SG sends an ASP Down Ack message in response to a received ASP 1153 Down message from the ASP even if the ASP is already marked as "Down" 1154 at the SG. 1156 If the ASP does not receive a response from the SG, the ASP MAY send 1157 ASP Down messages every 2 seconds until it receives an ASP Down Ack 1158 message from the SG or the SCTP association goes down. The ASP MAY 1159 decide to reduce the frequency (say to every 5 seconds) if an ASP 1160 Down Ack is not received after a few tries. 1162 --------- 1163 New text: (Section 4.3.3.2) 1164 --------- 1166 The ASP will send an ASP Down to an SG when the ASP is to be removed 1167 from the list of ASPs in all Application Servers that it is a member 1168 and no longer receive any IUA traffic or management messages. This 1169 action MAY be initiated at the ASP by an M-ASP_DOWN request primitive 1170 from Layer Management or MAY be initiated automatically by an IUA 1171 management function. 1173 Whether the ASP is permanently removed from an AS is a function of 1174 configuration management. 1176 The SG marks the ASP as ASP-DOWN, informs Layer Management with 1177 an M-ASP_Down indication primitive, and returns an ASP Down Ack 1178 message to the ASP. 1180 The SG MUST send an ASP Down Ack message in response to a received 1181 ASP Down message from the ASP even if the ASP is already marked as 1182 ASP-DOWN at the SG. 1184 At the ASP, the ASP Down Ack message received is not acknowledged. 1185 Layer Management is informed with an M-ASP_DOWN confirm primitive. 1186 If the ASP receives an ASP Down Ack without having sent an ASP Down 1187 message, the ASP should now consider itself as in the ASP-DOWN state. 1188 If the ASP was previously in the ASP-ACTIVE or ASP-INACTIVE state, 1189 the ASP should then initiate procedures to return itself to its 1190 previous state. 1192 When the ASP sends an ASP Down message it starts timer T(ack). If 1193 the ASP does not receive a response to an ASP Down message within 1194 T(ack), the ASP MAY restart T(ack) and resend ASP Down messages until 1195 it receives an ASP Down Ack message. T(ack) is provisionable, with 1196 a default of 2 seconds. Alternatively, retransmission of ASP Down 1197 messages MAY be put under control of Layer Management. In this 1198 method, expiry of T(ack) results in an M-ASP_DOWN confirm primitive 1199 carrying a negative indication. 1201 3.14.3 Solution description 1203 Updated ASP Down procedures based on other UAs. 1205 3.15 ASP Active Procedures 1207 3.15.1 Description of the problem 1209 The ASP Active procedures need to be resynchronized with the other 1210 UAs. 1212 3.15.2 Text changes to the document 1214 --------- 1215 Old text: (Section 4.3.3.4) 1216 --------- 1218 When an ASP Active (ASPAC) message is received, the SG responds to 1219 the ASP with a ASPAC Ack message acknowledging that the ASPAC was 1220 received and starts sending traffic for the associated Application 1221 Server(s) to that ASP. 1223 --------- 1224 New text: (Section 4.3.3.4) 1225 --------- 1227 If the Application Server can be successfully activated, the SG 1228 responds responds to the ASP with a ASPAC Ack message acknowledging 1229 that the ASPAC was received and starts sending traffic for the 1230 Application Server to that ASP. 1232 In the case where an "out-of-the-blue" ASP Active message is 1233 received (i.e., the ASP has not registered with the SG or the 1234 SG has no static configuration data for the ASP), the message 1235 MAY be silently discarded. 1237 The SG MUST send an ASP Active Ack message in response to a 1238 received ASP Active message from the ASP, if the ASP is already 1239 marked in the ASP-ACTIVE state at the SG. 1241 At the ASP, the ASP Active Ack message received is not 1242 acknowledged. Layer Management is informed with an M-ASP_ACTIVE 1243 confirm primitive. It is possible for the ASP to receive Data 1244 message(s) before the ASP Active Ack message as the ASP Active Ack 1245 and Data messages from an SG may be sent on different SCTP streams. 1246 Message loss is possible as the ASP does not consider itself in the 1247 ASP-ACTIVE state until reception of the ASP Active Ack message. 1249 When the ASP sends an ASP Active message it starts timer T(ack). 1250 If the ASP does not receive a response to an ASP Active message 1251 within T(ack), the ASP MAY restart T(ack) and resend ASP Active 1252 messages until it receives an ASP Active Ack message. T(ack) is 1253 provisionable, with a default of 2 seconds. Alternatively, 1254 retransmission of ASP Active messages MAY be put under control of 1255 Layer Management. In this method, expiry of T(ack) results in an 1256 M-ASP_ACTIVE confirm primitive carrying a negative indication. 1258 3.15.3 Solution description 1260 Updated ASP Active procedures based on other UAs. 1262 3.16 ASP Inactive Procedures 1264 3.16.1 Description of the problem 1266 The ASP Inactive procedures need to be resynchronized with the 1267 other UAs. 1269 3.16.2 Text changes to the document 1271 --------- 1272 Old text: (Section 4.3.3.5) 1273 --------- 1275 If no other ASPs are Active in the Application Server, the SG sends a 1276 NTFY (AS-Pending) to all inactive ASPs of the AS and either discards 1277 all incoming messages for the AS or starts buffering the incoming 1278 messages for T(r)seconds, after which messages will be discarded. 1279 T(r) is configurable by the network operator. If the SG receives an 1280 ASPAC from an ASP in the AS before expiry of T(r), the buffered 1281 traffic is directed to the ASP and the timer is cancelled. If T(r) 1282 expires, the AS is moved to the "Inactive" state. 1284 --------- 1285 New text: (Section 4.3.3.5) 1286 --------- 1288 When the ASP sends an ASP Inactive message it starts timer T(ack). 1289 If the ASP does not receive a response to an ASP Inactive message 1290 within T(ack), the ASP MAY restart T(ack) and resend ASP Inactive 1291 messages until it receives an ASP Inactive Ack message. T(ack) 1292 is provisionable, with a default of 2 seconds. Alternatively, 1293 retransmission of ASP Inactive messages MAY be put under control of 1294 Layer Management. In this method, expiry of T(ack) results in a 1295 M-ASP_Inactive confirm primitive carrying a negative indication. 1297 If no other ASPs in the Application Server are in the state 1298 ASP-ACTIVE, the SG MUST send a Notify message ("AS-Pending") to 1299 all of the ASPs in the AS which are in the state ASP-INACTIVE. 1300 The SG SHOULD start buffering the incoming messages for T(r) 1301 seconds, after which messages MAY be discarded. T(r) is 1302 configurable by the network operator. If the SG receives an ASP 1303 Active message from an ASP in the AS before expiry of T(r), the 1304 buffered traffic is directed to that ASP and the timer is cancelled. 1305 If T(r) expires, the AS is moved to the AS-INACTIVE state. 1307 At the ASP, the ASP Inactive Ack message received is not 1308 acknowledged. Layer Management is informed with an M-ASP_INACTIVE 1309 confirm primitive. If the ASP receives an ASP Inactive Ack without 1310 having sent an ASP Inactive message, the ASP should now consider 1311 itself as in the ASP-INACTIVE state. If the ASP was previously in 1312 the ASP-ACTIVE state, the ASP should then initiate procedures to 1313 return itself to its previous state. 1315 3.16.3 Solution description 1317 Updated ASP Inactive procedures based on other UAs. 1319 3.17 Notify Procedures 1321 3.17.1 Description of the problem 1323 The Notify procedures need to be resynchronized with the 1324 other UAs. 1326 3.17.2 Text changes to the document 1328 --------- 1329 Old text: (Section 4.3.3.6) 1330 --------- 1332 A Notify message reflecting a change in the AS state is sent to all 1333 ASPs in the AS, except those in the "Down" state, with appropriate 1334 Status Identification. 1336 --------- 1337 New text: (Section 4.3.3.6) 1338 --------- 1340 A Notify message reflecting a change in the AS state MUST be sent 1341 to all ASPs in the AS, except those in the ASP-DOWN state, with 1342 appropriate Status Information and any ASP Identifier of the 1343 failed ASP. At the ASP, Layer Management is informed with an 1344 M-NOTIFY indication primitive. The Notify message must be sent 1345 whether the AS state change was a result of an ASP failure or 1346 reception of an ASP State management (ASPSM) / ASP Traffic Management 1347 (ASPTM) message. In the second case, the Notify message MUST be 1348 sent after any related acknowledgement messages (e.g., ASP Up Ack, 1349 ASP Down Ack, ASP Active Ack, or ASP Inactive Ack). 1351 3.17.3 Solution description 1353 Updated Notify procedures based on other UAs. 1355 3.18 Heartbeat Text Clarification 1357 3.18.1 Description of the problem 1359 The are some minor error in the Heartbeat procedures text. 1361 3.18.2 Text changes to the document 1363 --------- 1364 Old text: (Section 4.3.3.7) 1365 --------- 1367 After receiving an ASP Up Ack message from the SG in response to an 1368 ASP Up message, the ASP MAY optionally send Beat messages 1369 periodically, subject to a provisionable timer T(beat). The SG IUA, 1370 upon receiving a BEAT message from the ASP, responds with a BEAT ACK 1371 message. If no BEAT message (or any other IUA message) is received 1372 from the SG within the timer 2*T(beat), the SG will consider the 1373 remote IUA as "Down". The SG will also send an ASP Down Ack message 1374 to the ASP. 1376 --------- 1377 New text: (Section 4.3.3.7) 1378 --------- 1380 Either IUA peer may optionally send Heartbeat messages periodically, 1381 subject to a provisionable timer T(beat). Upon receiving a Heartbeat 1382 message, the IUA peer MUST respond with a Heartbeat Ack message. 1384 If no Heartbeat Ack message (or any other IUA message) is received 1385 from the IUA peer within 2*T(beat), the remote IUA peer is 1386 considered unavailable. Transmission of Heartbeat messages is 1387 stopped and the signalling process SHOULD attempt to re-establish 1388 communication if it is configured as the client for the 1389 disconnected IUA peer. 1391 3.18.3 Solution description 1393 Updated Heartbeat procedures based on other UAs. 1395 3.19 Error Message 1397 3.19.1 Description of the problem 1399 There is a need to add the "Refused - Management Blocking" error 1400 code. Need to clearly specify that Error messages are not to be 1401 sent in response to an Error message. 1403 Also, need to indicate that the Diagnostic area must be used 1404 for the Invalid Interface Identifier error. 1406 3.19.2 Text changes to the document 1408 --------- 1409 Old text: (Section 3.3.3.1) 1410 --------- 1412 Invalid Version 0x01 1413 Invalid Interface Identifier 0x02 1414 Unsupported Message Class 0x03 1415 Unsupported Message Type 0x04 1416 Unsupported Traffic Handling Mode 0x05 1417 Unexpected Message 0x06 1418 Protocol Error 0x07 1419 Unsupported Interface Identifier Type 0x08 1420 Invalid Stream Identifier 0x09 1421 Unassigned TEI 0x0a 1422 Unrecognized SAPI 0x0b 1423 Invalid TEI, SAPI combination 0x0c 1425 The "Invalid Version" error would be sent if a message was received 1426 with an invalid or unsupported version. The Error message would 1427 contain the supported version in the Common header. The Error 1428 message could optionally provide the supported version in the 1429 Diagnostic Information area. 1431 The "Invalid Interface Identifier" error would be sent by a SG if an 1432 ASP sends a message with an invalid (unconfigured) Interface 1433 Identifier value. 1435 --------- 1436 New text: (Section 3.3.3.1) 1437 --------- 1439 Invalid Version 0x01 1440 Invalid Interface Identifier 0x02 1441 Unsupported Message Class 0x03 1442 Unsupported Message Type 0x04 1443 Unsupported Traffic Handling Mode 0x05 1444 Unexpected Message 0x06 1445 Protocol Error 0x07 1446 Unsupported Interface Identifier Type 0x08 1447 Invalid Stream Identifier 0x09 1448 Unassigned TEI 0x0a 1449 Unrecognized SAPI 0x0b 1450 Invalid TEI, SAPI combination 0x0c 1451 Refused - Management Blocking 0x0d 1452 ASP Identifier Required 0x0e 1453 Invalid ASP Identifier 0x0f 1455 The "Invalid Version" error would be sent if a message was received 1456 with an invalid or unsupported version. The Error message would 1457 contain the supported version in the Common header. The Error 1458 message could optionally provide the supported version in the 1459 Diagnostic Information area. 1461 The "Invalid Interface Identifier" error would be sent by a SG if an 1462 ASP sends a message with an invalid (unconfigured) Interface 1463 Identifier value. For this error, the Diagnostic Information MUST 1464 contain the Common and IUA message headers of the offending message 1465 so that Invalid Interface Identifier can be identified. 1467 Error messages MUST NOT be generated in response to other Error 1468 messages. 1470 3.19.3 Solution description 1472 Added new error code and clarified that Error messages must not be 1473 generated in response to an Error message. These changes make IUA 1474 more consistent with other UAs. 1476 3.20 Misconfiguration of Interface Identifiers 1478 3.20.1 Description of the problem 1480 Provide some examples of how to handle misconfiguration of Interface 1481 Identifiers. 1483 3.20.2 Text changes to the document 1485 --------- 1486 New text: (Section 5.1.5) 1487 --------- 1489 This scenario shows the example IUA message flows for the 1490 establishment of traffic between an SG and an ASP in which some 1491 of the Interface Identifiers have been misconfigured on the 1492 ASP side. The SG in this case has Interface Identifers 1-5 1493 configured for ASP1. 1495 SG ASP1 1496 | | 1497 | | 1498 |<----ASP Active (IIDs 1-10)-----| 1499 |---ASP Active Ack (IIDs 1-5)--->| 1500 |-------Error (IIDs 6)---------->| 1501 |-------Error (IIDs 7)---------->| 1502 |-------Error (IIDs 8)---------->| 1503 |-------Error (IIDs 9)---------->| 1504 |-------Error (IIDs 10)--------->| 1505 | | 1507 3.20.3 Solution description 1509 An example message flow is provided for the case of Interface 1510 Identifier misconfiguration. 1512 3.21 ASP Inactive Traffic Mode Parameter 1514 3.21.1 Description of the problem 1516 The Traffic Mode Type parameter was removed from ASP Inactive 1517 and ASP Inactive Acknowledgement messages for all other UAs. 1519 3.21.2 Text changes to the document 1521 --------- 1522 Old text: (Section 3.3.2.7) 1523 --------- 1525 The ASPIA message contains the following parameters 1527 Traffic Mode Type (Mandatory) 1528 Interface Identifiers (Optional) 1529 - Combination of integer and integer ranges, OR 1530 - string (text formatted) 1531 INFO String (Optional) 1533 The format for the ASP Inactive message parameters using Integer 1534 formatted Interface Identifiers is as follows: 1536 0 1 2 3 1537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 | Tag (0xb) | Length | 1540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 | Traffic Mode Type | 1542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1543 | Tag (0x1=integer) | Length | 1544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 | Interface Identifiers* | 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Tag (0x8=integer range) | Length | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Interface Identifier Start1* | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | Interface Identifier Stop1* | 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | Interface Identifier Start2* | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Interface Identifier Stop2* | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 . . 1560 . . 1561 . . 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Interface Identifier StartN* | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | Interface Identifier StopN* | 1566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | Additional Interface Identifiers | 1569 | of Tag Type 0x1 or 0x8 | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Tag (0x4) | Length | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | INFO String* | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 The format for the ASP Inactive message using text formatted (string) 1580 Interface Identifiers is as follows: 1582 0 1 2 3 1583 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | Tag (0xb) | Length | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1587 | Traffic Mode Type | 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Tag (0x3=string) | Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Interface Identifier* | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Additional Interface Identifiers | 1597 | of Tag Type 0x3 | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Tag (0x4) | Length | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | INFO String* | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 The Traffic Mode Type parameter identifies the traffic mode of 1608 operation of the ASP within an AS. The valid values for Traffic Mode 1609 Type are shown in the following table: 1611 Value Description 1612 0x1 Over-ride 1613 0x2 Load-share 1615 --------- 1616 New text: (Section 3.3.2.7) 1617 --------- 1619 The ASPIA message contains the following parameters 1621 Interface Identifiers (Optional) 1622 - Combination of integer and integer ranges, OR 1623 - string (text formatted) 1624 INFO String (Optional) 1626 The format for the ASP Inactive message parameters using Integer 1627 formatted Interface Identifiers is as follows: 1629 0 1 2 3 1630 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Tag (0x1=integer) | Length | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Interface Identifiers* | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Tag (0x8=integer range) | Length | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 | Interface Identifier Start1* | 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1642 | Interface Identifier Stop1* | 1643 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1644 | Interface Identifier Start2* | 1645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1646 | Interface Identifier Stop2* | 1647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1648 . . 1649 . . 1650 . . 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 | Interface Identifier StartN* | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Interface Identifier StopN* | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 | Additional Interface Identifiers | 1658 | of Tag Type 0x1 or 0x8 | 1660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1661 | Tag (0x4) | Length | 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1664 | INFO String* | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 The format for the ASP Inactive message using text formatted (string) 1669 Interface Identifiers is as follows: 1671 0 1 2 3 1672 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1674 | Tag (0x3=string) | Length | 1675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Interface Identifier* | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | Additional Interface Identifiers | 1682 | of Tag Type 0x3 | 1684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1685 | Tag (0x4) | Length | 1686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | INFO String* | 1690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 --------- 1693 Old text: (Section 3.3.2.8) 1694 --------- 1695 The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP 1696 Inactive message received from a remote IUA peer. 1698 The ASPIA Ack message contains the following parameters: 1700 Traffic Mode Type (Mandatory) 1701 Interface Identifiers (Optional) 1702 - Combination of integer and integer ranges, OR 1703 - string (text formatted) 1704 INFO String (Optional) 1706 0 1 2 3 1707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1709 | Tag (0xb) | Length | 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Traffic Mode Type | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Tag (0x1=integer) | Length | 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Interface Identifiers* | 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1719 | Tag (0x8=integer range) | Length | 1720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 | Interface Identifier Start1* | 1722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1723 | Interface Identifier Stop1* | 1724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 | Interface Identifier Start2* | 1726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1727 | Interface Identifier Stop2* | 1728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1729 . . 1730 . . 1731 . . 1732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1733 | Interface Identifier StartN* | 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Interface Identifier StopN* | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1738 | Additional Interface Identifiers | 1739 | of Tag Type 0x1 or 0x8 | 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Tag (0x4) | Length | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | INFO String* | 1747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 The format for the ASP Inactive Ack message using text formatted 1750 (string) Interface Identifiers is as follows: 1752 0 1 2 3 1753 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | Tag (0xb) | Length | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | Traffic Mode Type | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Tag (0x3=string) | Length | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Interface Identifier* | 1764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1766 | Additional Interface Identifiers | 1767 | of Tag Type 0x3 | 1769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1770 | Tag (0x4) | Length | 1771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1773 | INFO String* | 1775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 The format of the Traffic Mode Type and Interface Identifier 1778 parameters is the same as for the ASP Inactive message (See Section 1779 3.3.2.7). 1781 --------- 1782 New text: (Section 3.3.2.8) 1783 --------- 1784 The ASP Inactive (ASPIA) Ack message is used to acknowledge an ASP 1785 Inactive message received from a remote IUA peer. 1787 The ASPIA Ack message contains the following parameters: 1789 Interface Identifiers (Optional) 1790 - Combination of integer and integer ranges, OR 1791 - string (text formatted) 1792 INFO String (Optional) 1794 0 1 2 3 1795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Tag (0x1=integer) | Length | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | Interface Identifiers* | 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 | Tag (0x8=integer range) | Length | 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 | Interface Identifier Start1* | 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1807 | Interface Identifier Stop1* | 1808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1809 | Interface Identifier Start2* | 1810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1811 | Interface Identifier Stop2* | 1812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1813 . . 1814 . . 1815 . . 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Interface Identifier StartN* | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 | Interface Identifier StopN* | 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Additional Interface Identifiers | 1823 | of Tag Type 0x1 or 0x8 | 1825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1826 | Tag (0x4) | Length | 1827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | INFO String* | 1831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 The format for the ASP Inactive Ack message using text formatted 1834 (string) Interface Identifiers is as follows: 1836 0 1 2 3 1837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Tag (0x3=string) | Length | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 | Interface Identifier* | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1846 | Additional Interface Identifiers | 1847 | of Tag Type 0x3 | 1849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1850 | Tag (0x4) | Length | 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | INFO String* | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 The format of the Interface Identifier parameters is the same as for 1858 the ASP Inactive message (See Section 3.3.2.7). 1860 3.21.3 Solution description 1862 Remove Traffic Mode Type from ASP Inactive message in order to 1863 remain consistent with other UAs. 1865 3.22 Encoding of the DLCI parameter 1867 3.22.1 Description of the problem 1869 The text states the DLCI field is encoded in accordance to Q.921 1870 and a figure is given. Using the standard interpretation of the IETF 1871 for the significance of bits the encoding described in the figure 1872 is not in accordance to Q.921. 1874 3.22.2 Text changes to the document 1876 -------- 1877 Old text (Section 3.2) 1878 -------- 1880 3.2 IUA Message Header 1882 In addition to the common message header, there will be a specific 1883 message header for QPTM and the TEI Status MGMT messages. The IUA 1884 message header will immediately follow the Common header in these 1885 messages. 1887 This message header will contain the Interface Identifier and Data 1888 Link Connection Identifier (DLCI). The Interface Identifier 1889 identifies the physical interface terminating the signaling channel 1890 at the SG for which the signaling messages are sent/received. The 1891 format of the Interface Identifier parameter can be text or integer. 1892 The Interface Identifiers are assigned according to network operator 1893 policy. The integer values used are of local significance only, 1894 coordinated between the SG and ASP. 1896 The integer formatted Interface Identifier MUST be supported. The 1897 text formatted Interface Identifier MAY optionally be supported. 1899 0 1 2 3 1900 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | Tag (0x1) | Length | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Interface Identifier (integer) | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | Tag (0x5) | Length=8 | 1907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1908 | DLCI | Spare | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1911 Figure 4 IUA Message Header (Integer-based Interface Identifier) 1913 The Tag value for the Integer-based Interface Identifier is 0x1. The 1914 length is always set to a value of 8. 1916 0 1 2 3 1917 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 | Tag (0x3) | Length | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1921 | Interface Identifier (text) | 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 | Tag (0x5) | Length=8 | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 | DLCI | Spare | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1928 Figure 5 IUA Message Header (Text-based Interface Identifier) 1930 The Tag value for the Text-based Interface Identifier is 0x3. The 1931 length is variable. 1933 The DLCI format is shown below in Figure 6. 1935 0 1 2 3 4 5 6 7 1936 +-----+-----+-----+-----+-----+-----+-----+-----+ 1937 | 0 | SPR | SAPI | 1938 +-----------------------------------------------+ 1939 | 1 | TEI | 1940 +-----------------------------------------------+ 1942 Figure 6 DLCI Format 1944 SPR: Spare 2nd bit in octet 1, (1 bit) 1946 SAPI: Service Access Point Identifier, 3rd through 8th bits in octet 1947 1 (6 bits) 1949 TEI: Terminal Endpoint Identifier, 2nd through 8th bits in octet 2 1950 (7 bits) 1952 The DLCI field (including the SAPI and TEI) is coded in accordance 1953 with Q.921. 1955 -------- 1956 New text (Section 3.2) 1957 -------- 1959 3.2 IUA Message Header 1961 In addition to the common message header, there will be a specific 1962 message header for QPTM and the TEI Status MGMT messages. The IUA 1963 message header will immediately follow the Common header in these 1964 messages. 1966 This message header will contain the Interface Identifier and Data 1967 Link Connection Identifier (DLCI). The Interface Identifier 1968 identifies the physical interface terminating the signaling channel 1969 at the SG for which the signaling messages are sent/received. The 1970 format of the Interface Identifier parameter can be text or integer. 1971 The Interface Identifiers are assigned according to network operator 1972 policy. The integer values used are of local significance only, 1973 coordinated between the SG and ASP. 1975 The integer formatted Interface Identifier MUST be supported. The 1976 text formatted Interface Identifier MAY optionally be supported. 1978 0 1 2 3 1979 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Tag (0x1) | Length=8 | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Interface Identifier (integer) | 1984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 | Tag (0x5) | Length=8 | 1986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1987 | DLCI | Spare | 1988 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1990 Figure 4 IUA Message Header (Integer-based Interface Identifier) 1992 The Tag value for the Integer-based Interface Identifier is 0x1. The 1993 length is always set to a value of 8. The Interface Identifier (integer) 1994 is a 32-bit unsigned integer. 1996 0 1 2 3 1997 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | Tag (0x3) | Length | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | Interface Identifier (text) | 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2003 | Tag (0x5) | Length=8 | 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2005 | DLCI | Spare | 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 Figure 5 IUA Message Header (Text-based Interface Identifier) 2010 The Tag value for the Text-based Interface Identifier is 0x3. The 2011 length is variable. 2013 The DLCI format is shown below in Figure 6. 2015 most least 2016 significant significant 2017 bit bit 2018 +-----+-----+-----+-----+-----+-----+-----+-----+ 2019 | SAPI | SPR | 0 | 2020 +-----------------------------------------------+ 2021 | TEI | 1 | 2022 +-----------------------------------------------+ 2024 Figure 6 DLCI Format 2026 SPR: Spare 2nd bit in octet 1, (1 bit) 2028 SAPI: Service Access Point Identifier, (6 bits) 2030 TEI: Terminal Endpoint Identifier, (7 bits) 2032 As an example SAPI = 0, TEI = 64, SPR = 0 would be encoded as 2034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2035 | Tag (0x5) | Length=8 | 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | 0x0 | 0x81 | 0x0 | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2040 The DLCI field (including the SAPI and TEI) is coded in accordance 2041 with Q.921. 2043 3.22.3 Solution description 2045 It is now clearly stated that the DLCI field is encoded in accordance 2046 with Q.921. 2048 3.23 Updates to Message Flow Examples 2050 3.23.1 Description of the problem 2052 The message flow examples in Section 5 were missing Notify 2053 messages. 2055 3.23.2 Text changes to the document 2057 -------- 2058 Old text (Section 5.1.1) 2059 -------- 2061 SG ASP1 2062 | 2063 |<---------ASP Up----------| 2064 |--------ASP Up Ack------->| 2065 | | 2066 |<-------ASP Active--------| 2067 |------ASP Active Ack----->| 2068 | | 2070 -------- 2071 New text (Section 5.1.1) 2072 -------- 2074 SG ASP1 2075 | 2076 |<---------ASP Up----------| 2077 |--------ASP Up Ack------->| 2078 | | 2079 |-----NTFY(AS-INACTIVE)--->| 2080 | | 2081 |<-------ASP Active--------| 2082 |------ASP Active Ack----->| 2083 | | 2084 |------NTFY(AS-ACTIVE)---->| 2085 | | 2087 -------- 2088 Old text (Section 5.1.2) 2089 -------- 2091 SG ASP1 ASP2 2092 | | | 2093 |<--------ASP Up----------| | 2094 |-------ASP Up Ack------->| | 2095 | | | 2096 |<-----------------------------ASP Up----------------| 2097 |----------------------------ASP Up Ack------------->| 2098 | | | 2099 | | | 2100 |<-------ASP Active-------| | 2101 |-----ASP Active Ack----->| | 2102 | | | 2104 -------- 2105 New text (Section 5.1.2) 2106 -------- 2108 SG ASP1 ASP2 2109 | | | 2110 |<--------ASP Up----------| | 2111 |-------ASP Up Ack------->| | 2112 | | | 2113 |----NTFY(AS-INACTIVE)--->| | 2114 | | | 2115 |<-----------------------------ASP Up----------------| 2116 |----------------------------ASP Up Ack------------->| 2117 | | | 2118 | | | 2119 |<-------ASP Active-------| | 2120 |-----ASP Active Ack----->| | 2121 | | | 2122 |-----NTFY(AS-ACTIVE)---->| | 2123 |----------------------NTFY(AS-ACTIVE)-------------->| 2125 -------- 2126 Old text (Section 5.1.3) 2127 -------- 2129 SG ASP1 ASP2 2130 | | | 2131 |<---------ASP Up---------| | 2132 |--------ASP Up Ack------>| | 2133 | | | 2134 |<------------------------------ASP Up---------------| 2135 |-----------------------------ASP Up Ack------------>| 2136 | | | 2137 | | | 2138 |<--ASP Active (Ldshr)----| | 2139 |----ASP Active Ack------>| | 2140 | | | 2141 |<----------------------------ASP Active (Ldshr)-----| 2142 |-----------------------------ASP Active Ack-------->| 2143 | | | 2145 -------- 2146 New text (Section 5.1.3) 2147 -------- 2149 SG ASP1 ASP2 2150 | | | 2151 |<---------ASP Up---------| | 2152 |--------ASP Up Ack------>| | 2153 | | | 2154 |----NTFY(AS-INACTIVE)--->| | 2155 | | | 2156 |<------------------------------ASP Up---------------| 2157 |-----------------------------ASP Up Ack------------>| 2158 | | | 2159 | | | 2160 |<--ASP Active (Ldshr)----| | 2161 |----ASP Active Ack------>| | 2162 | | | 2163 |-----NTFY(AS-ACTIVE)---->| | 2164 |----------------------NTFY(AS-ACTIVE)-------------->| 2165 | | | 2166 |<----------------------------ASP Active (Ldshr)-----| 2167 |-----------------------------ASP Active Ack-------->| 2168 | | | 2170 -------- 2171 Old text (Section 5.1.4) 2172 -------- 2174 SG ASP1 ASP2 ASP3 2175 | | | | 2176 |<------ASP Up-------| | | 2177 |-----ASP Up Ack---->| | | 2178 | | | | 2179 |<--------------------------ASP Up-------| | 2180 |------------------------ASPUp Ack)----->| | 2181 | | | | 2182 |<---------------------------------------------ASP Up--------| 2183 |--------------------------------------------ASP Up Ack----->| 2184 | | | | 2185 | | | | 2186 |<-ASP Act (Ldshr)---| | | 2187 |----ASP Act Ack---->| | | 2188 | | | | 2189 |<---------------------ASP Act (Ldshr)---| | 2190 |----------------------ASP Act Ack------>| | 2191 | | | | 2193 -------- 2194 New text (Section 5.1.4) 2195 -------- 2197 SG ASP1 ASP2 ASP3 2198 | | | | 2199 |<------ASP Up-------| | | 2200 |-----ASP Up Ack---->| | | 2201 | | | | 2202 |-NTFY(AS-INACTIVE)->| | | 2203 | | | | 2204 |<--------------------------ASP Up-------| | 2205 |-----------------------ASP Up Ack------>| | 2206 | | | | 2207 |<---------------------------------------------ASP Up--------| 2208 |--------------------------------------------ASP Up Ack----->| 2209 | | | | 2210 | | | | 2211 |<-ASP Act (Ldshr)---| | | 2212 |----ASP Act Ack---->| | | 2213 | | | | 2214 |<---------------------ASP Act (Ldshr)---| | 2215 |----------------------ASP Act Ack------>| | 2216 | | | | 2217 |--NTFY(AS-ACTIVE)-->| | | 2218 |---------------NTFY(AS-ACTIVE)--------->| | 2219 |------------------------NTFY(AS-ACTIVE)-------------------->| 2221 -------- 2222 Old text (Section 5.2.1) 2223 -------- 2225 SG ASP1 ASP2 2226 | | | 2227 |<-----ASP Inactive-------| | 2228 |----ASP Inactive Ack---->| | 2229 |-------------------NTFY(AS-Pending) --------------->| 2230 | | | 2231 |<------------------------------ ASP Active----------| 2232 |-----------------------------ASP Active Ack)------->| 2233 | | 2235 -------- 2236 New text (Section 5.2.1) 2237 -------- 2239 SG ASP1 ASP2 2240 | | | 2241 |<-----ASP Inactive-------| | 2242 |----ASP Inactive Ack---->| | 2243 | | | 2244 |----NTFY(AS-Pending)---->| | 2245 |-------------------NTFY(AS-Pending)---------------->| 2246 | | | 2247 |<------------------------------ ASP Active----------| 2248 |-----------------------------ASP Active Ack)------->| 2249 | | | 2250 |----NTFY(AS-ACTIVE)----->| | 2251 |-------------------NTFY(AS-ACTIVE)----------------->| 2253 3.23.3 Solution description 2255 The new text shows when the SG should send Notify messages. 2257 4.0 Acknowledgements 2259 The author would like to thank the following people that have 2260 provided comments and input for this document: Alex Audu, 2261 Greg Sidebottom, Srinivasa A. Shikaripura, Subhodeep Sarkar, 2262 Sujatha Krao, Ming Lin, Shih-Chang Liang, Michael Tuexen and 2263 Kameshwar Mallampalli. 2265 5.0 Authors Addresses 2267 Ken A. Morneault 2268 13615 Dulles Technology Drive 2269 Herndon, VA 20171 2270 USA 2272 EMail: kmorneau@cisco.com 2274 6.0 References 2276 [RFC3057] - Morneault K., Rengasami S., Kalla M., Sidebottom G. - 2277 "ISDN Q.921-User Adaptation (IUA) Protocol", RFC 3057, February 2278 2001.