idnits 2.17.1 draft-rao-sigtran-v5ua-01.txt: ** The Abstract section seems to be numbered 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2000) is 8564 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 746, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 753, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 757, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 761, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 765, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 769, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 772, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Sanjay Rao 2 Neeraj Khanchandani 3 Fahir Ergincan 4 Eva Weilandt 5 Anil Vydyam 6 Ranjith Mukundan 7 Narsimuloo Mangalpally 8 Internet Draft Nortel Networks 10 Expires in 6 months November 2000 12 V5.2 and DPNSS/DASS 2 extensions to the IUA protocol 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet- Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 1. Abstract 38 This document defines a mechanism for backhauling of V5.2, DPNSS and 39 DASS 2 messages over IP by extending the ISDN User Adaptation Layer 40 Protocol (). The document aims to 41 become an Appendix to IUA and to be the base for V5.2 and DUA 42 (DPNSS/DASS 2 User Adaptation layer) implementation. 44 Table of Contents 46 1.0 Introduction ......................................... 2 47 2.0 V5UA ................................................. 2 49 Vydyam, Mukundan, Mangalpally 50 2.1.1 Scope .............................................. 2 51 2.1.2 Terminology ........................................ 3 52 2.1.3 V5.2 Overview ...................................... 4 53 2.1.4 Addition to boundary primitives .................... 6 54 2.1.4.1 V5 specific boundary primitives .................. 6 55 2.2.0 Proposed V5.2 Backhaul Architecture ................ 7 56 2.2.1 IUA Message Header for V5.2 ........................ 8 57 2.2.2 V5 Additions to IUA Boundaries ..................... 9 58 2.2.3 V5 Layer 1 Failure Message ......................... 9 59 3.0 DUA .................................................. 9 60 3.1.1 Scope .............................................. 10 61 3.1.2 Terminology ........................................ 10 62 3.1.3 DPNSS Overview ..................................... 10 63 3.1.4 Proposed DPNSS Backhaul Architecture ............... 10 64 3.2.0 Changes from IUA ................................... 11 65 3.2.1 Message Header ..................................... 12 66 3.2.2 Adaptation Layer Identifier ........................ 13 67 3.2.3 Unit Data Message .................................. 13 68 3.2.4 Status Message ..................................... 13 69 3.2.5 Error Message ...................................... 14 70 3.3.0 IANA Considerations ................................ 14 71 3.4.0 Message Sequence in DUA ............................ 15 72 3.4.1 Resetting of single DLC ............................ 15 73 3.4.2 Resetting all DLCs in a link ....................... 15 74 3.4.3 Information Transfer on a DLC ...................... 15 75 3.4.4 Link Takedown(Single DLC) .......................... 16 76 3.4.5 Link Takedown(All DLCs) ............................ 16 77 3.4.6 Getting link Status ................................ 16 78 3.4.7 Error conditions ................................... 16 79 3.4.8 Glossary of Terms .................................. 16 80 4.0 References ........................................... 17 81 5.0 Author's Addresses ................................... 17 82 5.1 V5UA Authors ......................................... 17 83 5.2 DUA Authors .......................................... 18 85 1.0 Introduction 87 This document describes a method of implementing V5.2 & DPNSS/DASS2 88 backhaul messaging over IP using a modified version of the ISDN 89 User Adaptation Protocol (IUAP). This document aims to 90 become an Appendix to IUA and to be the base for the "appli- 91 cation guide". 93 2.0 V5UA 95 2.1.1 Scope 97 Vydyam, Mukundan, Mangalpally 98 There is a need for a V5.2 backhaul to meet the following 99 access types: 101 - Analog telephone access 103 - ISDN Basic rate access 105 - ISDN Primary Rate access (V5.2) 107 - Other analog or digital accesses for semi-permanent 108 connections without associated outband signaling 109 information. 111 2.1.2 Terminology 113 Bearer Channel Connection (BCC) protocol - A protocol which 114 allows the LE to instruct the AN to allocate bearer 115 channels, either singly or in multiples, on demand. 117 Communication channel (C-channel) - A 64 kbit/s time slot on 118 a V5.2 interface provisioned to carry communication 119 paths. 121 Communication path (C-path) - Any one of the following 122 information types: 124 - The layer 2 data link carrying the Control protocol 126 - The layer 2 data link carrying the Link Control protocol 128 - The layer 2 data link carrying the PSTN signaling 130 - Each of the layer 2 data links carrying the protection 131 protocol 133 - The layer 2 data link carrying the BCC protocol 135 - All the ISDN Ds-type data from one or more user ports 137 - All the ISDN p-type data from one or more user ports 139 - All the ISDN t-type data from one or more user ports 141 Note: This definition includes the possibility that 142 there is more than one C-path of the same information 144 Vydyam, Mukundan, Mangalpally 145 type, each allocated to a different logical C-channel. 147 Logical Communication channel (Logical C-channel) - A group 148 of one or more C-paths, all of different types, but 149 excluding the C-path for the protection protocol. 151 Multi-link - A collection of more than one 2.048 kbit/s link 152 which together make up a V5.2 interface. 154 Multi-Slot - A group of more than one 64kbit/s channels pro- 155 viding 8Khz and time slot sequence integrity, generally 156 used together within an ISDN Primary Rate Access 157 (ISDN-PRA) user port, in order to supply a higher bit- 158 rate service. 160 Physical Communication Channel (Physical C-channel) - A 161 64kbit/s time slot on a V5.2 interface which has been 162 assigned for carrying logical C-channels. A physical 163 C-channel may not be used for carrying bearer channels. 165 Primary Link - A 2.048 kbit/s link in a multi-link V5.2 166 interface whose physical C-channel in time slot 16 carries a C- 167 path for the protection protocol and, on V5.2 168 initialization, also the C-path for the control protocol, link 169 control protocol, and the BCC protocol. Other 170 C-paths may also be carried in the time slot 16. 172 Secondary Link - A 2.048 kbit/s link in a multi-link V5.2 173 interface whose time slot 16 carries a C-path for the 174 protection protocol, and, on V5.2 initialization, acts 175 as the standby C-channel for the control protocol, link 176 control protocol, and BCC protocol and any other C- 177 paths initially carried in time slot 16 of the primary 178 link. 180 2.1.3 V5.2 Overview 182 V5.2 is an industry standard ETSI interface (reference ETS 183 300 347-1) defined between a Local Exchange (LE) and an Access 184 Network (AN) providing access to the following types: 186 Vydyam, Mukundan, Mangalpally 187 - Analog telephone access 189 - ISDN Basic rate access 191 - ISDN Primary Rate access (V5.2) 193 - Other analog or digital accesses for semi-permanent 194 connections without associated outband signaling 195 information 197 The original V5 specification uses 2048 kbps links, 198 V5.2 may use upto 16 such interface links. 200 ---------- ---------- o--o 201 | | E1 | |------- / 202 | |--------------| | -- 203 | LE | E1 | AN | 204 | |--------------| | o--o 205 | | | |------- / 206 ---------- ---------- -- 208 LE and AN are connected with up to 16 E1 (PCM30) links. 209 Channels 16, 15 and 31 on any E1 link can be reserved for 210 data communication between LE and AN. The channels reserved 211 for data are called "Communication Channels" or "C- 212 Channels." 214 The C-Channels are the physical media to exchange data 215 between the V5.2 protocol peer entities, as well as to 216 transfer the ISDN BRI D-Ch messages between the terminals 217 and the LE. A logical communication path between two peer 218 entities is called a "C-path". 220 The signaling information in V5.2 are defined as: 222 - Analog signals are carried by means of the V5 PSTN 223 protocol (L3) 225 - ISDN/analog ports are controlled by the V5 Control 226 protocol (L3) 228 - ISDN protocol messages are mapped to LAPD frames, 229 which are carried by means of LAPV5-EF sublayer (L2) 231 Vydyam, Mukundan, Mangalpally 233 - V5 protocol messages are mapped to LAPV5-DL frames, 234 which are carried by means of LAPV5-EF sublayer (L2) 236 In order to support more traffic and dynamic allocation of 237 links, the V5.2 protocol has several additions: 239 - A bearer channel connection protocol establishes and 240 de-establishes bearer connections required on demand, 241 identified by the signalling information, under the 242 control of the Local Exchange. 244 - A link control protocol is defined for the multi-link 245 management to control link identification, link 246 blocking and link failure conditions. 248 - A protection protocol, operated on two separate data 249 links for security reasons, is defined to manage the 250 protection switching of communication channels in 251 case of link failures. 253 The following protocols are defined for the various protocol 254 layers: 256 - LAPV5-EF 258 - LAPV5-DL 260 - V5-Link Control 262 - V5-BCC 264 - V5-PSTN 266 - V5-Control 268 - V5-Protection 270 2.1.4 Addition to boundary primitives 272 2.1.4.1 V5 specific boundary primitives 274 V5.2 introduces new boundary primitives in addition to the 275 ones defined for the Q.921/Q.931 boundary. 277 Vydyam, Mukundan, Mangalpally 278 This includes new primitives between system management and 279 the data link layer [2]: 281 MDL-ESTABLISH 283 The MDL-Establish primitives are used to request, indicate 284 and confirm the outcome of the procedures for establishing 285 multiple frame operation. 287 MDL-RELEASE 289 The MDL-Release primitive is used to indicate the outcome of 291 the procedures for terminating multiple frame operation. 293 MDL-LAYER_1_FAILURE 295 The MDL-Layer_1_Failure primitive is used by the system 296 management to indicate the condition of the physical layer 297 to the data link layer. 299 2.2.0 Proposed V5.2 Backhaul Architecture 301 ****** V5.2 ****** IP ******* 302 * AN *---------------* SG *--------------* MGC * 303 ****** ****** ******* 305 +-----+ +-----+ 306 |V5.2 | (NIF) |V5.2 | 307 +-----+ +----------+ +-----+ 308 | | | | IUA| | IUA | 309 | | | +----+ +-----+ 310 |LAPV5| |LAPV5|SCTP| |SCTP | 311 | | | +----+ +-----+ 312 | | | | IP + | IP | 313 +-----+ +-----+----+ +-----+ 315 NIF - Nodal Interworking function EP - End Point SCTP - 316 Stream Control Transmission Protocol IUA - ISDN User Adaptation 317 Layer Protocol 319 Vydyam, Mukundan, Mangalpally 321 2.2.1. IUA Message Header for V5.2 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Tag (0x1) | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Interface Identifier (integer) | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | DLCI | Spare | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 Figure 2 Original IUA Message Header 335 For the V5 extension of the IUA Message Header, the Envelope 336 Function Address (EFA) field is included in the last 13 bits 337 of the Spare field. 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Tag (0x1) | Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Interface Identifier (integer) | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | DLCI | | EFA | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3 IUA Message Header for V5.2 351 The EFA identifies a C-path, which is a 13-bit number, 352 ranging from 0 to 8191 (decimal). An EFA uniquely identifies 353 one of the five V5.2 protocols, or an ISDN agent attached to 354 an AN. The following list contains the possible values for 355 the EFA 357 Definition Value 358 ---------- ------ 359 ISDN_PROTOCOL 0 - 8175 360 PSTN_PROTOCOL 8176 361 CC_PROTOCOL 8177 362 BCC_PROTOCOL 8178 364 Vydyam, Mukundan, Mangalpally 365 PROT_PROTOCOL 8179 366 LINK_CONTROL_PROTOCOL 8180 367 RESERVED 8181 - 8191 369 2.2.2 V5 Additions to IUA Boundaries 371 Primitives for the V5 interface are identified by the Message Class 372 parameter in the Common Message Header for Q.921 user adaptation. 373 The valid message class for V5 primitives is: 375 6 Q.921/Q.932 Boundary Primitives Transport 376 Messages for V5 (QPTMV5) 378 The boundary primitives that are defined for the Q.921/Q.931 379 boundary are reused for the V5 messages. The following list 380 contains the names of the messages valid for V5.2: 382 Q.921/Q.931 Boundary Primitives Transport Messages 384 1 Data Request Message 385 2 Data Indication Message 386 5 Establish Request 387 6 Establish Confirm 388 7 Establish Indication 389 8 Release Request 390 9 Release Confirm 391 10 Release Indication 393 The following new message is defined for the Q.921/Q.931 394 boundary for V5 only: 396 11 Layer 1 Failure Indication 398 2.2.3 V5 Layer 1 Failure Message 400 The V5 Layer 1 Failure Message is used by the system manage- 401 ment to indicate the data link layer that a layer 1 failure 402 has occured. This primitive is send per protocol on a c- 403 channel. 404 The V5 Layer 1 Failure Message contains the common message 405 header followed by IUA message header. It does not contain 406 any additional parameters. 408 3.0 DUA 410 Vydyam, Mukundan, Mangalpally 411 3.1.1 Scope 413 There is a need for Switched Circuit Network (SCN) signaling 414 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 415 Gateway Controller (MGC). The delivery mechanism should support the 416 following protocols: 418 - DPNSS(Digital Private Network Signaling System) 419 - DASS 2 (Digital Access Signaling System No 2) 421 Unless specifically mentioned the details in this document are 422 applicable to both DPNSS and DASS2. 424 3.1.2 Terminology 426 Data channel (D-channel) - A 64 kbit/s time slot which functions 427 as a common signaling channel on a 2048 kbits/s interface or a 428 1544 kbits/s interface which is provisioned to carry DPNSS 429 signaling. 431 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 432 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 433 interface are termed as DPNSS channels. These are the 434 traffic channels which carry voice or data traffic. 435 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 436 - DASS2 supports 30 Channels (All Real) 438 Data Link Connection(DLC) - A DLC is the level 2 process that 439 controls the transfer of level 3 messages on behalf of one 440 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 441 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 442 - DASSII supports 30 DLCs (All Real) 444 DPNSS Link - A logical collection of the D-channel and the 445 associated DPNSS channels in a 2048 kbits/s interface or a 446 1544 kbits/s interface is called a "DPNSS Link". 448 3.1.3 DPNSS Overview 450 DPNSS is an industry standard interface (reference BTNR 188) 451 defined between a PBX and an Access Network (AN). 453 DPNSS extends facilities normally only available between 454 extensions on a single PBX to all extensions on PBXs that are 455 connected together in a private network. DPNSS was originally 456 derived from BT's Digital Access Signaling System I (DASS I) 458 Vydyam, Mukundan, Mangalpally 459 enhanced where necessary to meet the private network requirements. 460 Some of these enhancements were incorporated in DASS 2. 461 DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital Transmission 462 System Interface as shown in figure 1 below. 464 ---------- ---------- o--o 465 | | 2048 kbits/s | |------- /\ 466 | |--------------| | -- 467 | PBX | 1544 kbits/s | AN | 468 | |--------------| | o--o 469 | | | |------- /\ 470 ---------- ---------- -- 471 Figure 1 473 Channels 16 on a 2048 kbits/s interface and channel 24 on a 474 1544 kbits/s interface is reserved for data communication 475 between LE and AN. The channels reserved for data are called 476 "Data Channels" or "D-Channels." 478 The D-Channels are the physical media to exchange data 479 between the DPNSS protocol peer entities. 480 A logical collection of the D-channel and the 481 associated DPNSS channels is called a "DPNSS Link". 483 3.1.4 Proposed DPNSS Backhaul Architecture 485 ****** DPNSS ****** IP ******* 486 *PBX *---------------* SG *--------------* MGC * 487 ****** ****** ******* 489 +-----+ +-----+ 490 |DPNSS| (NIF) |DPNSS| 491 | L3 | | L3 | 492 +-----+ +----------+ +-----+ 493 | | | | DUA| | DUA | 494 |DPNSS| |DPNSS+----+ +-----+ 495 | L2 | | L2 |SCTP| |SCTP | 496 | | | +----+ +-----+ 497 | | | | IP + | IP | 498 +-----+ +-----+----+ +-----+ 500 NIF - Nodal Interworking function 501 SCTP - Stream Control Transmission Protocol 502 DUA - DPNSS User Adaptation Layer Protocol 504 3.2.0 Changes from IUA 506 Vydyam, Mukundan, Mangalpally 507 The following section outlines the differences between DUA and IUA 509 3.2.1 Message Header 511 IUA Message header has the format as shown in Figure 2 below. 513 0 1 2 3 514 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 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | Tag (0x1) | Length | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Interface Identifier | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | DLCI | Spare | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 2 IUA Message Header 525 In DUA header DLCI field has a different format in accordance with 526 the BTNR 188. 528 0 1 529 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Indicator |0|Channel No.|1| 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 The indicator field is used to determine whether the message is for 535 a particular DLC or it is applicable for all the DLCs in the 536 carrier. The possible values of the indicator is mentioned below. 538 Value Description 540 0 Action is to be performed on all DLCs 541 Channel number parameter is ignored. 543 1 Action is to be performed on a single 544 DLC specified by channel number. 546 This indicator value is used only by the Est and Rel messages. 547 Data messages should ignore this value. 548 This indicator is provided so that a single command can be issued to 549 establish or release all the DLCs in one DPNSS Link. 551 Vydyam, Mukundan, Mangalpally 552 For channel number the valid values are 0 to 63 for DPNSS and 0 to 553 31 for DASS 2. This is because DASS 2 does not support virtual DLCs 554 and hence has only 32 DLCs. 556 3.2.2 Adaptation Layer Identifier 558 Adaptation Layer Identifier string must be set to "DUA" for the DUA 559 applications. 561 3.2.3 Unit Data Message 563 DPNSS layer 2 does not have a unit data primitive and hence the 564 Unit Data Messages (Request, Indication) are invalid for a DUA 565 application. 567 3.2.4 Status Message 569 IUA MIUA-TEI STATUS Message has the following format: 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Status | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 In DUA this will be known as the Status message and will have the 577 following format. 579 0 1 2 3 580 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 581 DLC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 1 | | | | | | | | | | | | | | | | |16 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 17 | | | | | | | | | | | | | | | | |32 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 33 | | | | | | | | | | | | | | | | |48 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 49 | | | | | | | | | | | | | | | | |64 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 These 4 words carry the status of DLCs using two bits for each DLC. 592 These are the possible values for these two bits. 594 Value Description 595 00 Out Of Service 596 01 Reset Attempted 597 10 Reset Completed 598 11 Information Transfer 600 Vydyam, Mukundan, Mangalpally 602 For DASS 2 there are no virtual DLCs and hence information about 603 only 32 DLCs need to be carried. Therefore the status message will 604 have only 2 words instead of 4 for DPNSS. 606 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 607 DLC does not have this state. 609 3.2.5 Error Message 611 The ERR message is sent when an invalid value is found in an 612 incoming message. 614 The Error Code parameter indicates the reason for the Error Message. 615 These are the supported values in IUA. 617 Invalid Version 0x1 618 Invalid Interface Identifier 0x2 619 Invalid Adaptation Layer Identifier 0x3 620 Invalid Message Type 0x4 621 Invalid Stream Identifier 0x5 622 Unassigned TEI 0x6 623 Unrecognized SAPI 0x7 624 Invalid TEI, SAPI combination 0x8 625 Invalid AS Mode Type 0x9 627 In DUA the error codes 0x6 to 0x8 are invalid as they are specific 628 to ISDN. 630 The following additional error codes are supported in DUA. 632 Channel Number out of range 0xA 633 Channel Not configured 0xB 635 3.3.0 IANA Considerations 637 A request will be made to IANA to assign a DUA value for the Payload 638 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 639 Payload Protocol Identifier will be registered: 641 The SCTP Payload Protocol Identifier is included in each SCTP Data 642 chunk, to indicate which protocol the SCTP is carrying. This Payload 643 Protocol Identifier is not directly used by SCTP but may be used by 644 certain network entities to identify the type of information being 645 carried in a Data chunk. 647 The User Adaptation peer may use the Payload Protocol Identifier as 649 Vydyam, Mukundan, Mangalpally 650 a way of determining whether the message is for IUA or DUA. 652 3.4.0 Message Sequence in DUA 654 An example of the message flows for establishing a data link on a 655 signaling channel, passing PDUs and releasing a data link on a 656 DPNSS channel is shown below. An active association between MGC 657 and SG is established prior to the following message flows. 659 3.4.1 Resetting of single DLC 661 i) Successful 663 PBX SG MGC 664 <----------- SABMR <----------- Est Req(Ind=1) 665 UA -----------> Est Cfm -----------> (DLC in RC 666 State) 667 (Ind=1) 669 ii) Unsuccessful(Link Failure) 671 PBX SG MGC 672 <----------- SABMR <----------- Est Req(Ind=1) 673 Retransmissions over 674 NT1 and NT2 expired 675 Rel Ind -----------> (DLC in RA state) 676 (RELEASE_PHYS,Ind=1) 678 3.4.2 Resetting all DLCs in a link 680 PBX SG MGC 682 <----------- SABMR(1) <----------- Est Req(Ind=0) 683 <----------- SABMR(2) 684 <----------- SABMR(3) 685 ............. 686 <----------- SABMR(N) 687 In each DLC either 688 UA is received or 689 NT1/NT2 is expired 690 Est Cfm -----------> (Status of DLCs 691 (Ind=0) are not updated) 692 <----------- Stat Req 693 Stat Res -----------> (Mark DLC status 694 based on status bits) 696 3.4.3 Information Transfer on a DLC 698 Vydyam, Mukundan, Mangalpally 699 PBX SG MGC 700 <----------- UI(C) <----------- Data Req 701 UI(C)-----------> Data Ind -----------> 703 3.4.4 Link Takedown(Single DLC) 705 PBX SG MGC 706 (For DPNSS, mark DLC as OOS) <----------- Rel Req 707 (For DASSII, mark DLC as RA) (RELEASE_MGMT,Ind=1) 708 Rel Cfm ----------> 709 (Ind=1) 711 3.4.5 Link Takedown(All DLCs) 713 PBX SG MGC 714 (For DPNSS, mark all DLCs as OOS) <----------- Rel Req 715 (For DASSII, mark all DLCs as RA) (RELEASE_MGMT,Ind=0) 716 Rel Cfm ----------> 717 (Ind=0) 719 3.4.6 Getting link Status 721 PBX SG MGC 722 <----------- Stat Req 723 Stat Res -----------> (Mark DLC status 724 based on status bits) 726 3.4.7 Error conditions 727 PBX SG MGC 728 Invalid Message ----------- 729 Est/Rel/Data/Stat Req 730 Error Ind -----------> 731 (Error Code) 733 3.4.8 Glossary of terms 735 Real channel : The signalling channel with associated 736 traffic channel (TS). 737 Virtual channel: The signalling channel with no 738 associated traffic channel. 739 NT1 : Retransmission period of 500msec. 740 NT2 : Recommended value is 64. 742 Vydyam, Mukundan, Mangalpally 744 4.0 References 746 [1] ISDN Q.921-User Adaptation Layer 749 [2] EN 300 324-1 (1999): V interfaces at the digital Local 750 Exchange (LE); V5.1 interface for the support of Access 751 Network (AN); Part 1: V5.1 interface specification. 753 [3] EN 300 347-1 (1999): V interfaces at the digital Local 754 Exchange (LE); V5.2 interface for the support of Access 755 Network (AN); Part 1: V5.2 interface specification. 757 [4] ETS 300 125 (1991) : DSS1 protocol; User-Network inter- 758 face data link layer specification; (Standard is based 759 on : ITU Q.920, Q.921). 761 [5] ETS 300 166 (08/1993) : Transmission and Multiplexing; 762 Physical and electrical characteristic of hierarchical 763 digital interfaces (Standard is based on G.703). 765 [6] ETS 300 167 (08/1993) : Transmission and Multiplexing; 766 Functional characteristic of 2048 kbits/s interfaces 767 (Standard is based on G.704, G.706). 769 [7] BTNR (British Telecom Network Requirements) 188 Issue 6 770 Digital Private Network Signaling System 1 772 [8] BTNR (British Telecom Network Requirements) 190 Issue 2 773 Digital Access Signaling System No 2 775 5.0 Authors' Addresses 777 5.1 V5UA Authors 779 Sanjay Rao Tel +1-919-991-2251 780 Nortel Networks Email rsanjay@nortelnetworks.com 781 35 Davis Drive 782 Research Triangle Park, NC 27709 783 USA 785 Neeraj Khanchandani Tel +1-919-991-2274 786 Nortel Networks Email neerajk@nortelnetworks.com 787 35 Davis Drive 788 Research Triangle Park, NC 27709 790 Vydyam, Mukundan, Mangalpally 791 USA 793 Dr. Fahir Ergincan Tel +49 7545 96 8844 794 Nortel-Dasa Network Systems Email fahir@nortelnetworks.com 795 88039 Friedrichshafen 796 Germany 798 Dr. Eva Weilandt Tel +49 7545 96 7267 799 Nortel-Dasa Network Systems Email eva.weilandt@nortelnetworks.com 800 88039 Friedrichshafen 801 Germany 803 5.2 DUA Authors 805 Authors : Anil Vydyam, Ranjith Mukundan and Narsimuloo Mangalpally 807 All correspondence regarding DUA should be sent to 808 the following address : 810 Mick Dragon Tel. +44 1628 43 4388 811 Nortel Networks plc Email. mdragon@nortelnetworks.com 812 Concorde Road 813 Maidenhead 814 Berkshire SL6 4AG 815 United Kingdom 817 Vydyam, Mukundan, Mangalpally