summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4129.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4129.txt')
-rw-r--r--doc/rfc/rfc4129.txt843
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc4129.txt b/doc/rfc/rfc4129.txt
new file mode 100644
index 0000000..b071cbd
--- /dev/null
+++ b/doc/rfc/rfc4129.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group R. Mukundan
+Request for Comments: 4129 Wipro Technologies
+Category: Standards Track K. Morneault
+ Cisco Systems
+ N. Mangalpally
+ Nortel Networks
+ August 2005
+
+
+ Digital Private Network Signaling System (DPNSS)/
+ Digital Access Signaling System 2 (DASS 2)
+ Extensions to the IUA Protocol
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2005).
+
+Abstract
+
+ This document defines a mechanism for backhauling Digital Private
+ Network Signaling System 1 (DPNSS 1) and Digital Access Signaling
+ System 2 (DASS 2) messages over IP by extending the ISDN User
+ Adaptation (IUA) Layer Protocol defined in RFC 3057. DPNSS 1,
+ specified in ND1301:2001/03 (formerly BTNR 188), is used to
+ interconnect Private Branch Exchanges (PBX) in a private network.
+ DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.
+ This document aims to become an Appendix to IUA and to be the base
+ for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 1]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+Table of Contents
+
+ 1. Introduction ................................................. 2
+ 1.1. Scope .................................................. 2
+ 1.2. Terminology ............................................ 3
+ 1.3. DPNSS Overview ......................................... 4
+ 1.4. Proposed DPNSS Backhaul Architecture ................... 5
+ 2. Changes from IUA ............................................. 5
+ 2.1. New Message Class for DUA .............................. 5
+ 2.2. Message Header ......................................... 6
+ 2.3. Unit Data Message ...................................... 7
+ 2.4. DLC Status Message ..................................... 7
+ 2.5. Management (MGMT) Messages ............................. 9
+ 3. IANA Considerations .......................................... 10
+ 4. Use of SCTP Payload Protocol ID .............................. 10
+ 5. Message Sequence in DUA ...................................... 11
+ 5.1. Resetting of single DLC ................................ 11
+ 5.2. Resetting all DLCs in a Link ........................... 11
+ 5.3. Information Transfer on a DLC .......................... 12
+ 5.4. Link Takedown (Single DLC) ............................. 12
+ 5.5. Link Takedown (All DLCs) ............................... 12
+ 5.6. Getting Link Status .................................... 12
+ 5.7. Error Conditions ....................................... 12
+ 6. Security Considerations ...................................... 13
+ 7. References ................................................... 13
+ 7.1. Normative References ................................... 13
+ 8. Acknowledgements ............................................. 13
+
+1. Introduction
+
+ This document describes a method of implementing Digital Private
+ Network Signaling System 1 (DPNSS 1) [2] (henceforth referred to as
+ just DPNSS) and Digital Access Signaling System 2 (DASS 2)[3]
+ backhaul messaging over IP using a modified version of the ISDN User
+ Adaptation Protocol (IUAP) [1]. The DPNSS/DASS 2 User Adaptation
+ (DUA) builds on top of IUA by defining the necessary extensions to
+ IUA for a DPNSS/DASS2 implementation.
+
+1.1. Scope
+
+ There is a need for Switched Circuit Network (SCN) signaling protocol
+ delivery from a DPNSS Signaling Gateway (SG) to a Media Gateway
+ Controller (MGC). The delivery mechanism should support the
+ following protocols:
+
+ - DPNSS (Digital Private Network Signaling System) [2]
+ - DASS 2 (Digital Access Signaling System Number 2) [3]
+
+
+
+
+Mukundan, et al. Standards Track [Page 2]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ Unless specifically mentioned, the details in this document are
+ applicable to both DPNSS and DASS 2.
+
+1.2. Terminology
+
+ Data channel (D-channel) - A 64 kbit/s time slot that functions as a
+ common signaling channel on a 2048 kbits/s interface or a 1544
+ kbits/s interface that is provisioned to carry DPNSS signaling.
+
+ DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 kbits/s
+ interface or Time slots 1 to 23 on a 1544 kbits/s interface are
+ termed as DPNSS channels. These are the traffic channels that carry
+ voice or data traffic.
+
+ - DPNSS supports 60 Channels (30 Real and 30 Virtual)
+ - DASS2 supports 30 Channels (All Real)
+
+ Data Link Connection(DLC) - A DLC is the level 2 process that
+ controls the transfer of level 3 messages on behalf of one DPNSS
+ channel. A DLC uniquely identifies one DPNSS channel.
+
+ - DPNSS supports 60 DLCs (30 Real and 30 Virtual)
+ - DASSII supports 30 DLCs (All Real)
+
+ DPNSS Link - A logical collection of the D-channel and the
+ associated DPNSS channels in a 2048 kbits/s interface or a 1544
+ kbits/s interface is called a "DPNSS Link".
+
+ Real channel - A signalling channel with an associated traffic
+ channel (TS).
+
+ Virtual channel - A signalling channel with no associated traffic
+ channel.
+
+ NT1 - The DPNSS minimum retransmission period.
+
+ NT2 - The DPNSS minimum post retransmission acknowledgement delay.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [5].
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 3]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+1.3. DPNSS Overview
+
+ DPNSS is an industry standard interface (ref. ND1301:2001/03) [2],
+ which is defined between a PBX and an Access Network (AN). DPNSS
+ extends facilities that are normally only available between
+ extensions on a single PBX to all extensions on PBXs that are
+ connected in a private network. DPNSS was originally derived from
+ BT's Digital Access Signaling System I (DASS I), and was enhanced
+ where necessary to meet the private network requirements. Some of
+ these enhancements were incorporated in DASS 2 [3]. DPNSS uses a
+ 2048 kbits/s or 1544 kbits/s Digital Transmission System Interface,
+ as shown in Figure 1 below.
+
+ ---------- ---------- o--o
+ | | 2048 kbits/s | |------- /\
+ | |--------------| | --
+ | PBX | 1544 kbits/s | AN |
+ | |--------------| | o--o
+ | | | |------- /\
+ ---------- ---------- --
+
+ Figure 1
+
+ Channel 16 is on a 2048 kbits/s (E1) interface and channel 24 is on a
+ 1544 kbits/s (T1) interface and is reserved for data communication
+ between LE and AN. The channels reserved for data are called "Data
+ Channels" or "D-Channels."
+
+ The D-Channels are the physical media used to exchange data between
+ the DPNSS protocol peer entities. A logical collection of the
+ D-channel and the associated DPNSS channels is called a "DPNSS Link".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 4]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+1.4. Proposed DPNSS Backhaul Architecture
+
+ ****** DPNSS ****** IP *******
+ *PBX *---------------* SG *--------------* MGC *
+ ****** ****** *******
+
+ +-----+ +-----+
+ |DPNSS| (NIF) |DPNSS|
+ | L3 | | L3 |
+ +-----+ +----------+ +-----+
+ | | | | DUA| | DUA |
+ |DPNSS| |DPNSS+----+ +-----+
+ | L2 | | L2 |SCTP| |SCTP |
+ | | | +----+ +-----+
+ | | | | IP + | IP |
+ +-----+ +-----+----+ +-----+
+
+ NIF - Nodal Interworking function
+ SCTP - Stream Control Transmission Protocol
+ DUA - DPNSS User Adaptation Layer Protocol
+
+2. Changes from IUA
+
+ This section outlines the differences between DUA and IUA.
+
+2.1. New Message Class for DUA
+
+ The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be
+ identifiable from IUA boundary primitive transport messages and the
+ boundary primitive transport messages of other IUA extensions (i.e.,
+ V5 or GR-303). Therefore, it is necessary to use a different message
+ class parameter for DUA messages.
+
+ For all DPNSS/DASS2 interface boundary primitives, a new Message
+ Class is introduced:
+
+ 13 DPNSS/DASS2 Boundary Primitives Transport Messages
+ (DPTM)
+
+ Similar to IUA, other valid message classes for DUA are:
+
+ 0 Management (MGMT) Message
+ 3 ASP State Maintenance (ASPSM) Messages
+ 4 ASP Traffic Maintenance (ASPTM) Messages
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 5]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+2.2. Message Header
+
+ The IUA Message Header [1] MUST be used with the DPTM messages, but
+ the DLCI field in the DLCI parameter is formatted differently.
+ Figure 2 below shows the IUA Message Header with integer-based
+ Interface Identifier.
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x1) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Interface Identifier (integer) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x5) | Length=8 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | DLCI | Spare |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 2 IUA Message Header (integer-based Interface Identifier)
+
+ In DUA, the DLCI field has a different format, in accordance with the
+ ND1301:2001/03 (formerly BTNR 188) [2].
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |V|0|Channel No.|1|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Reserved: 7 bits
+
+ Should be set to all '0's and ignored by the receiver.
+
+ V-bit: 1 bit
+
+ The V-bit is used to determine if the message is for a particular
+ DLC or if it is applicable for all the DLCs in the carrier. The
+ possible values of the V-bit are listed below:
+
+ Value Description
+ 0 Action is to be performed on all DLCs;
+ Channel number parameter is ignored.
+ 1 Action is to be performed on a single
+ DLC specified by channel number.
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 6]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ This V-bit value is used only by the Establish and Release
+ messages. Data messages should ignore this value. This indicator
+ is provided so that a single command can be issued to establish or
+ release all the DLCs in one DPNSS Link.
+
+ For Channel Number (Channel No.), the valid values are 0 to 63 for
+ DPNSS and 0 to 31 for DASS 2. This is because DASS 2 does not
+ support virtual DLCs and, hence, has only 32 DLCs.
+
+2.3. Unit Data Message
+
+ DPNSS layer 2 does not have a unit data primitive and, hence, the
+ Unit Data Messages (Request, Indication) are invalid for a DUA
+ application. The Data Request and Indication messages (message types
+ 1 and 2, respectively) will be used with DUA.
+
+2.4. DLC Status Message
+
+ For DUA, a new message is necessary to carry the status of the DLCs.
+ This message will be a Management message (i.e., its message class
+ will be a value of 0 for Management). The following message types
+ will be used for these messages:
+
+ 5 DLC Status Request
+ 6 DLC Status Confirm
+ 7 DLC Status Indication
+
+ The DLC Status messages are exchanged between DUA layer peers to
+ request, confirm, and indicate the status of the DLCs. The DLC
+ Status messages contain the common message header, followed by IUA
+ message header, as described in section 2.2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 7]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ In addition, the DLC Status Confirm and Indication messages will
+ contain the new parameter, called the DLC Status parameter. This
+ parameter will have the following format for an E1 interface:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x12) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ NA stands for Not Applicable. D0 and D16 are not applicable for an
+ E1 interface because timeslot 0 is used for E1 framing and
+ synchronization bits and timeslot 16 is used for signaling. For
+ DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual)
+ and in case of DASS2 there would be a total of 30 DLCs (no virtuals).
+
+ This parameter will have the following format for a T1 interface:
+
+ 0 1 2 3
+ 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
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Tag (0x12) | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ D23 is not applicable for a T1 interface because timeslot 23 is used
+ for signaling. For DPNSS, there would be a total of max 46 DLCs (23
+ real + 23 virtual) and in case of DASS2 there would be a total of 23
+ DLCs (no virtuals).
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 8]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ The parameter carries the status of DLCs using two bits for each DLC.
+ The possible values for the two bits are shown below:
+
+ Value Description
+ 00 Out Of Service
+ 01 Reset Attempted
+ 10 Reset Completed
+ 11 Information Transfer
+
+ For DASS 2, the value 00 (Out Of Service) is invalid because the DASS
+ 2 DLC does not have this state. In addition, the Idle state is a
+ transient state local to the DLC, therefore, a value is not allocated
+ for it.
+
+ For DASS 2, there are no virtual DLCs and, hence, information about
+ only 32 DLCs need to be carried. Therefore, the status message will
+ have a length of 12 for a DASS 2 DLC Status message.
+
+2.5. Management (MGMT) Messages
+
+ Only the Notify and Error messages are valid for DUA. The TEI Status
+ messages are not used.
+
+2.5.1. Error Message
+
+ The ERR message is sent when an invalid value or unrecognized message
+ is found in an incoming message.
+
+ The Error Code parameter indicates the reason for the Error Message.
+ These are the supported values in IUA.
+
+ Invalid Version 0x01
+ Invalid Interface Identifier 0x02
+ Unsupported Message Class 0x03
+ Unsupported Message Type 0x04
+ Unsupported Traffic Handling Mode 0x05
+ Unexpected Message 0x06
+ Protocol Error 0x07
+ Unsupported Interface Identifier Type 0x08
+ Invalid Stream Identifier 0x09
+ Unassigned TEI 0x0a
+ Unrecognized SAPI 0x0b
+ Invalid TEI, SAPI combination 0x0c
+ Refused - Management Blocking 0x0d
+ ASP Identifier Required 0x0e
+ Invalid ASP Identifier 0x0f
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 9]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are
+ specific to ISDN.
+
+ The following additional error codes are supported in DUA:
+
+ Channel Number out of range 0x1c
+ Channel Number not configured 0x1d
+
+ The "Channel Number out of range" error is sent if a message is
+ received with a channel number greater than 63 for DPNSS or 31 for
+ DASS 2.
+
+ The "Channel Number not configured" error is sent if a message is
+ received with a channel number that is not configured.
+
+3. IANA Considerations
+
+ IANA has assigned a DUA value for the SCTP Payload Protocol
+ Identifier field that is used in SCTP Payload Data chunks. The
+ following value for the SCTP Payload Protocol Identifier field SHOULD
+ be used for DUA:
+
+ SCTP Payload Protocol ID = "10"
+
+4. Use of SCTP Payload Protocol ID
+
+ As an option, the IUA value for SCTP Payload Protocol ID MAY also be
+ used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS
+ over the same SCTP association. However, use of separate SCTP
+ Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the
+ primary option, even in scenarios where ISDN and DPNSS are backhauled
+ over the same SCTP association.
+
+ SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only DPNSS
+ is backhauled over an SCTP association (i.e., in scenarios where
+ simultaneous backhauling of ISDN and DPNSS over the same association
+ is NOT required).
+
+ The SCTP Payload Protocol Identifier is included in each SCTP Data
+ chunk, to indicate which protocol the SCTP is carrying. This Payload
+ Protocol Identifier is not directly used by SCTP but MAY be used by
+ certain network entities to identify the type of information being
+ carried in a Data chunk.
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 10]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+5. Message Sequence in DUA
+
+ An example of the message flows for establishing a data link on a
+ signaling channel, passing PDUs and releasing a data link on a DPNSS
+ channel is shown below. An active association between MGC and SG is
+ established prior to the following message flows.
+
+5.1. Resetting of single DLC
+
+ i) Successful
+
+ PBX SG MGC
+ <----------- SABMR <----------- Est Req(Ind=1)
+ UA -----------> Est Cfm -----------> (DLC in RC State)
+ Ind=1)
+
+ ii) Unsuccessful(Link Failure)
+
+ PBX SG MGC
+ <----------- SABMR <----------- Est Req(Ind=1)
+ Retransmissions over
+ NT1 and NT2 expired
+ Rel Ind -----------> (DLC in RA state)
+ (RELEASE_OTHER,Ind=1)
+
+5.2. Resetting all DLCs in a Link
+
+ PBX SG MGC
+ <----------- SABMR(1) <----------- Est Req(Ind=0)
+ <----------- SABMR(2)
+ <----------- SABMR(3)
+ .............
+ <----------- SABMR(N)
+ In each DLC either
+ UA is received or
+ NT1/NT2 is expired
+
+
+ Est Cfm -----------> (Status of DLCs
+ (Ind=0) are not updated)
+ <----------- Status Req
+ Status cfm ----------> (Mark DLC status
+ based on
+ status bits)
+
+ If one of more DLCs remains out-of-service after this procedure
+ (e.g., due to layer 2 management), the MGC can either retry this DLC
+ with an Est Req(Ind=1) indicating the specific DLC or with an
+
+
+
+Mukundan, et al. Standards Track [Page 11]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+ Est Req(Ind=0) and the SG will retry the appropriate DLC that is
+ out-of-service.
+
+5.3. Information Transfer on a DLC
+
+ PBX SG MGC
+ <----------- UI(C) <----------- Data Req
+ UI(R)-----------> Data Ind ----------->
+
+5.4. Link Takedown (Single DLC)
+
+ PBX SG MGC
+ (For DPNSS, mark DLC as OOS) <----------- Rel Req
+ (For DASSII, mark DLC as RA) (RELEASE_MGMT,
+ Ind=1)
+ Rel Cfm ---------->
+ (Ind=1)
+
+5.5. Link Takedown (All DLCs)
+
+ PBX SG MGC
+ (For DPNSS, mark all DLCs as OOS) <-------- Rel Req
+ (For DASSII, mark DLC as RA) (RELEASE_MGMT,
+ Ind=0)
+ Rel Cfm ---------->
+ (Ind=0)
+
+5.6. Getting Link Status
+
+ PBX SG MGC
+ <----------- Stat Req
+ Stat Cfm -----------> (Mark DLC status
+ based on
+ status bits)
+
+5.7. Error Conditions
+
+ PBX SG MGC
+ Invalid Message <-----------Est/Rel/Data/-
+ Stat Req
+ Error Ind ----------->
+ (Error Code)
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 12]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+6. Security Considerations
+
+ The security considerations for the ISDN User Adaptation Protocol
+ (IUAP) [1] (Section 6) and the security considerations for SIGTRAN
+ Protocols document [4] apply to this document as well.
+
+7. References
+
+7.1. Normative References
+
+ [1] Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom,
+ "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.
+
+ [2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private
+ Signalling System No 1 (DPNSS 1) (Formerly BTNR 188).
+
+ [3] BTNR (British Telecom Network Requirements) 190 Issue 2 Digital
+ Access Signaling System No 2.
+
+ [4] Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
+ Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
+ 3788, June 2004.
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+8. Acknowledgements
+
+ The authors would like to thank Shashi Kumar and Venkatesh Seshasayee
+ of Wipro Technologies for their useful suggestions and comments.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 13]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+Authors' Addresses
+
+ All correspondence regarding this document should be sent to the
+ following addresses:
+
+ Ranjith Mukundan
+ Wipro Technologies
+ 72, Electronics City
+ Hosur Main Road
+ Bangalore 560100
+ India
+
+ Phone: +91-80-51195893
+ EMail: ranjith.mukundan@wipro.com
+
+
+ Ken Morneault
+ Cisco Systems Inc.
+ 13615 Dulles Technology Drive
+ Herndon, VA. 20171
+ USA
+
+ Phone: +1-703-484-3323
+ EMail: kmorneau@cisco.com
+
+
+ Narsimuloo Mangalpally
+ Nortel Networks
+ 250 Sidney Street
+ Belleville, Ontario K8P 3Z3
+ Canada
+
+ Phone: +1-613-967-5034
+ EMail: narsim@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 14]
+
+RFC 4129 DPNSS/DASS 2 Extensions to the IUA Protocol August 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2005).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Mukundan, et al. Standards Track [Page 15]
+