idnits 2.17.1 draft-ietf-sigtran-dua-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 7) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 179 has weird spacing: '...inguish betwe...' -- 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 (May 2002) is 8016 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: '4' is defined on line 455, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 460, 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' == Outdated reference: A later version (-02) exists of draft-ietf-sigtran-iua-imp-guide-01 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force A. Vydyam 2 R. Mukundan 3 N. Mangalpally 4 Nortel Networks 5 Ken Morneault 6 Cisco Systems 7 Expires in 6 months May 2002 9 DPNSS/DASS 2 extensions to the IUA protocol 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance 15 with all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Abstract 35 This document defines a mechanism for backhauling of DPNSS [2] and 36 DASS2 [3] messages over IP by extending the ISDN User Adaptation 37 Layer Protocol [1]. This document aims to become an Appendix to 38 IUA [1] and to be the base for a DPNSS/DASS User Adaptation (DUA) 39 implementation. 41 Table of Contents 43 1.0 Introduction ......................................... 2 44 1.1 Scope ............................................. 2 45 1.2 Terminology ....................................... 2 46 1.3 DPNSS Overview .................................... 3 47 1.4 Proposed DPNSS Backhaul Architecture .............. 3 49 2.0 Changes from IUA...................................... 4 50 2.1 New Message Class for DUA.......................... 4 51 2.2 Message Header..................................... 4 52 2.3 Unit Data Message.................................. 5 53 2.4 Status Message..................................... 5 54 2.5 Error Message...................................... 6 55 3.0 IANA Considerations................................... 7 56 4.0 Message Sequence in DUA............................... 7 57 4.1 Resetting of single DLC............................ 7 58 4.2 Resetting all DLCs in a link....................... 8 59 4.3 Information Transfer on a DLC...................... 8 60 4.4 Link Takedown(Single DLC).......................... 8 61 4.5 Link Takedown(All DLCs)............................ 8 62 4.6 Getting link Status................................ 9 63 4.7 Error conditions................................... 9 64 5.0 Glossary of Terms .................................... 9 65 6.0 Security Considerations............................... 9 66 7.0 References............................................ 9 67 8.0 Acknowledgements...................................... 10 68 9.0 Author's Addresses.................................... 10 70 1.0 Introduction 72 This document describes a method of implementing DPNSS [2] and 73 DASS 2 [3] backhaul messaging over IP using a modified version 74 of the ISDN User Adaptation Protocol (IUAP) [1]. The DUA builds 75 on top of IUA defining the necessary extensions to IUA for a 76 DPNSS/DASS2 implementation. 78 1.1 Scope 80 There is a need for Switched Circuit Network (SCN) signaling 81 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 82 Gateway Controller (MGC). The delivery mechanism should support the 83 following protocols: 85 - DPNSS (Digital Private Network Signaling System) [2] 86 - DASS 2 (Digital Access Signaling System No 2) [3] 88 Unless specifically mentioned, the details in this document are 89 applicable to both DPNSS and DASS2. 91 1.2 Terminology 93 Data channel (D-channel) - A 64 kbit/s time slot which functions 94 as a common signaling channel on a 2048 kbits/s interface or a 95 1544 kbits/s interface which is provisioned to carry DPNSS 96 signaling. 98 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 99 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 100 interface are termed as DPNSS channels. These are the 101 traffic channels which carry voice or data traffic. 103 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 104 - DASS2 supports 30 Channels (All Real) 106 Data Link Connection(DLC) - A DLC is the level 2 process that 107 controls the transfer of level 3 messages on behalf of one 108 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 109 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 110 - DASSII supports 30 DLCs (All Real) 112 DPNSS Link - A logical collection of the D-channel and the 113 associated DPNSS channels in a 2048 kbits/s interface or a 114 1544 kbits/s interface is called a "DPNSS Link". 116 1.3 DPNSS Overview 118 DPNSS is an industry standard interface (reference BTNR 188) [2] 119 defined between a PBX and an Access Network (AN). DPNSS extends 120 facilities normally only available between extensions on a single 121 PBX to all extensions on PBXs that are connected together in a 122 private network. DPNSS was originally derived from BT's Digital 123 Access Signaling System I (DASS I) enhanced where necessary to 124 meet the private network requirements. Some of these enhancements 125 were incorporated in DASS 2 [3]. DPNSS uses a 2048 kbits/s or 126 1544 kbits/s Digital Transmission System Interface as shown in 127 Figure 1 below. 129 ---------- ---------- o--o 130 | | 2048 kbits/s | |------- /\ 131 | |--------------| | -- 132 | PBX | 1544 kbits/s | AN | 133 | |--------------| | o--o 134 | | | |------- /\ 135 ---------- ---------- -- 137 Figure 1 139 Channel 16 on a 2048 kbits/s interface and channel 24 on a 140 1544 kbits/s interface is reserved for data communication 141 between LE and AN. The channels reserved for data are called 142 "Data Channels" or "D-Channels." 144 The D-Channels are the physical media to exchange data between the 145 DPNSS protocol peer entities. A logical collection of the D-channel 146 and the associated DPNSS channels is called a "DPNSS Link". 148 1.4 Proposed DPNSS Backhaul Architecture 150 ****** DPNSS ****** IP ******* 151 *PBX *---------------* SG *--------------* MGC * 152 ****** ****** ******* 154 +-----+ +-----+ 155 |DPNSS| (NIF) |DPNSS| 156 | L3 | | L3 | 157 +-----+ +----------+ +-----+ 158 | | | | DUA| | DUA | 159 |DPNSS| |DPNSS+----+ +-----+ 160 | L2 | | L2 |SCTP| |SCTP | 161 | | | +----+ +-----+ 162 | | | | IP + | IP | 163 +-----+ +-----+----+ +-----+ 165 NIF - Nodal Interworking function 166 SCTP - Stream Control Transmission Protocol 167 DUA - DPNSS User Adaptation Layer Protocol 169 2.0 Changes from IUA 171 This section outlines the differences between DUA and IUA. 173 2.1 New Message Class for DUA 175 The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be 176 handled in a different way from the IUA boundary primitive transport 177 messages and the boundary primitive transport messages of other 178 IUA extensions (i.e. V5 or GR-303). Therefore, it is neccessary to 179 distinguish between these from other IUA-based boundary primitive 180 transport message types [1] by means of the Message Class parameter. 182 For all DPNSS/DASS2 interface boundary primitives, a new Message 183 Class is introduced: 185 10 DPNSS/DASS2 Boundary Primitives Transport Messages 186 (DPTM) 188 Similar to IUA, other valid message classes for DUA are: 190 0 Management (MGMT) Message 191 3 ASP State Maintenance (ASPSM) Messages 192 4 ASP Traffic Maintenance (ASPTM) Messages 194 2.2 Message Header 196 IUA Message header [1] has the format as shown in Figure 2 below. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Tag (0x1) | Length | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Interface Identifier | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | DLCI | Spare | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 2 IUA Message Header 210 In DUA header DLCI field has a different format in accordance with 211 the BTNR 188 [2]. 213 0 1 214 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Reserved |V|0|Channel No.|1| 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Reserved: 7 bits 221 Should be set to all '0's and ignored by the receiver. 223 V-bit: 1 bit 225 The V-bit is used to determine whether the message is for 226 a particular DLC or it is applicable for all the DLCs in the 227 carrier. The possible values of the V-bit are listed below: 229 Value Description 230 0 Action is to be performed on all DLCs 231 Channel number parameter is ignored. 232 1 Action is to be performed on a single 233 DLC specified by channel number. 235 This V-bit value is used only by the Establish and Release 236 messages. Data messages should ignore this value. This indicator 237 is provided so that a single command can be issued to establish or 238 release all the DLCs in one DPNSS Link. 240 For Channel Number (Channel No.), the valid values are 0 to 63 for 241 DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not 242 support virtual DLCs and hence has only 32 DLCs. 244 2.3 Unit Data Message 246 DPNSS layer 2 does not have a unit data primitive and hence the 247 Unit Data Messages (Request, Indication) are invalid for a DUA 248 application. 250 2.4 DLC Status Message 252 For DUA, a new message is necessary to carry the status of the DLCs. 253 This message will be a Management message (i.e. its message class 254 will be a value of 0 for Management). A message type of 0x5 will be 255 used for this message. 257 The DLC Status messages are exchanged between IUA layer peers to 258 request, confirm and indicate the status of the DLCs. The DLC 259 Status messages contain the common message header followed by IUA 260 message header as described in section 2.1. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Tag (0x11) | Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|D16| 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 \ / 270 / \ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | .................... |Dxx| 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 The parameter carries the status of DLCs using two bits for each 276 DLC. 278 The possible values for the two bits are shown below: 280 Value Description 281 00 Out Of Service 282 01 Reset Attempted 283 10 Reset Completed 284 11 Information Transfer 286 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 287 DLC does not have this state. 289 For DASS 2 there are no virtual DLCs and hence information about 290 only 32 DLCs need to be carried. Therefore the status message will 291 have a length of 12 for a DASS 2 DLC Status message. 293 2.5 Error Message 295 The ERR message is sent when an invalid value or unrecognized 296 message is found in an incoming message. 298 The Error Code parameter indicates the reason for the Error Message. 299 These are the supported values in IUA. 301 Invalid Version 0x01 302 Invalid Interface Identifier 0x02 303 Unsupported Message Class 0x03 304 Unsupported Message Type 0x04 305 Unsupported Traffic Handling Mode 0x05 306 Unexpected Message 0x06 307 Protocol Error 0x07 308 Unsupported Interface Identifier Type 0x08 309 Invalid Stream Identifier 0x09 310 Unassigned TEI 0x0a 311 Unrecognized SAPI 0x0b 312 Invalid TEI, SAPI combination 0x0c 314 In DUA the error codes 0x0a to 0x0c are invalid as they are specific 315 to ISDN. 317 The following additional error codes are supported in DUA: 319 Channel Number out of range 0x16 320 Channel Number not configured 0x17 322 The "Channel Number out of range" error is sent if a message is 323 received with a channel number greater than 63 for DPNSS or 31 for 324 DASS 2. 326 The "Channel Number not configured" error is sent if a message is 327 received with a channel number that is not configured. 329 3.0 IANA Considerations 331 A request will be made to IANA to assign a DUA value for the SCTP 332 Payload Protocol Identifier field used in SCTP Payload Data chunks. 333 The following value for the SCTP Payload Protocol Identifier field 334 should be used for DUA 336 SCTP Payload Protocol ID xxx - tba by IANA 338 The SCTP Payload Protocol Identifier is included in each SCTP Data 339 chunk, to indicate which protocol the SCTP is carrying. This Payload 340 Protocol Identifier is not directly used by SCTP but may be used by 341 certain network entities to identify the type of information being 342 carried in a Data chunk. 344 The User Adaptation peer may use the Payload Protocol Identifier as 345 a way of determining whether the message is for IUA or DUA. 347 4.0 Message Sequence in DUA 349 An example of the message flows for establishing a data link on a 350 signaling channel, passing PDUs and releasing a data link on a 351 DPNSS channel is shown below. An active association between MGC 352 and SG is established prior to the following message flows. 354 4.1 Resetting of single DLC 356 i) Successful 357 PBX SG MGC 358 <----------- SABMR <----------- Est Req(Ind=1) 359 UA -----------> Est Cfm -----------> (DLC in RC State) 360 Ind=1) 362 ii) Unsuccessful(Link Failure) 363 PBX SG MGC 364 <----------- SABMR <----------- Est Req(Ind=1) 365 Retransmissions over 366 NT1 and NT2 expired 367 Rel Ind -----------> (DLC in RA state) 368 (RELEASE_PHYS,Ind=1) 370 4.2 Resetting all DLCs in a link 372 PBX SG MGC 373 <----------- SABMR(1) <----------- Est Req(Ind=0) 374 <----------- SABMR(2) 375 <----------- SABMR(3) 376 ............. 377 <----------- SABMR(N) 378 In each DLC either 379 UA is received or 380 NT1/NT2 is expired 381 Est Cfm -----------> (Status of DLCs 382 (Ind=0) are not updated ) 383 <----------- Status Req 384 Status cfm ---------> (Mark DLC status 385 based on 386 status bits) 388 4.3 Information Transfer on a DLC 390 PBX SG MGC 391 <----------- UI(C) <----------- Data Req 392 UI(C)-----------> Data Ind -----------> 394 4.4 Link Takedown(Single DLC) 396 PBX SG MGC 397 (For DPNSS, mark DLC as OOS) <----------- Rel Req 398 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 399 Ind=1) 400 Rel Cfm ----------> 401 (Ind=1) 403 4.5 Link Takedown(All DLCs) 405 PBX SG MGC 406 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 407 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 408 Ind=0) 409 Rel Cfm ----------> 410 (Ind=0) 412 4.6 Getting link Status 414 PBX SG MGC 415 <----------- Stat Req 416 Stat Res -----------> (Mark DLC status 417 based on 418 status bits) 420 4.7 Error conditions 422 PBX SG MGC 423 Invalid Message <-----------Est/Rel/Data/- 424 Stat Req 425 Error Ind -----------> 426 (Error Code) 428 5.0 Glossary of terms 430 Real channel : The signalling channel with associated 431 traffic channel (TS). 432 Virtual channel: The signalling channel with no 433 associated traffic channel. 434 NT1 : Retransmission period of 500msec. 435 NT2 : Recommended value is 64. 437 6.0 Security Considerations 439 The security considerations discussed for the ISDN User Adaptation 440 Protocol (IUAP) [1] Section 6.0 apply to this document as well. 442 7.0 References 444 7.1 Normative References 446 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 447 February 2001. 449 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 450 Private Network Signaling System 1. 452 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 453 Digital Access Signaling System No 2 455 [4] IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp- 456 guide-01.txt, May 2002 458 7.2 Informative References 460 [5] ETS 300 167 (08/1993) : Transmission and Multiplexing; 461 Functional characteristic of 2048 kbits/s interfaces 462 (Standard is based on G.704, G.706). 464 8.0 Acknowledgments 466 The authors would like to thank Sudarsan Naganathan, Subhas 467 Mondal and Sivaram Subramanian of Nortel Networks for their useful 468 suggestions/comments. 470 9.0 Author's Addresses 472 Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and 473 Ken Morneault 475 All correspondence regarding this draft should be sent to 476 the following addresses : 478 Mick Dragon Phone: +44 (0)1628434388 479 Nortel Networks plc EMail: mdragon@nortelnetworks.com 480 Concorde Road 481 Maidenhead 482 Berkshire SL6 4AG 483 United Kingdom 485 Ken Morneault Phone: +1-703-484-3323 486 Cisco Systems Inc. EMail: kmorneau@cisco.com 487 13615 Dulles Technology Drive 488 Herndon, VA. 20171 489 USA