idnits 2.17.1 draft-ietf-sigtran-dua-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. == In addition to a regular copyright notice, the document also has a copyright notice embedded in the text. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 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 212: '... The IUA Message Header [1] MUST be used with the DPTM messages,...' RFC 2119 keyword, line 395: '...otocol Identifier field SHOULD be used...' RFC 2119 keyword, line 401: '...r SCTP Payload Protocol ID MAY also be...' RFC 2119 keyword, line 408: '...tocol ID of "10" SHOULD be used for DU...' RFC 2119 keyword, line 415: '...rectly used by SCTP but MAY be used by...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (Sept 2004) is 7436 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: '5' is defined on line 534, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3057 (ref. '1') (Obsoleted by RFC 4233) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Ranjith Mukundan 2 Internet Engineering Task Force Wipro Technologies 3 Ken Morneault 4 Cisco Systems 5 N Mangalpally 6 Nortel Networks 7 Expires: March 2005 Issued: Sept 2004 9 DPNSS/DASS 2 extensions to the IUA protocol 10 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 or will be disclosed, and any of which I become aware will be 17 disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document defines a mechanism for backhauling Digital Private 38 Network Signaling System 1 (DPNSS 1) and Digital Access Signaling 39 System 2 (DASS 2) messages over IP by extending the ISDN User 40 Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, 41 specified in ND1301:2001/03 (formerly BTNR 188), is used to 42 interconnect Private Branch Exchanges (PBX) in a private network 43 and DASS 2, specified in BTNR 190, is used to connect PBXs to the 44 PSTN. This document aims to become an Appendix to IUA and to be 45 the base for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation. 47 Table of Contents 49 1.0 Introduction ......................................... 2 50 1.1 Scope ............................................. 2 51 1.2 Terminology ....................................... 3 52 1.3 DPNSS Overview .................................... 3 53 1.4 Proposed DPNSS Backhaul Architecture .............. 4 54 2.0 Changes from IUA...................................... 4 55 2.1 New Message Class for DUA.......................... 4 56 2.2 Message Header..................................... 5 57 2.3 Unit Data Message.................................. 6 58 2.4 DLS Status Message................................. 6 59 2.5 Management (MGMT) Messages......................... 7 60 3.0 IANA Considerations................................... 8 61 4.0 Use of SCTP Payload Protocol ID........................9 62 5.0 Message Sequence in DUA............................... 9 63 5.1 Resetting of single DLC............................ 9 64 5.2 Resetting all DLCs in a link....................... 10 65 5.3 Information Transfer on a DLC...................... 10 66 5.4 Link Takedown(Single DLC).......................... 10 67 5.5 Link Takedown(All DLCs)............................ 10 68 5.6 Getting link Status................................ 11 69 5.7 Error conditions................................... 11 70 6.0 Security Considerations............................... 11 71 7.0 References............................................ 11 72 8.0 Acknowledgements...................................... 11 73 9.0 Author's Addresses.................................... 12 74 10.0 Full Copyright Statement.............................. 12 76 1.0 Introduction 78 This document describes a method of implementing Digital Private 79 Network Signaling System 1 (DPNSS 1) [2] - henceforth just referred 80 to as just DPNSS, and Digital Access Signaling System 2 (DASS 2)[3], 81 backhaul messaging over IP using a modified version of the ISDN User 82 Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation 83 (DUA) builds on top of IUA by defining the necessary extensions to 84 IUA for a DPNSS/DASS2 implementation. 86 1.1 Scope 88 There is a need for Switched Circuit Network (SCN) signaling 89 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 90 Gateway Controller (MGC). The delivery mechanism should support the 91 following protocols: 93 - DPNSS (Digital Private Network Signaling System) [2] 94 - DASS 2 (Digital Access Signaling System Number 2) [3] 96 Unless specifically mentioned, the details in this document are 97 applicable to both DPNSS and DASS 2. 99 1.2 Terminology 101 Data channel (D-channel) - A 64 kbit/s time slot which functions 102 as a common signaling channel on a 2048 kbits/s interface or a 103 1544 kbits/s interface which is provisioned to carry DPNSS 104 signaling. 106 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 107 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 108 interface are termed as DPNSS channels. These are the 109 traffic channels which carry voice or data traffic. 110 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 111 - DASS2 supports 30 Channels (All Real) 113 Data Link Connection(DLC) - A DLC is the level 2 process that 114 controls the transfer of level 3 messages on behalf of one 115 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 116 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 117 - DASSII supports 30 DLCs (All Real) 119 DPNSS Link - A logical collection of the D-channel and the 120 associated DPNSS channels in a 2048 kbits/s interface or a 121 1544 kbits/s interface is called a "DPNSS Link". 123 Real channel - A signalling channel with associated traffic 124 channel (TS). 126 Virtual channel - A signalling channel with no associated traffic 127 channel. 129 NT1 - The DPNSS minimum retransmission period. 131 NT2 - The DPNSS minimum post retransmission acknowledgement delay. 133 1.3 DPNSS Overview 135 DPNSS is an industry standard interface (ref. ND1301:2001/03) [2] 136 defined between a PBX and an Access Network (AN). DPNSS extends 137 facilities normally only available between extensions on a single 138 PBX to all extensions on PBXs that are connected together in a 139 private network. DPNSS was originally derived from BT's Digital 140 Access Signaling System I (DASS I) enhanced where necessary to 141 meet the private network requirements. Some of these enhancements 142 were incorporated in DASS 2 [3]. DPNSS uses a 2048 kbits/s or 143 1544 kbits/s Digital Transmission System Interface as shown in 144 Figure 1 below. 146 ---------- ---------- o--o 147 | | 2048 kbits/s | |------- /\ 148 | |--------------| | -- 149 | PBX | 1544 kbits/s | AN | 150 | |--------------| | o--o 151 | | | |------- /\ 152 ---------- ---------- -- 154 Figure 1 156 Channel 16 on a 2048 kbits/s (E1) interface and channel 24 on a 157 1544 kbits/s (T1) interface is reserved for data communication 158 between LE and AN. The channels reserved for data are called 159 "Data Channels" or "D-Channels." 161 The D-Channels are the physical media to exchange data between the 162 DPNSS protocol peer entities. A logical collection of the D-channel 163 and the associated DPNSS channels is called a "DPNSS Link". 165 1.4 Proposed DPNSS Backhaul Architecture 167 ****** DPNSS ****** IP ******* 168 *PBX *---------------* SG *--------------* MGC * 169 ****** ****** ******* 171 +-----+ +-----+ 172 |DPNSS| (NIF) |DPNSS| 173 | L3 | | L3 | 174 +-----+ +----------+ +-----+ 175 | | | | DUA| | DUA | 176 |DPNSS| |DPNSS+----+ +-----+ 177 | L2 | | L2 |SCTP| |SCTP | 178 | | | +----+ +-----+ 179 | | | | IP + | IP | 180 +-----+ +-----+----+ +-----+ 182 NIF - Nodal Interworking function 183 SCTP - Stream Control Transmission Protocol 184 DUA - DPNSS User Adaptation Layer Protocol 186 2.0 Changes from IUA 188 This section outlines the differences between DUA and IUA. 190 2.1 New Message Class for DUA 192 The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be 193 identifiable from IUA boundary primitive transport messages and the 194 boundary primitive transport messages of other IUA extensions 195 (i.e. V5 or GR-303). Therefore, it is neccessary to use a different 196 message class parameter for DUA messages. 198 For all DPNSS/DASS2 interface boundary primitives, a new Message 199 Class is introduced: 201 13 DPNSS/DASS2 Boundary Primitives Transport Messages 202 (DPTM) 204 Similar to IUA, other valid message classes for DUA are: 206 0 Management (MGMT) Message 207 3 ASP State Maintenance (ASPSM) Messages 208 4 ASP Traffic Maintenance (ASPTM) Messages 210 2.2 Message Header 212 The IUA Message Header [1] MUST be used with the DPTM messages, 213 but the DLCI field in the DLCI parameter is formatted differently. 214 Figure 2 below shows the IUA Message Header with integer-based 215 Interface Identifier. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Tag (0x1) | Length | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Interface Identifier (integer) | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Tag (0x5) | Length=8 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | DLCI | Spare | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 Figure 2 IUA Message Header (integer-based Interface Identifier) 231 In DUA, the DLCI field has a different format in accordance with 232 the ND1301:2001/03 (formerly BTNR 188) [2]. 234 0 1 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Reserved |V|0|Channel No.|1| 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Reserved: 7 bits 242 Should be set to all '0's and ignored by the receiver. 244 V-bit: 1 bit 245 The V-bit is used to determine whether the message is for 246 a particular DLC or it is applicable for all the DLCs in the 247 carrier. The possible values of the V-bit are listed below: 249 Value Description 250 0 Action is to be performed on all DLCs 251 Channel number parameter is ignored. 252 1 Action is to be performed on a single 253 DLC specified by channel number. 255 This V-bit value is used only by the Establish and Release 256 messages. Data messages should ignore this value. This indicator 257 is provided so that a single command can be issued to establish or 258 release all the DLCs in one DPNSS Link. 260 For Channel Number (Channel No.), the valid values are 0 to 63 for 261 DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not 262 support virtual DLCs and hence has only 32 DLCs. 264 2.3 Unit Data Message 266 DPNSS layer 2 does not have a unit data primitive and hence the 267 Unit Data Messages (Request, Indication) are invalid for a DUA 268 application. The Data Request and Indication messages (message 269 types 1 and 2 respectively) will be used with DUA. 271 2.4 DLC Status Message 273 For DUA, a new message is necessary to carry the status of the DLCs. 274 This message will be a Management message (i.e. its message class 275 will be a value of 0 for Management). The following message types 276 will be used for these messages: 278 5 DLC Status Request 279 6 DLC Status Confirm 280 7 DLC Status Indication 282 The DLC Status messages are exchanged between IUA layer peers to 283 request, confirm and indicate the status of the DLCs. The DLC 284 Status messages contain the common message header followed by IUA 285 message header as described in section 2.1. 287 In addition, the DLC Status Confirm and Indication messages will 288 contain the new parameter called the DLC Status parameter. This 289 parameter will have the following format for an E1 interface: 291 0 1 2 3 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Tag (0x12) | Length | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15| 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31| 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47| 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63| 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 NA stands for Not Applicable. D0 and D16 are not applicable for 306 an E1 interface because timeslot 0 is used for E1 framing and 307 synchronization bits and timeslot 16 is used for signaling. For 308 DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual) 309 and in case of DASS2 there would be a total of 30 DLCs (no virtuals). 311 This parameter will have the following format for a T1 interface: 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Tag (0x12) | Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15| 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31| 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 D23 is not applicable for a T1 interface because timeslot 23 is used 326 for signaling. For DPNSS, there would be a total of max 46 DLCs 327 (23 real + 23 virtual) and in case of DASS2 there would be a total 328 of 23 DLCs (no virtuals). 330 The parameter carries the status of DLCs using two bits for each 331 DLC. The possible values for the two bits are shown below: 333 Value Description 334 00 Out Of Service 335 01 Reset Attempted 336 10 Reset Completed 337 11 Information Transfer 339 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 340 DLC does not have this state. In addition, the Idle state is a 341 transient state local to the DLC so a value is not allocated for it. 343 For DASS 2 there are no virtual DLCs and hence information about 344 only 32 DLCs need to be carried. Therefore the status message will 345 have a length of 12 for a DASS 2 DLC Status message. 347 2.5 Management (MGMT) Messages 349 Only the Notify and Error messages are valid for DUA. The TEI Status 350 messages are not used. 352 2.5.1 Error Message 354 The ERR message is sent when an invalid value or unrecognized 355 message is found in an incoming message. 357 The Error Code parameter indicates the reason for the Error Message. 358 These are the supported values in IUA. 360 Invalid Version 0x01 361 Invalid Interface Identifier 0x02 362 Unsupported Message Class 0x03 363 Unsupported Message Type 0x04 364 Unsupported Traffic Handling Mode 0x05 365 Unexpected Message 0x06 366 Protocol Error 0x07 367 Unsupported Interface Identifier Type 0x08 368 Invalid Stream Identifier 0x09 369 Unassigned TEI 0x0a 370 Unrecognized SAPI 0x0b 371 Invalid TEI, SAPI combination 0x0c 372 Refused - Management Blocking 0x0d 373 ASP Identifier Required 0x0e 374 Invalid ASP Identifier 0x0f 376 In DUA, the error codes 0x0a, 0x0b and 0x0c are invalid as they are 377 specific to ISDN. 379 The following additional error codes are supported in DUA: 381 Channel Number out of range 0x1c 382 Channel Number not configured 0x1d 384 The "Channel Number out of range" error is sent if a message is 385 received with a channel number greater than 63 for DPNSS or 31 for 386 DASS 2. 388 The "Channel Number not configured" error is sent if a message is 389 received with a channel number that is not configured. 391 3.0 IANA Considerations 393 IANA has assigned a DUA value for the SCTP Payload Protocol 394 Identifier field used in SCTP Payload Data chunks. The following 395 value for the SCTP Payload Protocol Identifier field SHOULD be used 396 for DUA: 397 SCTP Payload Protocol ID = "10" 399 4.0 Use of SCTP Payload Protocol ID 401 As an option, IUA value for SCTP Payload Protocol ID MAY also be 402 used for DUA, for instance, if one wanted to backhaul ISDN and 403 DPNSS over the same SCTP association. However, use of separate SCTP 404 Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the 405 primary option even in scenarios where ISDN and DPNSS are backhauled 406 over the same SCTP association. 408 SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only 409 DPNSS is backhauled over a SCTP association - i.e., in scenarios 410 where simultaneous backhauling of ISDN and DPNSS over the same 411 association is NOT required 413 The SCTP Payload Protocol Identifier is included in each SCTP Data 414 chunk, to indicate which protocol the SCTP is carrying. This Payload 415 Protocol Identifier is not directly used by SCTP but MAY be used by 416 certain network entities to identify the type of information being 417 carried in a Data chunk. 419 The User Adaptation peer MAY use the Payload Protocol Identifier as 420 a way of determining whether the message is for IUA or DUA. 422 5.0 Message Sequence in DUA 424 An example of the message flows for establishing a data link on a 425 signaling channel, passing PDUs and releasing a data link on a 426 DPNSS channel is shown below. An active association between MGC 427 and SG is established prior to the following message flows. 429 5.1 Resetting of single DLC 431 i) Successful 432 PBX SG MGC 433 <----------- SABMR <----------- Est Req(Ind=1) 434 UA -----------> Est Cfm -----------> (DLC in RC State) 435 Ind=1) 437 ii) Unsuccessful(Link Failure) 438 PBX SG MGC 439 <----------- SABMR <----------- Est Req(Ind=1) 440 Retransmissions over 441 NT1 and NT2 expired 442 Rel Ind -----------> (DLC in RA state) 443 (RELEASE_OTHER,Ind=1) 445 5.2 Resetting all DLCs in a link 447 PBX SG MGC 448 <----------- SABMR(1) <----------- Est Req(Ind=0) 449 <----------- SABMR(2) 450 <----------- SABMR(3) 451 ............. 452 <----------- SABMR(N) 453 In each DLC either 454 UA is received or 455 NT1/NT2 is expired 457 Est Cfm -----------> (Status of DLCs 458 (Ind=0) are not updated) 459 <----------- Status Req 460 Status cfm ----------> (Mark DLC status 461 based on 462 status bits) 464 If one of more DLCs remains out-of-service after this procedure 465 (e.g. due to layer 2 management), the MGC can either retry this 466 DLC with an Est Req(Ind=1) indicating the specific DLC or with 467 a Est Req(Ind=0) and the SG will retry the appropriate DLC that 468 is out-of-service. 470 5.3 Information Transfer on a DLC 472 PBX SG MGC 473 <----------- UI(C) <----------- Data Req 474 UI(R)-----------> Data Ind -----------> 476 5.4 Link Takedown(Single DLC) 478 PBX SG MGC 479 (For DPNSS, mark DLC as OOS) <----------- Rel Req 480 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 481 Ind=1) 482 Rel Cfm ----------> 483 (Ind=1) 485 5.5 Link Takedown(All DLCs) 487 PBX SG MGC 488 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 489 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 490 Ind=0) 491 Rel Cfm ----------> 492 (Ind=0) 494 5.6 Getting link Status 496 PBX SG MGC 497 <----------- Stat Req 498 Stat Cfm -----------> (Mark DLC status 499 based on 500 status bits) 502 5.7 Error conditions 504 PBX SG MGC 505 Invalid Message <-----------Est/Rel/Data/- 506 Stat Req 507 Error Ind -----------> 508 (Error Code) 510 6.0 Security Considerations 512 The security considerations discussed for the ISDN User Adaptation 513 Protocol (IUAP) [1] Section 6.0 and the Security Considerations 514 for SIGTRAN Protocols document [4] apply to this document as well. 516 7.0 References 518 7.1 Normative References 520 [1] Morneault, et al., ISDN Q.921-User Adaptation Layer RFC3057) 521 February 2001 523 [2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private 524 Signalling System No 1 (DPNSS 1) (Formerly BTNR 188). 526 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 527 Digital Access Signaling System No 2 529 [4] Loughney, et al., Security Considerations for Signaling 530 Transport (SIGTRAN) Protocols, RFC 3788, June 2004 532 7.2 Informative References 534 [5] ETS 300 167 (08/1993) : Transmission and Multiplexing; 535 Functional characteristic of 2048 kbits/s interfaces 536 (Standard is based on G.704, G.706). 538 8.0 Acknowledgments 540 The authors would like to thank Shashi Kumar and Venkatesh 541 Seshasayee of Wipro Technologies for their useful suggestions and 542 comments. 544 9.0 Author's Addresses 546 All correspondence regarding this draft should be sent to 547 the following addresses: 549 Ranjith Mukundan Phone: +91-80-51195893 550 Wipro Technologies Email: ranjith.mukundan@wipro.com 551 72, Electronics City 552 Hosur Main Road 553 Bangalore 560100 554 India 556 Ken Morneault Phone: +1-703-484-3323 557 Cisco Systems Inc. EMail: kmorneau@cisco.com 558 13615 Dulles Technology Drive 559 Herndon, VA. 20171 560 USA 562 Narsimuloo Mangalpally Phone: +1-613-967-5034 563 Nortel Networks EMail: narsim@nortelnetworks.com 564 250 Sidney Street 565 Belleville, Ontario K8P 3Z3 566 Canada 568 10.0 Full Copyright Statement 570 "Copyright (C) The Internet Society (2004). This document is subject 571 to the rights, licenses and restrictions contained in BCP 78, and 572 except as set forth therein, the authors retain all their rights." 574 "This document and the information contained herein are provided on 575 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 576 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 577 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 578 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."