idnits 2.17.1 draft-ietf-sigtran-dua-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: ---------------------------------------------------------------------------- ** 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 67 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 (November 2001) is 8170 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 452, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 5 errors (**), 0 flaws (~~), 4 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 November 2001 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 SCTP Payload Protocol Identifier will be registered: 335 DUA "??" 337 The SCTP Payload Protocol Identifier is included in each SCTP Data 338 chunk, to indicate which protocol the SCTP is carrying. This Payload 339 Protocol Identifier is not directly used by SCTP but may be used by 340 certain network entities to identify the type of information being 341 carried in a Data chunk. 343 The User Adaptation peer may use the Payload Protocol Identifier as 344 a way of determining whether the message is for IUA or DUA. 346 4.0 Message Sequence in DUA 348 An example of the message flows for establishing a data link on a 349 signaling channel, passing PDUs and releasing a data link on a 350 DPNSS channel is shown below. An active association between MGC 351 and SG is established prior to the following message flows. 353 4.1 Resetting of single DLC 355 i) Successful 356 PBX SG MGC 357 <----------- SABMR <----------- Est Req(Ind=1) 358 UA -----------> Est Cfm -----------> (DLC in RC State) 359 Ind=1) 361 ii) Unsuccessful(Link Failure) 362 PBX SG MGC 363 <----------- SABMR <----------- Est Req(Ind=1) 364 Retransmissions over 365 NT1 and NT2 expired 366 Rel Ind -----------> (DLC in RA state) 367 (RELEASE_PHYS,Ind=1) 369 4.2 Resetting all DLCs in a link 371 PBX SG MGC 372 <----------- SABMR(1) <----------- Est Req(Ind=0) 373 <----------- SABMR(2) 374 <----------- SABMR(3) 375 ............. 376 <----------- SABMR(N) 377 In each DLC either 378 UA is received or 379 NT1/NT2 is expired 380 Est Cfm -----------> (Status of DLCs 381 (Ind=0) are not updated ) 382 <----------- Status Req 383 Status cfm ---------> (Mark DLC status 384 based on 385 status bits) 387 4.3 Information Transfer on a DLC 389 PBX SG MGC 390 <----------- UI(C) <----------- Data Req 391 UI(C)-----------> Data Ind -----------> 393 4.4 Link Takedown(Single DLC) 395 PBX SG MGC 396 (For DPNSS, mark DLC as OOS) <----------- Rel Req 397 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 398 Ind=1) 399 Rel Cfm ----------> 400 (Ind=1) 402 4.5 Link Takedown(All DLCs) 404 PBX SG MGC 405 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 406 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 407 Ind=0) 408 Rel Cfm ----------> 409 (Ind=0) 411 4.6 Getting link Status 413 PBX SG MGC 414 <----------- Stat Req 415 Stat Res -----------> (Mark DLC status 416 based on 417 status bits) 419 4.7 Error conditions 421 PBX SG MGC 422 Invalid Message <-----------Est/Rel/Data/- 423 Stat Req 424 Error Ind -----------> 425 (Error Code) 427 5.0 Glossary of terms 429 Real channel : The signalling channel with associated 430 traffic channel (TS). 431 Virtual channel: The signalling channel with no 432 associated traffic channel. 433 NT1 : Retransmission period of 500msec. 434 NT2 : Recommended value is 64. 436 6.0 Security Considerations 438 The security considerations discussed for the ISDN User Adaptation 439 Protocol (IUAP) [1] Section 6.0 apply to this document as well. 441 7.0 References 443 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 444 February 2001. 446 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 447 Private Network Signaling System 1. 449 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 450 Digital Access Signaling System No 2 452 [4] ETS 300 167 (08/1993) : Transmission and Multiplexing; 453 Functional characteristic of 2048 kbits/s interfaces 454 (Standard is based on G.704, G.706). 456 8.0 Acknowledgments 458 The authors would like to thank Sudarsan Naganathan, Subhas 459 Mondal and Sivaram Subramanian of Nortel Networks for their useful 460 suggestions/comments. 462 9.0 Author's Addresses 464 Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and 465 Ken Morneault 467 All correspondence regarding this draft should be sent to 468 the following addresses : 470 Mick Dragon Phone: +44 (0)1628434388 471 Nortel Networks plc EMail: mdragon@nortelnetworks.com 472 Concorde Road 473 Maidenhead 474 Berkshire SL6 4AG 475 United Kingdom 477 Ken Morneault Phone: +1-703-484-3323 478 Cisco Systems Inc. EMail: kmorneau@cisco.com 479 13615 Dulles Technology Drive 480 Herndon, VA. 20171 481 USA