idnits 2.17.1 draft-ietf-sigtran-dua-00.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. 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 (July 2001) is 8320 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 400, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 403, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 409, 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 (~~), 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 July 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 ......................................... 3 43 1.1 Scope ............................................. 3 44 1.2 Terminology ....................................... 3 45 1.3 DPNSS Overview .................................... 3 46 1.4 Proposed DPNSS Backhaul Architecture .............. 4 48 Vydyam/Mukundan/Mangalpally/Morneault 1 49 2.0 Changes from IUA...................................... 4 50 2.1 Message Header..................................... 4 51 2.2 Adaptation Layer Identifier........................ 5 52 2.3 Unit Data Message.................................. 5 53 2.4 Status Message..................................... 5 54 2.5 Error Message...................................... 6 55 3.0 IANA Considerations................................... 6 56 4.0 Message Sequence in DUA............................... 6 57 4.1 Resetting of single DLC............................ 6 58 4.2 Resetting all DLCs in a link....................... 7 59 4.3 Information Transfer on a DLC...................... 7 60 4.4 Link Takedown(Single DLC).......................... 7 61 4.5 Link Takedown(All DLCs)............................ 7 62 4.6 Getting link Status................................ 7 63 4.7 Error conditions................................... 7 64 5.0 References ........................................... 8 65 6.0 Author's Addresses.................................... 8 67 1.0 Introduction 69 This document describes a method of implementing DPNSS/DASS 2 back- 70 haul messaging over IP using a modified version of the ISDN 71 User Adaptation Protocol (IUAP). The DUA builds on top of IUA 72 defining the necessary extensions to IUA for a DPNSS/DASS2 73 implementation. 75 1.1 Scope 77 There is a need for Switched Circuit Network (SCN) signaling 78 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 79 Gateway Controller (MGC). The delivery mechanism should support the 80 following protocols: 82 - DPNSS(Digital Private Network Signaling System) 83 - DASS 2 (Digital Access Signaling System No 2) 85 Unless specifically mentioned the details in this document are 86 applicable to both DPNSS and DASS2. 88 1.2 Terminology 90 Data channel (D-channel) - A 64 kbit/s time slot which functions 91 as a common signaling channel on a 2048 kbits/s interface or a 92 1544 kbits/s interface which is provisioned to carry DPNSS 93 signaling. 95 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 96 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 97 interface are termed as DPNSS channels. These are the 98 traffic channels which carry voice or data traffic. 100 Vydyam/Mukundan/Mangalpally/Morneault 1 101 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 102 - DASS2 supports 30 Channels (All Real) 104 Data Link Connection(DLC) - A DLC is the level 2 process that 105 controls the transfer of level 3 messages on behalf of one 106 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 107 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 108 - DASSII supports 30 DLCs (All Real) 110 DPNSS Link - A logical collection of the D-channel and the 111 associated DPNSS channels in a 2048 kbits/s interface or a 112 1544 kbits/s interface is called a "DPNSS Link". 114 1.3 DPNSS Overview 116 DPNSS is an industry standard interface (reference BTNR 188) 117 defined between a PBX and an Access Network (AN). 118 DPNSS extends facilities normally only available between 119 extensions on a single PBX to all extensions on PBXs that are 120 connected together in a private network. DPNSS was originally 121 derived from BT's Digital Access Signaling System I (DASS I) 122 enhanced where necessary to meet the private network 123 requirements. Some of these enhancements were incorporated in 124 DASS 2. DPNSS uses a 2048 kbits/s or 1544 kbits/s Digital 125 Transmission System Interface as shown in figure 1 below. 127 ---------- ---------- o--o 128 | | 2048 kbits/s | |------- /\ 129 | |--------------| | -- 130 | PBX | 1544 kbits/s | AN | 131 | |--------------| | o--o 132 | | | |------- /\ 133 ---------- ---------- -- 134 Figure 1 136 Channel 16 on a 2048 kbits/s interface and channel 24 on a 137 1544 kbits/s interface is reserved for data communication 138 between LE and AN. The channels reserved for data are called 139 "Data Channels" or "D-Channels." 141 The D-Channels are the physical media to exchange data 142 between the DPNSS protocol peer entities. A logical collection of 143 the D-channel and the associated DPNSS channels is called a "DPNSS 144 Link". 146 1.4 Proposed DPNSS Backhaul Architecture 148 Vydyam/Mukundan/Mangalpally/Morneault 1 149 ****** DPNSS ****** IP ******* 150 *PBX *---------------* SG *--------------* MGC * 151 ****** ****** ******* 153 +-----+ +-----+ 154 |DPNSS| (NIF) |DPNSS| 155 | L3 | | L3 | 156 +-----+ +----------+ +-----+ 157 | | | | DUA| | DUA | 158 |DPNSS| |DPNSS+----+ +-----+ 159 | L2 | | L2 |SCTP| |SCTP | 160 | | | +----+ +-----+ 161 | | | | IP + | IP | 162 +-----+ +-----+----+ +-----+ 164 NIF - Nodal Interworking function 165 SCTP - Stream Control Transmission Protocol 166 DUA - DPNSS User Adaptation Layer Protocol 168 2.0 Changes from IUA 170 The following section outlines the differences between DUA and IUA 172 2.1 Message Header 174 IUA Message header has the format as shown in Figure 2 below. 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Tag (0x1) | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Interface Identifier | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | DLCI | Spare | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 Figure 2 IUA Message Header 188 In DUA header DLCI field has a different format in accordance with 189 the BTNR 188. 191 0 1 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Indicator |0|Channel No.|1| 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Vydyam/Mukundan/Mangalpally/Morneault 1 198 The indicator field is used to determine whether the message is for 199 a particular DLC or it is applicable for all the DLCs in the 200 carrier. The possible values of the indicator is mentioned below. 202 Value Description 203 0 Action is to be performed on all DLCs 204 Channel number parameter is ignored. 205 1 Action is to be performed on a single 206 DLC specified by channel number. 208 This indicator value is used only by the Establish and Release 209 messages. Data messages should ignore this value. This indicator is 210 provided so that a single command can be issued to establish or 211 release all the DLCs in one DPNSS Link. 213 For channel number the valid values are 0 to 63 for DPNSS and 0 to 214 31 for DASS 2. This is because DASS 2 does not support virtual DLCs 215 and hence has only 32 DLCs. 217 2.2 Unit Data Message 219 DPNSS layer 2 does not have a unit data primitive and hence the 220 Unit Data Messages (Request, Indication) are invalid for a DUA 221 application. 223 2.3 DLC Status Message 225 For DUA, a new message is necessary to carry the status of the DLCs. 226 This message will be a Management message (i.e. its message class 227 will be a value of 0 for Management). A message type of 0x5 will be 228 used for this message. 230 The DLC Status messages are exchanged between IUA layer peers to 231 request, confirm and indicate the status of the DLCs. The DLC 232 Status messages contain the common message header followed by IUA 233 message header as described in section 2.1. 235 Vydyam/Mukundan/Mangalpally/Morneault 1 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Tag (0x11) | Length | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|D16| 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 \ / 244 / \ 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | .................... |Dxx| 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 The parameter carries the status of DLCs using two bits for each 250 DLC. 252 The possible values for the two bits are shown below: 253 Value Description 254 00 Out Of Service 255 01 Reset Attempted 256 10 Reset Completed 257 11 Information Transfer 259 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 260 DLC does not have this state. 262 For DASS 2 there are no virtual DLCs and hence information about 263 only 32 DLCs need to be carried. Therefore the status message will 264 have a length of 12 for a DASS 2 DLC Status message. 266 2.4 Error Message 268 The ERR message is sent when an invalid value or unrecognized 269 message is found in an incoming message. 271 The Error Code parameter indicates the reason for the Error Message. 272 These are the supported values in IUA. 274 Vydyam/Mukundan/Mangalpally/Morneault 1 275 Invalid Version 0x01 276 Invalid Interface Identifier 0x02 277 Unsupported Message Class 0x03 278 Unsupported Message Type 0x04 279 Unsupported Traffic Handling Mode 0x05 280 Unexpected Message 0x06 281 Protocol Error 0x07 282 Unsupported Interface Identifier Type 0x08 283 Invalid Stream Identifier 0x09 284 Unassigned TEI 0x0a 285 Unrecognized SAPI 0x0b 286 Invalid TEI, SAPI combination 0x0c 288 In DUA the error codes 0x0a to 0x0c are invalid as they are specific 289 to ISDN. 291 The following additional error codes are supported in DUA. 292 Channel Number out of range 0x0d 293 Channel Not configured 0x0e 295 3.0 IANA Considerations 297 A request will be made to IANA to assign a DUA value for the Payload 298 Protocol Identifier in SCTP Payload Data chunk. The following SCTP 299 Payload Protocol Identifier will be registered: 301 The SCTP Payload Protocol Identifier is included in each SCTP Data 302 chunk, to indicate which protocol the SCTP is carrying. This Payload 303 Protocol Identifier is not directly used by SCTP but may be used by 304 certain network entities to identify the type of information being 305 carried in a Data chunk. 307 The User Adaptation peer may use the Payload Protocol Identifier as 308 a way of determining whether the message is for IUA or DUA. 310 4.0 Message Sequence in DUA 312 An example of the message flows for establishing a data link on a 313 signaling channel, passing PDUs and releasing a data link on a 314 DPNSS channel is shown below. An active association between MGC 315 and SG is established prior to the following message flows. 317 4.1 Resetting of single DLC 319 i) Successful 320 PBX SG MGC 321 <----------- SABMR <----------- Est Req(Ind=1) 322 UA -----------> Est Cfm -----------> (DLC in RC State) 323 Ind=1) 325 Vydyam/Mukundan/Mangalpally/Morneault 1 326 ii) Unsuccessful(Link Failure) 327 PBX SG MGC 328 <----------- SABMR <----------- Est Req(Ind=1) 329 Retransmissions over 330 NT1 and NT2 expired 331 Rel Ind -----------> (DLC in RA state) 332 (RELEASE_PHYS,Ind=1) 334 4.2 Resetting all DLCs in a link 336 PBX SG MGC 337 <----------- SABMR(1) <----------- Est Req(Ind=0) 338 <----------- SABMR(2) 339 <----------- SABMR(3) 340 ............. 341 <----------- SABMR(N) 342 In each DLC either 343 UA is received or 344 NT1/NT2 is expired 345 Est Cfm -----------> (Status of DLCs 346 (Ind=0) are not updated ) 347 <----------- Status Req 348 Status cfm ---------> (Mark DLC status 349 based on 350 status bits) 351 4.3 Information Transfer on a DLC 353 PBX SG MGC 354 <----------- UI(C) <----------- Data Req 355 UI(C)-----------> Data Ind -----------> 357 4.4 Link Takedown(Single DLC) 359 PBX SG MGC 360 (For DPNSS, mark DLC as OOS) <----------- Rel Req 361 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 362 Ind=1) 363 Rel Cfm ----------> 364 (Ind=1) 366 Vydyam/Mukundan/Mangalpally/Morneault 1 367 4.5 Link Takedown(All DLCs) 369 PBX SG MGC 370 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 371 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 372 Ind=0) 373 Rel Cfm ----------> 374 (Ind=0) 375 4.6 Getting link Status 377 PBX SG MGC 378 <----------- Stat Req 379 Stat Res -----------> (Mark DLC status 380 based on 381 status bits) 382 4.7 Error conditions 384 PBX SG MGC 385 Invalid Message <----------- 386 Est/Rel/Data/Stat Req 387 Error Ind -----------> 388 (Error Code) 389 5.0 Glossary of terms 391 Real channel : The signalling channel with associated 392 traffic channel (TS). 393 Virtual channel: The signalling channel with no 394 associated traffic channel. 395 NT1 : Retransmission period of 500msec. 396 NT2 : Recommended value is 64. 398 6.0 References 400 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 401 February 2001. 403 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 404 Private Network Signaling System 1. 406 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 407 Digital Access Signaling System No 2 409 [4] ETS 300 167 (08/1993) : Transmission and Multiplexing; 410 Functional characteristic of 2048 kbits/s interfaces 411 (Standard is based on G.704, G.706). 413 7.0. Acknowledgments 415 The authors would like to thank Sudarsan Naganathan, Subhas 416 Mondal and Sivaram Subramanian of Nortel Networks for their useful 417 suggestions/comments. 419 Vydyam/Mukundan/Mangalpally/Morneault 1 420 8.0 Author's Addresses 422 Authors : Anil Vydyam, Ranjith Mukundan, Narsimuloo Mangalpally and 423 Ken Morneault 425 All correspondence regarding this draft should be sent to 426 the following addresses : 428 Mick Dragon Phone: +44 (0)1628434388 429 Nortel Networks plc EMail: mdragon@nortelnetworks.com 430 Concorde Road 431 Maidenhead 432 Berkshire SL6 4AG 433 United Kingdom 435 Ken Morneault Phone: +1-703-484-3323 436 Cisco Systems Inc. EMail: kmorneau@cisco.com 437 13615 Dulles Technology Drive 438 Herndon, VA. 20171 439 USA