idnits 2.17.1 draft-ietf-sigtran-dua-07.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 9 longer pages, the longest (page 6) being 87 lines == It seems as if not all pages are separated by form feeds - found 8 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 211: '... The IUA Message Header [1] MUST be used with the DPTM messages,...' RFC 2119 keyword, line 396: '... SHOULD be used for DUA:...' RFC 2119 keyword, line 400: '...load Protocol ID MAY be used, for inst...' RFC 2119 keyword, line 405: '...rectly used by SCTP but MAY be used by...' RFC 2119 keyword, line 409: '... Adaptation peer MAY use the Payload P...' 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 (Oct 2003) is 7497 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: '6' is defined on line 526, 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-rfc3057bis-00 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Mukundan 2 Wipro Technologies 3 Ken Morneault 4 Cisco Systems 5 N Mangalpally 6 Nortel Networks 7 Expires in 6 months Oct 2003 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 Digital Private 36 Network Signaling System 1 (DPNSS 1) and Digital Access Signaling 37 System 2 (DASS 2) messages over IP by extending the ISDN User 38 Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, 39 specified in BTNR 188, is used to interconnect Private Branch 40 Exchanges (PBX) in a private network and DASS 2, specified in 41 BTNR 190, is used to connect PBXs to the PSTN. This document aims 42 to become an Appendix to IUA and to be the base for a DPNSS 1/ 43 DASS 2 User Adaptation (DUA) implementation. 45 Table of Contents 47 1.0 Introduction ......................................... 2 48 1.1 Scope ............................................. 2 49 1.2 Terminology ....................................... 2 50 1.3 DPNSS Overview .................................... 3 51 1.4 Proposed DPNSS Backhaul Architecture .............. 3 53 2.0 Changes from IUA...................................... 4 54 2.1 New Message Class for DUA.......................... 4 55 2.2 Message Header..................................... 4 56 2.3 Unit Data Message.................................. 5 57 2.4 Status Message..................................... 5 58 2.5 Management (MGMT) Messages......................... 6 59 3.0 IANA Considerations................................... 7 60 4.0 Message Sequence in DUA............................... 7 61 4.1 Resetting of single DLC............................ 7 62 4.2 Resetting all DLCs in a link....................... 8 63 4.3 Information Transfer on a DLC...................... 8 64 4.4 Link Takedown(Single DLC).......................... 8 65 4.5 Link Takedown(All DLCs)............................ 8 66 4.6 Getting link Status................................ 9 67 4.7 Error conditions................................... 9 68 5.0 Security Considerations............................... 9 69 6.0 References............................................ 9 70 7.0 Acknowledgements...................................... 10 71 8.0 Acknowledgements...................................... 10 72 9.0 Editor's Addresses.................................... 10 74 1.0 Introduction 76 This document describes a method of implementing Digital Private 77 Network Signaling System 1 (DPNSS 1) [2] - henceforth just referred 78 to as just DPNSS, and Digital Access Signaling System 2 (DASS 2) [3], 79 backhaul messaging over IP using a modified version of the ISDN User 80 Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation (DUA) 81 builds on top of IUA by defining the necessary extensions to IUA 82 for a DPNSS/DASS2 implementation. 84 1.1 Scope 86 There is a need for Switched Circuit Network (SCN) signaling 87 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 88 Gateway Controller (MGC). The delivery mechanism should support the 89 following protocols: 91 - DPNSS (Digital Private Network Signaling System) [2] 92 - DASS 2 (Digital Access Signaling System Number 2) [3] 94 Unless specifically mentioned, the details in this document are 95 applicable to both DPNSS and DASS 2. 97 1.2 Terminology 99 Data channel (D-channel) - A 64 kbit/s time slot which functions 100 as a common signaling channel on a 2048 kbits/s interface or a 101 1544 kbits/s interface which is provisioned to carry DPNSS 102 signaling. 104 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 105 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 106 interface are termed as DPNSS channels. These are the 107 traffic channels which carry voice or data traffic. 109 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 110 - DASS2 supports 30 Channels (All Real) 112 Data Link Connection(DLC) - A DLC is the level 2 process that 113 controls the transfer of level 3 messages on behalf of one 114 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 115 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 116 - DASSII supports 30 DLCs (All Real) 118 DPNSS Link - A logical collection of the D-channel and the 119 associated DPNSS channels in a 2048 kbits/s interface or a 120 1544 kbits/s interface is called a "DPNSS Link". 122 Real channel - A signalling channel with associated traffic 123 channel (TS). 125 Virtual channel - A signalling channel with no associated traffic 126 channel. 128 NT1 - The DPNSS minimum retransmission period. 130 NT2 - The DPNSS minimum post retransmission acknowledgement delay. 132 1.3 DPNSS Overview 134 DPNSS is an industry standard interface (reference BTNR 188) [2] 135 defined between a PBX and an Access Network (AN). DPNSS extends 136 facilities normally only available between extensions on a single 137 PBX to all extensions on PBXs that are connected together in a 138 private network. DPNSS was originally derived from BT's Digital 139 Access Signaling System I (DASS I) enhanced where necessary to 140 meet the private network requirements. Some of these enhancements 141 were incorporated in DASS 2 [3]. DPNSS uses a 2048 kbits/s or 142 1544 kbits/s Digital Transmission System Interface as shown in 143 Figure 1 below. 145 ---------- ---------- o--o 146 | | 2048 kbits/s | |------- /\ 147 | |--------------| | -- 148 | PBX | 1544 kbits/s | AN | 149 | |--------------| | o--o 150 | | | |------- /\ 151 ---------- ---------- -- 153 Figure 1 155 Channel 16 on a 2048 kbits/s (E1) interface and channel 24 on a 156 1544 kbits/s (T1) interface is reserved for data communication 157 between LE and AN. The channels reserved for data are called 158 "Data Channels" or "D-Channels." 160 The D-Channels are the physical media to exchange data between the 161 DPNSS protocol peer entities. A logical collection of the D-channel 162 and the associated DPNSS channels is called a "DPNSS Link". 164 1.4 Proposed DPNSS Backhaul Architecture 166 ****** DPNSS ****** IP ******* 167 *PBX *---------------* SG *--------------* MGC * 168 ****** ****** ******* 170 +-----+ +-----+ 171 |DPNSS| (NIF) |DPNSS| 172 | L3 | | L3 | 173 +-----+ +----------+ +-----+ 174 | | | | DUA| | DUA | 175 |DPNSS| |DPNSS+----+ +-----+ 176 | L2 | | L2 |SCTP| |SCTP | 177 | | | +----+ +-----+ 178 | | | | IP + | IP | 179 +-----+ +-----+----+ +-----+ 181 NIF - Nodal Interworking function 182 SCTP - Stream Control Transmission Protocol 183 DUA - DPNSS User Adaptation Layer Protocol 185 2.0 Changes from IUA 187 This section outlines the differences between DUA and IUA. 189 2.1 New Message Class for DUA 191 The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be 192 identifiable from IUA boundary primitive transport messages and the 193 boundary primitive transport messages of other IUA extensions 194 (i.e. V5 or GR-303). Therefore, it is neccessary to use a different 195 message class parameter for DUA messages. 197 For all DPNSS/DASS2 interface boundary primitives, a new Message 198 Class is introduced: 200 13 DPNSS/DASS2 Boundary Primitives Transport Messages 201 (DPTM) 203 Similar to IUA, other valid message classes for DUA are: 205 0 Management (MGMT) Message 206 3 ASP State Maintenance (ASPSM) Messages 207 4 ASP Traffic Maintenance (ASPTM) Messages 209 2.2 Message Header 211 The IUA Message Header [1] MUST be used with the DPTM messages, 212 but the DLCI field in the DLCI parameter is formatted differently. 213 Figure 2 below shows the IUA Message Header with integer-based 214 Interface Identifier. 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Tag (0x1) | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Interface Identifier (integer) | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Tag (0x5) | Length=8 | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | DLCI | Spare | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 2 IUA Message Header (integer-based Interface Identifier) 230 In DUA, the DLCI field has a different format in accordance with 231 the BTNR 188 [2]. 233 0 1 234 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved |V|0|Channel No.|1| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Reserved: 7 bits 241 Should be set to all '0's and ignored by the receiver. 243 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 A request will be made to IANA to assign a DUA value for the SCTP 394 Payload Protocol Identifier field used in SCTP Payload Data chunks. 395 The following value for the SCTP Payload Protocol Identifier field 396 SHOULD be used for DUA: 398 SCTP Payload Protocol ID = 10 400 However, the IUA SCTP Payload Protocol ID MAY be used, for instance, 401 if one wanted to backhaul ISDN and DPNSS over the same SCTP association. 403 The SCTP Payload Protocol Identifier is included in each SCTP Data 404 chunk, to indicate which protocol the SCTP is carrying. This Payload 405 Protocol Identifier is not directly used by SCTP but MAY be used by 406 certain network entities to identify the type of information being 407 carried in a Data chunk. 409 The User Adaptation peer MAY use the Payload Protocol Identifier as 410 a way of determining whether the message is for IUA or DUA. 412 4.0 Message Sequence in DUA 414 An example of the message flows for establishing a data link on a 415 signaling channel, passing PDUs and releasing a data link on a 416 DPNSS channel is shown below. An active association between MGC 417 and SG is established prior to the following message flows. 419 4.1 Resetting of single DLC 421 i) Successful 422 PBX SG MGC 423 <----------- SABMR <----------- Est Req(Ind=1) 424 UA -----------> Est Cfm -----------> (DLC in RC State) 425 Ind=1) 427 ii) Unsuccessful(Link Failure) 428 PBX SG MGC 429 <----------- SABMR <----------- Est Req(Ind=1) 430 Retransmissions over 431 NT1 and NT2 expired 432 Rel Ind -----------> (DLC in RA state) 433 (RELEASE_OTHER,Ind=1) 435 4.2 Resetting all DLCs in a link 437 PBX SG MGC 438 <----------- SABMR(1) <----------- Est Req(Ind=0) 439 <----------- SABMR(2) 440 <----------- SABMR(3) 441 ............. 442 <----------- SABMR(N) 443 In each DLC either 444 UA is received or 445 NT1/NT2 is expired 446 Est Cfm -----------> (Status of DLCs 447 (Ind=0) are not updated ) 448 <----------- Status Req 449 Status cfm ---------> (Mark DLC status 450 based on 451 status bits) 453 If one of more DLCs remains out-of-service after this procedure 454 (e.g. due to layer 2 management), the MGC can either retry this 455 DLC with an Est Req(Ind=1) indicating the specific DLC or with 456 a Est Req(Ind=0) and the SG will retry the appropriate DLC that 457 is out-of-service. 459 4.3 Information Transfer on a DLC 461 PBX SG MGC 462 <----------- UI(C) <----------- Data Req 463 UI(R)-----------> Data Ind -----------> 465 4.4 Link Takedown(Single DLC) 467 PBX SG MGC 468 (For DPNSS, mark DLC as OOS) <----------- Rel Req 469 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 470 Ind=1) 471 Rel Cfm ----------> 472 (Ind=1) 474 4.5 Link Takedown(All DLCs) 476 PBX SG MGC 477 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 478 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 479 Ind=0) 480 Rel Cfm ----------> 481 (Ind=0) 483 4.6 Getting link Status 485 PBX SG MGC 486 <----------- Stat Req 487 Stat Cfm -----------> (Mark DLC status 488 based on 489 status bits) 491 4.7 Error conditions 493 PBX SG MGC 494 Invalid Message <-----------Est/Rel/Data/- 495 Stat Req 496 Error Ind -----------> 497 (Error Code) 499 5.0 Security Considerations 501 The security considerations discussed for the ISDN User Adaptation 502 Protocol (IUAP) [1][4] Section 6.0 and the Security Considerations 503 for SIGTRAN Protocols document [5] apply to this document as well. 505 6.0 References 507 6.1 Normative References 509 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 510 February 2001. 512 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 513 Private Network Signaling System 1. 515 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 516 Digital Access Signaling System No 2 518 [4] Morneault, et al., IUA (RFC3057) bis, draft-ietf-sigtran- 519 rfc3057bis-00.txt, May 2003 521 [5] Loughnet, et al., Security Considerations for SIGTRAN Protocols, 522 draft-ietf-sigtran-security-03.txt, June 29, 2003 524 6.2 Informative References 526 [6] ETS 300 167 (08/1993) : Transmission and Multiplexing; 527 Functional characteristic of 2048 kbits/s interfaces 528 (Standard is based on G.704, G.706). 530 7.0 Acknowledgments 532 The authors would like to thank Subhas Mondal and Sivaram 533 Subramanian of Nortel Networks for their useful suggestions/ 534 comments. 536 8.0 Contributors 538 In addition to the listed authors, the following person contributed 539 significantly to this document: 541 Anil Vydyam 542 Nortel Networks 543 Email: anil.vydyam@wipro.com 545 9.0 Author's Addresses 547 All correspondence regarding this draft should be sent to 548 the following addresses: 550 Ranjith Mukundan Phone +91-80-8520408 551 Wipro Technologies Email ranjith.mukundan@wipro.com 552 72, Electronics City, 553 Hosur Main Road, 554 Bangalore 561229 555 India 557 Ken Morneault Phone: +1-703-484-3323 558 Cisco Systems Inc. EMail: kmorneau@cisco.com 559 13615 Dulles Technology Drive 560 Herndon, VA. 20171 561 USA 563 Narsimuloo Mangalpally Phone +1 613 967 5034 564 250 Sidney Street EMail narsim@nortelnetworks.com 565 Belleville, Ontario K8P 3Z3 566 Canada