idnits 2.17.1 draft-ietf-sigtran-dua-01.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 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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. 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 (October 2001) is 8229 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 424, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 427, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 430, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 433, 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: 6 errors (**), 0 flaws (~~), 5 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 October 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/DASS2 36 messages over IP by extending the ISDN User Adaptation Layer 37 Protocol reference RFC3057. This document aims to become an Appendix 38 to IUA and to be the base for a DUA implementation. 40 Table of Contents 42 1.0 Introduction ......................................... 2 43 1.1 Scope ............................................. 2 44 1.2 Terminology ....................................... 2 45 1.3 DPNSS Overview .................................... 3 46 1.4 Proposed DPNSS Backhaul Architecture .............. 3 48 Vydyam/Mukundan/Mangalpally/Morneault 1 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 References ........................................... 9 65 6.0 Author's Addresses.................................... 9 66 7.0 Author's Addresses.................................... 9 67 8.0 Author's Addresses.................................... 9 69 1.0 Introduction 71 This document describes a method of implementing DPNSS/DASS 2 back- 72 haul messaging over IP using a modified version of the ISDN 73 User Adaptation Protocol (IUAP). The DUA builds on top of IUA 74 defining the necessary extensions to IUA for a DPNSS/DASS2 75 implementation. 77 1.1 Scope 79 There is a need for Switched Circuit Network (SCN) signaling 80 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 81 Gateway Controller (MGC). The delivery mechanism should support the 82 following protocols: 84 - DPNSS(Digital Private Network Signaling System) 85 - DASS 2 (Digital Access Signaling System No 2) 87 Unless specifically mentioned the details in this document are 88 applicable to both DPNSS and DASS2. 90 1.2 Terminology 92 Data channel (D-channel) - A 64 kbit/s time slot which functions 93 as a common signaling channel on a 2048 kbits/s interface or a 94 1544 kbits/s interface which is provisioned to carry DPNSS 95 signaling. 97 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 98 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 99 interface are termed as DPNSS channels. These are the 100 traffic channels which carry voice or data traffic. 102 Vydyam/Mukundan/Mangalpally/Morneault 2 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) 119 defined between a PBX and an Access Network (AN). 120 DPNSS extends facilities normally only available between 121 extensions on a single PBX to all extensions on PBXs that are 122 connected together in a private network. DPNSS was originally 123 derived from BT's Digital Access Signaling System I (DASS I) 124 enhanced where necessary to meet the private network 125 requirements. Some of these enhancements were incorporated in 126 DASS 2. DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital 127 Transmission System Interface as shown in figure 1 below. 129 ---------- ---------- o--o 130 | | 2048 kbits/s | |------- /\ 131 | |--------------| | -- 132 | PBX | 1544 kbits/s | AN | 133 | |--------------| | o--o 134 | | | |------- /\ 135 ---------- ---------- -- 136 Figure 1 138 Channel 16 on a 2048 kbits/s interface and channel 24 on a 139 1544 kbits/s interface is reserved for data communication 140 between LE and AN. The channels reserved for data are called 141 "Data Channels" or "D-Channels." 143 The D-Channels are the physical media to exchange data 144 between the DPNSS protocol peer entities. A logical collection of 145 the D-channel and the associated DPNSS channels is called a "DPNSS 146 Link". 148 1.4 Proposed DPNSS Backhaul Architecture 150 Vydyam/Mukundan/Mangalpally/Morneault 3 151 ****** DPNSS ****** IP ******* 152 *PBX *---------------* SG *--------------* MGC * 153 ****** ****** ******* 155 +-----+ +-----+ 156 |DPNSS| (NIF) |DPNSS| 157 | L3 | | L3 | 158 +-----+ +----------+ +-----+ 159 | | | | DUA| | DUA | 160 |DPNSS| |DPNSS+----+ +-----+ 161 | L2 | | L2 |SCTP| |SCTP | 162 | | | +----+ +-----+ 163 | | | | IP + | IP | 164 +-----+ +-----+----+ +-----+ 166 NIF - Nodal Interworking function 167 SCTP - Stream Control Transmission Protocol 168 DUA - DPNSS User Adaptation Layer Protocol 170 2.0 Changes from IUA 172 The following section outlines the differences between DUA and IUA 174 2.1 New Message Class for DUA 176 The DPNSS/DASS2 Layer 2 to Layer 3 primitives need to be handled 177 in a different way from the IUA boundary primitive transport 178 messages and the boundary primitive transport messages of other 179 IUA extensions V5UA. Therefore it is neccessary to distinguish 180 between these from other IUA-based boundary primitive transport 181 message types by means of the Message Class parameter. 183 For all DPNSS/DASS2 interface boundary primitives, a new Message 184 Class is introduced: 186 10 DPNSS/DASS2 Boundary Primitives Transport Messages 187 (DPTM) 189 Similar to IUA, other valid message classes for DUA are: 191 0 Management (MGMT) Message 192 3 ASP State Maintenance (ASPSM) Messages 193 4 ASP Traffic Maintenance (ASPTM) Messages 195 2.2 Message Header 197 IUA Message header has the format as shown in Figure 2 below. 199 Vydyam/Mukundan/Mangalpally/Morneault 4 200 0 1 2 3 201 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 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Tag (0x1) | Length | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Interface Identifier | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | DLCI | Spare | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2 IUA Message Header 212 In DUA header DLCI field has a different format in accordance with 213 the BTNR 188. 215 0 1 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Indicator |0|Channel No.|1| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 The indicator field is used to determine whether the message is for 222 a particular DLC or it is applicable for all the DLCs in the 223 carrier. The possible values of the indicator is mentioned below. 225 Value Description 226 0 Action is to be performed on all DLCs 227 Channel number parameter is ignored. 228 1 Action is to be performed on a single 229 DLC specified by channel number. 231 This indicator value is used only by the Establish and Release 232 messages. Data messages should ignore this value. This indicator is 233 provided so that a single command can be issued to establish or 234 release all the DLCs in one DPNSS Link. 236 For channel number the valid values are 0 to 63 for DPNSS and 0 to 237 31 for DASS 2. This is because DASS 2 does not support virtual DLCs 238 and hence has only 32 DLCs. 240 2.3 Unit Data Message 242 DPNSS layer 2 does not have a unit data primitive and hence the 244 Vydyam/Mukundan/Mangalpally/Morneault 5 245 Unit Data Messages (Request, Indication) are invalid for a DUA 246 application. 248 2.4 DLC Status Message 250 For DUA, a new message is necessary to carry the status of the DLCs. 251 This message will be a Management message (i.e. its message class 252 will be a value of 0 for Management). A message type of 0x5 will be 253 used for this message. 255 The DLC Status messages are exchanged between IUA layer peers to 256 request, confirm and indicate the status of the DLCs. The DLC 257 Status messages contain the common message header followed by IUA 258 message header as described in section 2.1. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Tag (0x11) | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|D16| 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 \ / 268 / \ 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | .................... |Dxx| 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 The parameter carries the status of DLCs using two bits for each 274 DLC. 276 The possible values for the two bits are shown below: 277 Value Description 278 00 Out Of Service 279 01 Reset Attempted 280 10 Reset Completed 281 11 Information Transfer 283 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 284 DLC does not have this state. 286 For DASS 2 there are no virtual DLCs and hence information about 287 only 32 DLCs need to be carried. Therefore the status message will 288 have a length of 12 for a DASS 2 DLC Status message. 290 2.5 Error Message 292 Vydyam/Mukundan/Mangalpally/Morneault 6 293 The ERR message is sent when an invalid value or unrecognized 294 message is found in an incoming message. 295 The Error Code parameter indicates the reason for the Error Message. 296 These are the supported values in IUA. 298 Invalid Version 0x01 299 Invalid Interface Identifier 0x02 300 Unsupported Message Class 0x03 301 Unsupported Message Type 0x04 302 Unsupported Traffic Handling Mode 0x05 303 Unexpected Message 0x06 304 Protocol Error 0x07 305 Unsupported Interface Identifier Type 0x08 306 Invalid Stream Identifier 0x09 307 Unassigned TEI 0x0a 308 Unrecognized SAPI 0x0b 309 Invalid TEI, SAPI combination 0x0c 311 In DUA the error codes 0x0a to 0x0c are invalid as they are specific 312 to ISDN. 314 The following additional error codes are supported in DUA. 315 Channel Number out of range 0x0d 316 Channel Not configured 0x0e 318 3.0 IANA Considerations 320 A request will be made to IANA to assign a DUA value for the Payload 321 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 322 Payload Protocol Identifier will be registered: 324 The SCTP Payload Protocol Identifier is included in each SCTP Data 325 chunk, to indicate which protocol the SCTP is carrying. This Payload 326 Protocol Identifier is not directly used by SCTP but may be used by 327 certain network entities to identify the type of information being 328 carried in a Data chunk. 330 The User Adaptation peer may use the Payload Protocol Identifier as 331 a way of determining whether the message is for IUA or DUA. 333 4.0 Message Sequence in DUA 335 An example of the message flows for establishing a data link on a 336 signaling channel, passing PDUs and releasing a data link on a 337 DPNSS channel is shown below. An active association between MGC 338 and SG is established prior to the following message flows. 340 4.1 Resetting of single DLC 342 Vydyam/Mukundan/Mangalpally/Morneault 7 343 i) Successful 344 PBX SG MGC 345 <----------- SABMR <----------- Est Req(Ind=1) 346 UA -----------> Est Cfm -----------> (DLC in RC State) 347 Ind=1) 349 ii) Unsuccessful(Link Failure) 350 PBX SG MGC 351 <----------- SABMR <----------- Est Req(Ind=1) 352 Retransmissions over 353 NT1 and NT2 expired 354 Rel Ind -----------> (DLC in RA state) 355 (RELEASE_PHYS,Ind=1) 357 4.2 Resetting all DLCs in a link 359 PBX SG MGC 360 <----------- SABMR(1) <----------- Est Req(Ind=0) 361 <----------- SABMR(2) 362 <----------- SABMR(3) 363 ............. 364 <----------- SABMR(N) 365 In each DLC either 366 UA is received or 367 NT1/NT2 is expired 368 Est Cfm -----------> (Status of DLCs 369 (Ind=0) are not updated ) 370 <----------- Status Req 371 Status cfm ---------> (Mark DLC status 372 based on 373 status bits) 375 4.3 Information Transfer on a DLC 377 PBX SG MGC 378 <----------- UI(C) <----------- Data Req 379 UI(C)-----------> Data Ind -----------> 381 4.4 Link Takedown(Single DLC) 383 PBX SG MGC 384 (For DPNSS, mark DLC as OOS) <----------- Rel Req 385 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 386 Ind=1) 387 Rel Cfm ----------> 388 (Ind=1) 390 4.5 Link Takedown(All DLCs) 392 Vydyam/Mukundan/Mangalpally/Morneault 8 393 PBX SG MGC 394 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 395 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 396 Ind=0) 397 Rel Cfm ----------> 398 (Ind=0) 399 4.6 Getting link Status 401 PBX SG MGC 402 <----------- Stat Req 403 Stat Res -----------> (Mark DLC status 404 based on 405 status bits) 406 4.7 Error conditions 408 PBX SG MGC 409 Invalid Message <----------- 410 Est/Rel/Data/Stat Req 411 Error Ind -----------> 412 (Error Code) 413 5.0 Glossary of terms 415 Real channel : The signalling channel with associated 416 traffic channel (TS). 417 Virtual channel: The signalling channel with no 418 associated traffic channel. 419 NT1 : Retransmission period of 500msec. 420 NT2 : Recommended value is 64. 422 6.0 References 424 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 425 February 2001. 427 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 428 Private Network Signaling System 1. 430 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 431 Digital Access Signaling System No 2 433 [4] ETS 300 167 (08/1993) : Transmission and Multiplexing; 434 Functional characteristic of 2048 kbits/s interfaces 435 (Standard is based on G.704, G.706). 437 Vydyam/Mukundan/Mangalpally/Morneault 9 438 7.0. Acknowledgments 440 The authors would like to thank Sudarsan Naganathan, Subhas 441 Mondal and Sivaram Subramanian of Nortel Networks for their useful 442 suggestions/comments. 444 8.0 Author's Addresses 446 Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and 447 Ken Morneault 449 All correspondence regarding this draft should be sent to 450 the following addresses : 452 Mick Dragon Phone: +44 (0)1628434388 453 Nortel Networks plc EMail: mdragon@nortelnetworks.com 454 Concorde Road 455 Maidenhead 456 Berkshire SL6 4AG 457 United Kingdom 459 Ken Morneault Phone: +1-703-484-3323 460 Cisco Systems Inc. EMail: kmorneau@cisco.com 461 13615 Dulles Technology Drive 462 Herndon, VA. 20171 463 USA 465 Vydyam/Mukundan/Mangalpally/Morneault 10