| draft-rao-sigtran-v5ua-01 Description: Request For Comments
You can download source copies of the file as follows:
Listed below is the contents of file draft-rao-sigtran-v5ua-01.txt.
Internet Engineering Task Force Sanjay Rao
Neeraj Khanchandani
Fahir Ergincan
Eva Weilandt
Anil Vydyam
Ranjith Mukundan
Narsimuloo Mangalpally
Internet Draft Nortel Networks
Expires in 6 months November 2000
V5.2 and DPNSS/DASS 2 extensions to the IUA protocol
<draft-rao-sigtran-v5ua-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
1. Abstract
This document defines a mechanism for backhauling of V5.2, DPNSS and
DASS 2 messages over IP by extending the ISDN User Adaptation Layer
Protocol (<draft-ietf-sigtran-iua-09.txt>). The document aims to
become an Appendix to IUA and to be the base for V5.2 and DUA
(DPNSS/DASS 2 User Adaptation layer) implementation.
Table of Contents
1.0 Introduction ......................................... 2
2.0 V5UA ................................................. 2
Rao, Khanchandani, Ergincan, Weilandt, [page 1]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
2.1.1 Scope .............................................. 2
2.1.2 Terminology ........................................ 3
2.1.3 V5.2 Overview ...................................... 4
2.1.4 Addition to boundary primitives .................... 6
2.1.4.1 V5 specific boundary primitives .................. 6
2.2.0 Proposed V5.2 Backhaul Architecture ................ 7
2.2.1 IUA Message Header for V5.2 ........................ 8
2.2.2 V5 Additions to IUA Boundaries ..................... 9
2.2.3 V5 Layer 1 Failure Message ......................... 9
3.0 DUA .................................................. 9
3.1.1 Scope .............................................. 10
3.1.2 Terminology ........................................ 10
3.1.3 DPNSS Overview ..................................... 10
3.1.4 Proposed DPNSS Backhaul Architecture ............... 10
3.2.0 Changes from IUA ................................... 11
3.2.1 Message Header ..................................... 12
3.2.2 Adaptation Layer Identifier ........................ 13
3.2.3 Unit Data Message .................................. 13
3.2.4 Status Message ..................................... 13
3.2.5 Error Message ...................................... 14
3.3.0 IANA Considerations ................................ 14
3.4.0 Message Sequence in DUA ............................ 15
3.4.1 Resetting of single DLC ............................ 15
3.4.2 Resetting all DLCs in a link ....................... 15
3.4.3 Information Transfer on a DLC ...................... 15
3.4.4 Link Takedown(Single DLC) .......................... 16
3.4.5 Link Takedown(All DLCs) ............................ 16
3.4.6 Getting link Status ................................ 16
3.4.7 Error conditions ................................... 16
3.4.8 Glossary of Terms .................................. 16
4.0 References ........................................... 17
5.0 Author's Addresses ................................... 17
5.1 V5UA Authors ......................................... 17
5.2 DUA Authors .......................................... 18
1.0 Introduction
This document describes a method of implementing V5.2 & DPNSS/DASS2
backhaul messaging over IP using a modified version of the ISDN
User Adaptation Protocol (IUAP). This document aims to
become an Appendix to IUA and to be the base for the "appli-
cation guide".
2.0 V5UA
2.1.1 Scope
Rao, Khanchandani, Ergincan, Weilandt, [page 2]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
There is a need for a V5.2 backhaul to meet the following
access types:
- Analog telephone access
- ISDN Basic rate access
- ISDN Primary Rate access (V5.2)
- Other analog or digital accesses for semi-permanent
connections without associated outband signaling
information.
2.1.2 Terminology
Bearer Channel Connection (BCC) protocol - A protocol which
allows the LE to instruct the AN to allocate bearer
channels, either singly or in multiples, on demand.
Communication channel (C-channel) - A 64 kbit/s time slot on
a V5.2 interface provisioned to carry communication
paths.
Communication path (C-path) - Any one of the following
information types:
- The layer 2 data link carrying the Control protocol
- The layer 2 data link carrying the Link Control protocol
- The layer 2 data link carrying the PSTN signaling
- Each of the layer 2 data links carrying the protection
protocol
- The layer 2 data link carrying the BCC protocol
- All the ISDN Ds-type data from one or more user ports
- All the ISDN p-type data from one or more user ports
- All the ISDN t-type data from one or more user ports
Note: This definition includes the possibility that
there is more than one C-path of the same information
Rao, Khanchandani, Ergincan, Weilandt, [page 3]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
type, each allocated to a different logical C-channel.
Logical Communication channel (Logical C-channel) - A group
of one or more C-paths, all of different types, but
excluding the C-path for the protection protocol.
Multi-link - A collection of more than one 2.048 kbit/s link
which together make up a V5.2 interface.
Multi-Slot - A group of more than one 64kbit/s channels pro-
viding 8Khz and time slot sequence integrity, generally
used together within an ISDN Primary Rate Access
(ISDN-PRA) user port, in order to supply a higher bit-
rate service.
Physical Communication Channel (Physical C-channel) - A
64kbit/s time slot on a V5.2 interface which has been
assigned for carrying logical C-channels. A physical
C-channel may not be used for carrying bearer channels.
Primary Link - A 2.048 kbit/s link in a multi-link V5.2
interface whose physical C-channel in time slot 16 carries a C-
path for the protection protocol and, on V5.2
initialization, also the C-path for the control protocol, link
control protocol, and the BCC protocol. Other
C-paths may also be carried in the time slot 16.
Secondary Link - A 2.048 kbit/s link in a multi-link V5.2
interface whose time slot 16 carries a C-path for the
protection protocol, and, on V5.2 initialization, acts
as the standby C-channel for the control protocol, link
control protocol, and BCC protocol and any other C-
paths initially carried in time slot 16 of the primary
link.
2.1.3 V5.2 Overview
V5.2 is an industry standard ETSI interface (reference ETS
300 347-1) defined between a Local Exchange (LE) and an Access
Network (AN) providing access to the following types:
Rao, Khanchandani, Ergincan, Weilandt, [page 4]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
- Analog telephone access
- ISDN Basic rate access
- ISDN Primary Rate access (V5.2)
- Other analog or digital accesses for semi-permanent
connections without associated outband signaling
information
The original V5 specification uses 2048 kbps links,
V5.2 may use upto 16 such interface links.
---------- ---------- o--o
| | E1 | |------- /
| |--------------| | --
| LE | E1 | AN |
| |--------------| | o--o
| | | |------- /
---------- ---------- --
LE and AN are connected with up to 16 E1 (PCM30) links.
Channels 16, 15 and 31 on any E1 link can be reserved for
data communication between LE and AN. The channels reserved
for data are called "Communication Channels" or "C-
Channels."
The C-Channels are the physical media to exchange data
between the V5.2 protocol peer entities, as well as to
transfer the ISDN BRI D-Ch messages between the terminals
and the LE. A logical communication path between two peer
entities is called a "C-path".
The signaling information in V5.2 are defined as:
- Analog signals are carried by means of the V5 PSTN
protocol (L3)
- ISDN/analog ports are controlled by the V5 Control
protocol (L3)
- ISDN protocol messages are mapped to LAPD frames,
which are carried by means of LAPV5-EF sublayer (L2)
Rao, Khanchandani, Ergincan, Weilandt, [page 5]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
- V5 protocol messages are mapped to LAPV5-DL frames,
which are carried by means of LAPV5-EF sublayer (L2)
In order to support more traffic and dynamic allocation of
links, the V5.2 protocol has several additions:
- A bearer channel connection protocol establishes and
de-establishes bearer connections required on demand,
identified by the signalling information, under the
control of the Local Exchange.
- A link control protocol is defined for the multi-link
management to control link identification, link
blocking and link failure conditions.
- A protection protocol, operated on two separate data
links for security reasons, is defined to manage the
protection switching of communication channels in
case of link failures.
The following protocols are defined for the various protocol
layers:
- LAPV5-EF
- LAPV5-DL
- V5-Link Control
- V5-BCC
- V5-PSTN
- V5-Control
- V5-Protection
2.1.4 Addition to boundary primitives
2.1.4.1 V5 specific boundary primitives
V5.2 introduces new boundary primitives in addition to the
ones defined for the Q.921/Q.931 boundary.
Rao, Khanchandani, Ergincan, Weilandt [page 6]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
This includes new primitives between system management and
the data link layer [2]:
MDL-ESTABLISH
The MDL-Establish primitives are used to request, indicate
and confirm the outcome of the procedures for establishing
multiple frame operation.
MDL-RELEASE
The MDL-Release primitive is used to indicate the outcome of
the procedures for terminating multiple frame operation.
MDL-LAYER_1_FAILURE
The MDL-Layer_1_Failure primitive is used by the system
management to indicate the condition of the physical layer
to the data link layer.
2.2.0 Proposed V5.2 Backhaul Architecture
****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | | IUA| | IUA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
NIF - Nodal Interworking function EP - End Point SCTP -
Stream Control Transmission Protocol IUA - ISDN User Adaptation
Layer Protocol
Rao, Khanchandani, Ergincan, Weilandt, [page 7]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
2.2.1. IUA Message Header for V5.2
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Original IUA Message Header
For the V5 extension of the IUA Message Header, the Envelope
Function Address (EFA) field is included in the last 13 bits
of the Spare field.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | | EFA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 IUA Message Header for V5.2
The EFA identifies a C-path, which is a 13-bit number,
ranging from 0 to 8191 (decimal). An EFA uniquely identifies
one of the five V5.2 protocols, or an ISDN agent attached to
an AN. The following list contains the possible values for
the EFA
Definition Value
---------- ------
ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176
CC_PROTOCOL 8177
BCC_PROTOCOL 8178
Rao, Khanchandani, Ergincan, Weilandt [page 8]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191
2.2.2 V5 Additions to IUA Boundaries
Primitives for the V5 interface are identified by the Message Class
parameter in the Common Message Header for Q.921 user adaptation.
The valid message class for V5 primitives is:
6 Q.921/Q.932 Boundary Primitives Transport
Messages for V5 (QPTMV5)
The boundary primitives that are defined for the Q.921/Q.931
boundary are reused for the V5 messages. The following list
contains the names of the messages valid for V5.2:
Q.921/Q.931 Boundary Primitives Transport Messages
1 Data Request Message
2 Data Indication Message
5 Establish Request
6 Establish Confirm
7 Establish Indication
8 Release Request
9 Release Confirm
10 Release Indication
The following new message is defined for the Q.921/Q.931
boundary for V5 only:
11 Layer 1 Failure Indication
2.2.3 V5 Layer 1 Failure Message
The V5 Layer 1 Failure Message is used by the system manage-
ment to indicate the data link layer that a layer 1 failure
has occured. This primitive is send per protocol on a c-
channel.
The V5 Layer 1 Failure Message contains the common message
header followed by IUA message header. It does not contain
any additional parameters.
3.0 DUA
Rao, Khanchandani, Ergincan, Weilandt [page 9]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
3.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)
- DASS 2 (Digital Access Signaling System No 2)
Unless specifically mentioned the details in this document are
applicable to both DPNSS and DASS2.
3.1.2 Terminology
Data channel (D-channel) - A 64 kbit/s time slot which functions
as a common signaling channel on a 2048 kbits/s interface or a
1544 kbits/s interface which 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 which 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".
3.1.3 DPNSS Overview
DPNSS is an industry standard interface (reference BTNR 188)
defined between a PBX and an Access Network (AN).
DPNSS extends facilities normally only available between
extensions on a single PBX to all extensions on PBXs that are
connected together in a private network. DPNSS was originally
derived from BT's Digital Access Signaling System I (DASS I)
Rao, Khanchandani, Ergincan, Weilandt [page 10]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
enhanced where necessary to meet the private network requirements.
Some of these enhancements were incorporated in DASS 2.
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
Channels 16 on a 2048 kbits/s interface and channel 24 on a
1544 kbits/s interface 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 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".
3.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
3.2.0 Changes from IUA
Rao, Khanchandani, Ergincan, Weilandt, [page 11]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
The following section outlines the differences between DUA and IUA
3.2.1 Message Header
IUA Message header has the format as shown in Figure 2 below.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 IUA Message Header
In DUA header DLCI field has a different format in accordance with
the BTNR 188.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Indicator |0|Channel No.|1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The indicator field is used to determine whether the message is for
a particular DLC or it is applicable for all the DLCs in the
carrier. The possible values of the indicator is mentioned 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.
This indicator value is used only by the Est and Rel 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.
Rao, Khanchandani, Ergincan, Weilandt, [page 12]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2, DPNSS/DASS 2 November 2000
For channel number 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.
3.2.2 Adaptation Layer Identifier
Adaptation Layer Identifier string must be set to "DUA" for the DUA
applications.
3.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.
3.2.4 Status Message
IUA MIUA-TEI STATUS Message has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In DUA this will be known as the Status message and will have the
following format.
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
DLC +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 | | | | | | | | | | | | | | | | |16
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
17 | | | | | | | | | | | | | | | | |32
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
33 | | | | | | | | | | | | | | | | |48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
49 | | | | | | | | | | | | | | | | |64
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
These 4 words carry the status of DLCs using two bits for each DLC.
These are the possible values for these two bits.
Value Description
00 Out Of Service
01 Reset Attempted
10 Reset Completed
11 Information Transfer
Rao, Khanchandani, Ergincan, Weilandt, [page 13]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
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 only 2 words instead of 4 for DPNSS.
For DASS 2 the value 00 (Out Of Service) is invalid since the DASS 2
DLC does not have this state.
3.2.5 Error Message
The ERR message is sent when an invalid value 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 0x1
Invalid Interface Identifier 0x2
Invalid Adaptation Layer Identifier 0x3
Invalid Message Type 0x4
Invalid Stream Identifier 0x5
Unassigned TEI 0x6
Unrecognized SAPI 0x7
Invalid TEI, SAPI combination 0x8
Invalid AS Mode Type 0x9
In DUA the error codes 0x6 to 0x8 are invalid as they are specific
to ISDN.
The following additional error codes are supported in DUA.
Channel Number out of range 0xA
Channel Not configured 0xB
3.3.0 IANA Considerations
A request will be made to IANA to assign a DUA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered:
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.
The User Adaptation peer may use the Payload Protocol Identifier as
Rao, Khanchandani, Ergincan, Weilandt, [page 14]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
a way of determining whether the message is for IUA or DUA.
3.4.0 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.
3.4.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_PHYS,Ind=1)
3.4.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)
<----------- Stat Req
Stat Res -----------> (Mark DLC status
based on status bits)
3.4.3 Information Transfer on a DLC
Rao,Khanchandani,Ergincan, Weilandt [page 15]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
PBX SG MGC
<----------- UI(C) <----------- Data Req
UI(C)-----------> Data Ind ----------->
3.4.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)
3.4.5 Link Takedown(All DLCs)
PBX SG MGC
(For DPNSS, mark all DLCs as OOS) <----------- Rel Req
(For DASSII, mark all DLCs as RA) (RELEASE_MGMT,Ind=0)
Rel Cfm ---------->
(Ind=0)
3.4.6 Getting link Status
PBX SG MGC
<----------- Stat Req
Stat Res -----------> (Mark DLC status
based on status bits)
3.4.7 Error conditions
PBX SG MGC
Invalid Message -----------
Est/Rel/Data/Stat Req
Error Ind ----------->
(Error Code)
3.4.8 Glossary of terms
Real channel : The signalling channel with associated
traffic channel (TS).
Virtual channel: The signalling channel with no
associated traffic channel.
NT1 : Retransmission period of 500msec.
NT2 : Recommended value is 64.
Rao, Khanchandani, Ergincan, Weilandt [page 16]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
4.0 References
[1] ISDN Q.921-User Adaptation Layer <draft-ietf-sigtran-
iua-09.txt>
[2] EN 300 324-1 (1999): V interfaces at the digital Local
Exchange (LE); V5.1 interface for the support of Access
Network (AN); Part 1: V5.1 interface specification.
[3] EN 300 347-1 (1999): V interfaces at the digital Local
Exchange (LE); V5.2 interface for the support of Access
Network (AN); Part 1: V5.2 interface specification.
[4] ETS 300 125 (1991) : DSS1 protocol; User-Network inter-
face data link layer specification; (Standard is based
on : ITU Q.920, Q.921).
[5] ETS 300 166 (08/1993) : Transmission and Multiplexing;
Physical and electrical characteristic of hierarchical
digital interfaces (Standard is based on G.703).
[6] ETS 300 167 (08/1993) : Transmission and Multiplexing;
Functional characteristic of 2048 kbits/s interfaces
(Standard is based on G.704, G.706).
[7] BTNR (British Telecom Network Requirements) 188 Issue 6
Digital Private Network Signaling System 1
[8] BTNR (British Telecom Network Requirements) 190 Issue 2
Digital Access Signaling System No 2
5.0 Authors' Addresses
5.1 V5UA Authors
Sanjay Rao Tel +1-919-991-2251
Nortel Networks Email rsanjay@nortelnetworks.com
35 Davis Drive
Research Triangle Park, NC 27709
USA
Neeraj Khanchandani Tel +1-919-991-2274
Nortel Networks Email neerajk@nortelnetworks.com
35 Davis Drive
Research Triangle Park, NC 27709
Rao, Khanchandani, Ergincan, Weilandt, [page 17]
Vydyam, Mukundan, Mangalpally
Internet Draft V5.2 & DPNSS/DASS 2 November 2000
USA
Dr. Fahir Ergincan Tel +49 7545 96 8844
Nortel-Dasa Network Systems Email fahir@nortelnetworks.com
88039 Friedrichshafen
Germany
Dr. Eva Weilandt Tel +49 7545 96 7267
Nortel-Dasa Network Systems Email eva.weilandt@nortelnetworks.com
88039 Friedrichshafen
Germany
5.2 DUA Authors
Authors : Anil Vydyam, Ranjith Mukundan and Narsimuloo Mangalpally
All correspondence regarding DUA should be sent to
the following address :
Mick Dragon Tel. +44 1628 43 4388
Nortel Networks plc Email. mdragon@nortelnetworks.com
Concorde Road
Maidenhead
Berkshire SL6 4AG
United Kingdom
Rao, Khanchandani, Ergincan, Weilandt, [page 18]
Vydyam, Mukundan, Mangalpally
|
Documentation