idnits 2.17.1 draft-ietf-sigtran-dua-05.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 8 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 is 1 instance of too long lines in the document, the longest one being 1 character 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 202: '... The IUA Message Header [1] MUST be used with the DPTM messages,...' RFC 2119 keyword, line 387: '... SHOULD be used for DUA:...' 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 (Jan 2003) is 7743 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 516, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 521, 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: 5 errors (**), 0 flaws (~~), 6 warnings (==), 5 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 A Vydyam 7 Nortel Networks 8 Expires in 6 months Jan 2003 10 DPNSS/DASS 2 extensions to the IUA protocol 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document defines a mechanism for backhauling Digital Private 37 Network Signaling System 1 (DPNSS 1) and Digital Access Signaling 38 System 2 (DASS 2) messages over IP by extending the ISDN User 39 Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1, 40 specified in BTNR 188, is used to interconnect Private Branch 41 Exchanges (PBX) in a private network and DASS 2, specified in 42 BTNR 190, is used to connect PBXs to the PSTN. This document aims 43 to become an Appendix to IUA and to be the base for a DPNSS 1/ 44 DASS 2 User Adaptation (DUA) implementation. 46 Table of Contents 48 1.0 Introduction ......................................... 2 49 1.1 Scope ............................................. 2 50 1.2 Terminology ....................................... 2 51 1.3 DPNSS Overview .................................... 3 52 1.4 Proposed DPNSS Backhaul Architecture .............. 3 54 2.0 Changes from IUA...................................... 4 55 2.1 New Message Class for DUA.......................... 4 56 2.2 Message Header..................................... 4 57 2.3 Unit Data Message.................................. 5 58 2.4 Status Message..................................... 5 59 2.5 Management (MGMT) Messages......................... 6 60 3.0 IANA Considerations................................... 7 61 4.0 Message Sequence in DUA............................... 7 62 4.1 Resetting of single DLC............................ 7 63 4.2 Resetting all DLCs in a link....................... 8 64 4.3 Information Transfer on a DLC...................... 8 65 4.4 Link Takedown(Single DLC).......................... 8 66 4.5 Link Takedown(All DLCs)............................ 8 67 4.6 Getting link Status................................ 9 68 4.7 Error conditions................................... 9 69 5.0 Glossary of Terms .................................... 9 70 6.0 Security Considerations............................... 9 71 7.0 References............................................ 9 72 8.0 Acknowledgements...................................... 10 73 9.0 Author's Addresses.................................... 10 75 1.0 Introduction 77 This document describes a method of implementing Digital Private 78 Network Signaling System 1 (DPNSS 1) [2] - henceforth just referred 79 to as just DPNSS, and Digital Access Signaling System 2 (DASS 2) [3], 80 backhaul messaging over IP using a modified version of the ISDN User 81 Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation (DUA) 82 builds on top of IUA by defining the necessary extensions to IUA 83 for a DPNSS/DASS2 implementation. 85 1.1 Scope 87 There is a need for Switched Circuit Network (SCN) signaling 88 protocol delivery from a DPNSS Signaling Gateway (SG) to a Media 89 Gateway Controller (MGC). The delivery mechanism should support the 90 following protocols: 92 - DPNSS (Digital Private Network Signaling System) [2] 93 - DASS 2 (Digital Access Signaling System Number 2) [3] 95 Unless specifically mentioned, the details in this document are 96 applicable to both DPNSS and DASS 2. 98 1.2 Terminology 100 Data channel (D-channel) - A 64 kbit/s time slot which functions 101 as a common signaling channel on a 2048 kbits/s interface or a 102 1544 kbits/s interface which is provisioned to carry DPNSS 103 signaling. 105 DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 106 kbits/s interface or Time slots 1 to 23 on a 1544 kbits/s 107 interface are termed as DPNSS channels. These are the 108 traffic channels which carry voice or data traffic. 110 - DPNSS supports 60 Channels (30 Real and 30 Virtual) 111 - DASS2 supports 30 Channels (All Real) 113 Data Link Connection(DLC) - A DLC is the level 2 process that 114 controls the transfer of level 3 messages on behalf of one 115 DPNSS channel. A DLC uniquely identifies one DPNSS channel. 116 - DPNSS supports 60 DLCs (30 Real and 30 Virtual) 117 - DASSII supports 30 DLCs (All Real) 119 DPNSS Link - A logical collection of the D-channel and the 120 associated DPNSS channels in a 2048 kbits/s interface or a 121 1544 kbits/s interface is called a "DPNSS Link". 123 1.3 DPNSS Overview 125 DPNSS is an industry standard interface (reference BTNR 188) [2] 126 defined between a PBX and an Access Network (AN). DPNSS extends 127 facilities normally only available between extensions on a single 128 PBX to all extensions on PBXs that are connected together in a 129 private network. DPNSS was originally derived from BT's Digital 130 Access Signaling System I (DASS I) enhanced where necessary to 131 meet the private network requirements. Some of these enhancements 132 were incorporated in DASS 2 [3]. DPNSS uses a 2048 kbits/s or 133 1544 kbits/s Digital Transmission System Interface as shown in 134 Figure 1 below. 136 ---------- ---------- o--o 137 | | 2048 kbits/s | |------- /\ 138 | |--------------| | -- 139 | PBX | 1544 kbits/s | AN | 140 | |--------------| | o--o 141 | | | |------- /\ 142 ---------- ---------- -- 144 Figure 1 146 Channel 16 on a 2048 kbits/s (E1) interface and channel 24 on a 147 1544 kbits/s (T1) interface is reserved for data communication 148 between LE and AN. The channels reserved for data are called 149 "Data Channels" or "D-Channels." 151 The D-Channels are the physical media to exchange data between the 152 DPNSS protocol peer entities. A logical collection of the D-channel 153 and the associated DPNSS channels is called a "DPNSS Link". 155 1.4 Proposed DPNSS Backhaul Architecture 157 ****** DPNSS ****** IP ******* 158 *PBX *---------------* SG *--------------* MGC * 159 ****** ****** ******* 161 +-----+ +-----+ 162 |DPNSS| (NIF) |DPNSS| 163 | L3 | | L3 | 164 +-----+ +----------+ +-----+ 165 | | | | DUA| | DUA | 166 |DPNSS| |DPNSS+----+ +-----+ 167 | L2 | | L2 |SCTP| |SCTP | 168 | | | +----+ +-----+ 169 | | | | IP + | IP | 170 +-----+ +-----+----+ +-----+ 172 NIF - Nodal Interworking function 173 SCTP - Stream Control Transmission Protocol 174 DUA - DPNSS User Adaptation Layer Protocol 176 2.0 Changes from IUA 178 This section outlines the differences between DUA and IUA. 180 2.1 New Message Class for DUA 182 The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be 183 uniquely identifyable from IUA boundary primitive transport messages 184 and the boundary primitive transport messages of other IUA extensions 185 (i.e. V5 or GR-303). Therefore, it is neccessary to use a different 186 message class parameter for DUA messages. 188 For all DPNSS/DASS2 interface boundary primitives, a new Message 189 Class is introduced: 191 11 DPNSS/DASS2 Boundary Primitives Transport Messages 192 (DPTM) 194 Similar to IUA, other valid message classes for DUA are: 196 0 Management (MGMT) Message 197 3 ASP State Maintenance (ASPSM) Messages 198 4 ASP Traffic Maintenance (ASPTM) Messages 200 2.2 Message Header 202 The IUA Message Header [1] MUST be used with the DPTM messages, 203 but the DLCI field in the DLCI parameter is formatted differently. 204 Figure 2 below shows the IUA Message Header with integer-based 205 Interface Identifier. 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Tag (0x1) | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Interface Identifier (integer) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Tag (0x5) | Length=8 | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | DLCI | Spare | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2 IUA Message Header (integer-based Interface Identifier) 221 In DUA, the DLCI field has a different format in accordance with 222 the BTNR 188 [2]. 224 0 1 225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Reserved |V|0|Channel No.|1| 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Reserved: 7 bits 232 Should be set to all '0's and ignored by the receiver. 234 V-bit: 1 bit 236 The V-bit is used to determine whether the message is for 237 a particular DLC or it is applicable for all the DLCs in the 238 carrier. The possible values of the V-bit are listed below: 240 Value Description 241 0 Action is to be performed on all DLCs 242 Channel number parameter is ignored. 243 1 Action is to be performed on a single 244 DLC specified by channel number. 246 This V-bit value is used only by the Establish and Release 247 messages. Data messages should ignore this value. This indicator 248 is provided so that a single command can be issued to establish or 249 release all the DLCs in one DPNSS Link. 251 For Channel Number (Channel No.), the valid values are 0 to 63 for 252 DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not 253 support virtual DLCs and hence has only 32 DLCs. 255 2.3 Unit Data Message 257 DPNSS layer 2 does not have a unit data primitive and hence the 258 Unit Data Messages (Request, Indication) are invalid for a DUA 259 application. The Data Request and Indication messages (message 260 types 1 and 2 respectively) will be used with DUA. 262 2.4 DLC Status Message 264 For DUA, a new message is necessary to carry the status of the DLCs. 265 This message will be a Management message (i.e. its message class 266 will be a value of 0 for Management). The following message types 267 will be used for these messages: 269 5 DLC Status Request 270 6 DLC Status Confirm 271 7 DLC Status Indication 273 The DLC Status messages are exchanged between IUA layer peers to 274 request, confirm and indicate the status of the DLCs. The DLC 275 Status messages contain the common message header followed by IUA 276 message header as described in section 2.1. 278 In addition, the DLC Status Confirm and Indication messages will 279 contain the new parameter called the DLC Status parameter. This 280 parameter will have the following format for an E1 interface: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Tag (0x12) | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15| 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31| 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47| 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63| 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 NA stands for Not Applicable. D0 and D16 are not applicable for 297 an E1 interface because timeslot 0 is used for E1 framing and 298 synchronization bits and timeslot 16 is used for signaling. For 299 DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual) 300 and in case of DASS2 there would be a total of 30 DLCs (no virtuals). 302 This parameter will have the following format for a T1 interface: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Tag (0x12) | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 |D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31| 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA| 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 D23 is not applicable for a T1 interface because timeslot 23 is used 317 for signaling. For DPNSS, there would be a total of max 46 DLCs 318 (23 real + 23 virtual) and in case of DASS2 there would be a total 319 of 23 DLCs (no virtuals). 321 The parameter carries the status of DLCs using two bits for each 322 DLC. The possible values for the two bits are shown below: 324 Value Description 325 00 Out Of Service 326 01 Reset Attempted 327 10 Reset Completed 328 11 Information Transfer 330 For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2 331 DLC does not have this state. In addition, the Idle state is a 332 transient state local to the DLC so a value is not allocated for it. 334 For DASS 2 there are no virtual DLCs and hence information about 335 only 32 DLCs need to be carried. Therefore the status message will 336 have a length of 12 for a DASS 2 DLC Status message. 338 2.5 Management (MGMT) Messages 340 Only the Notify and Error messages are valid for DUA. The TEI Status 341 messages are not used. 343 2.5.1 Error Message 345 The ERR message is sent when an invalid value or unrecognized 346 message is found in an incoming message. 348 The Error Code parameter indicates the reason for the Error Message. 349 These are the supported values in IUA. 351 Invalid Version 0x01 352 Invalid Interface Identifier 0x02 353 Unsupported Message Class 0x03 354 Unsupported Message Type 0x04 355 Unsupported Traffic Handling Mode 0x05 356 Unexpected Message 0x06 357 Protocol Error 0x07 358 Unsupported Interface Identifier Type 0x08 359 Invalid Stream Identifier 0x09 360 Unassigned TEI 0x0a 361 Unrecognized SAPI 0x0b 362 Invalid TEI, SAPI combination 0x0c 363 Refused - Management Blocking 0x0d 364 ASP Identifier Required 0x0e 365 Invalid ASP Identifier 0x0f 367 In DUA, the error codes 0x0a, 0x0b and 0x0c are invalid as they are 368 specific to ISDN. 370 The following additional error codes are supported in DUA: 372 Channel Number out of range 0x1c 373 Channel Number not configured 0x1d 375 The "Channel Number out of range" error is sent if a message is 376 received with a channel number greater than 63 for DPNSS or 31 for 377 DASS 2. 379 The "Channel Number not configured" error is sent if a message is 380 received with a channel number that is not configured. 382 3.0 IANA Considerations 384 A request will be made to IANA to assign a DUA value for the SCTP 385 Payload Protocol Identifier field used in SCTP Payload Data chunks. 386 The following value for the SCTP Payload Protocol Identifier field 387 SHOULD be used for DUA: 389 SCTP Payload Protocol ID = 10 391 However, the IUA SCTP Payload Protocol ID can also be used. 393 The SCTP Payload Protocol Identifier is included in each SCTP Data 394 chunk, to indicate which protocol the SCTP is carrying. This Payload 395 Protocol Identifier is not directly used by SCTP but may be used by 396 certain network entities to identify the type of information being 397 carried in a Data chunk. 399 The User Adaptation peer may use the Payload Protocol Identifier as 400 a way of determining whether the message is for IUA or DUA. 402 4.0 Message Sequence in DUA 404 An example of the message flows for establishing a data link on a 405 signaling channel, passing PDUs and releasing a data link on a 406 DPNSS channel is shown below. An active association between MGC 407 and SG is established prior to the following message flows. 409 4.1 Resetting of single DLC 411 i) Successful 412 PBX SG MGC 413 <----------- SABMR <----------- Est Req(Ind=1) 414 UA -----------> Est Cfm -----------> (DLC in RC State) 415 Ind=1) 417 ii) Unsuccessful(Link Failure) 418 PBX SG MGC 419 <----------- SABMR <----------- Est Req(Ind=1) 420 Retransmissions over 421 NT1 and NT2 expired 422 Rel Ind -----------> (DLC in RA state) 423 (RELEASE_OTHER,Ind=1) 425 4.2 Resetting all DLCs in a link 427 PBX SG MGC 428 <----------- SABMR(1) <----------- Est Req(Ind=0) 429 <----------- SABMR(2) 430 <----------- SABMR(3) 431 ............. 432 <----------- SABMR(N) 433 In each DLC either 434 UA is received or 435 NT1/NT2 is expired 436 Est Cfm -----------> (Status of DLCs 437 (Ind=0) are not updated ) 438 <----------- Status Req 439 Status cfm ---------> (Mark DLC status 440 based on 441 status bits) 443 If one of more DLCs remains out-of-service after this procedure 444 (e.g. due to layer 2 management), the MGC can either retry this 445 DLC with an Est Req(Ind=1) indicating the specific DLC or with 446 a Est Req(Ind=0) and the SG will retry the appropriate DLC that 447 is out-of-service. 449 4.3 Information Transfer on a DLC 451 PBX SG MGC 452 <----------- UI(C) <----------- Data Req 453 UI(R)-----------> Data Ind -----------> 455 4.4 Link Takedown(Single DLC) 457 PBX SG MGC 458 (For DPNSS, mark DLC as OOS) <----------- Rel Req 459 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 460 Ind=1) 461 Rel Cfm ----------> 462 (Ind=1) 464 4.5 Link Takedown(All DLCs) 466 PBX SG MGC 467 (For DPNSS, mark all DLCs as OOS) <-------- Rel Req 468 (For DASSII, mark DLC as RA) (RELEASE_MGMT, 469 Ind=0) 470 Rel Cfm ----------> 471 (Ind=0) 473 4.6 Getting link Status 475 PBX SG MGC 476 <----------- Stat Req 477 Stat Cfm -----------> (Mark DLC status 478 based on 479 status bits) 481 4.7 Error conditions 483 PBX SG MGC 484 Invalid Message <-----------Est/Rel/Data/- 485 Stat Req 486 Error Ind -----------> 487 (Error Code) 489 5.0 Glossary of terms 491 Real channel : The signalling channel with associated 492 traffic channel (TS). 493 Virtual channel: The signalling channel with no 494 associated traffic channel. 495 NT1 : Retransmission period of 500msec. 496 NT2 : Recommended value is 64. 498 6.0 Security Considerations 500 The security considerations discussed for the ISDN User Adaptation 501 Protocol (IUAP) [1] Section 6.0 apply to this document as well. 503 7.0 References 505 7.1 Normative References 507 [1] Morneault, et al., "ISDN Q.921-User Adaptation Layer", RFC 3057, 508 February 2001. 510 [2] BTNR (British Telecom Network Requirements) 188 Issue 6 Digital 511 Private Network Signaling System 1. 513 [3] BTNR (British Telecom Network Requirements) 190 Issue 2 514 Digital Access Signaling System No 2 516 [4] IUA (RFC3057) Implementors Guide, draft-ietf-sigtran-iua-imp- 517 guide-01.txt, Jan 2003 519 7.2 Informative References 521 [5] ETS 300 167 (08/1993) : Transmission and Multiplexing; 522 Functional characteristic of 2048 kbits/s interfaces 523 (Standard is based on G.704, G.706). 525 8.0 Acknowledgments 527 The authors would like to thank Subhas Mondal and Sivaram 528 Subramanian of Nortel Networks for their useful suggestions/ 529 comments. 531 9.0 Author's Addresses 533 Authors : Ranjith Mukundan, Ken Morneault, Narsimuloo Mangalpally 534 and Anil Vydyam 536 All correspondence regarding this draft should be sent to 537 the following addresses : 539 Ranjith Mukundan Phone +91-80-8520408 540 Wipro Technologies Email ranjith.mukundan@wipro.com 541 72, Electronics City, 542 Hosur Main Road, 543 Bangalore 561229 544 India 546 Ken Morneault Phone: +1-703-484-3323 547 Cisco Systems Inc. EMail: kmorneau@cisco.com 548 13615 Dulles Technology Drive 549 Herndon, VA. 20171 550 USA