Request for Comments: 3807 N. Khanchandani
Updates: 3057 S. Rao
Category: Standards Track Nortel Networks
June 2004
V5.2-User Adaptation Layer (V5UA)
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 (2004).
Abstract
This document defines a mechanism for the backhauling of V5.2
messages over IP using the Stream Control Transmission Protocol
(SCTP). This protocol may be used between a Signaling Gateway (SG)
and a Media Gateway controller (MGC). It is assumed that the SG
receives V5.2 signaling over a standard V5.2 interface.
This document builds on the ISDN User Adaptation Layer Protocol (RFC
3057). It defines all necessary extensions to the IUA Protocol
needed for the V5UA protocol implementation.
Table of Contents
1. Introduction ................................................. 2
1.1. Scope .................................................. 3
1.2. Terminology ............................................ 3
1.3. V5.2 Overview .......................................... 5
1.4. Distribution of responsibilities between MGC and SG .... 7
1.5. Client/Server Model .................................... 7
1.6. Addition to boundary primitives ........................ 7
1.6.1. V5 specific boundary primitives ................ 7
2. Conventions .................................................. 9
3. SCTP Stream Management ....................................... 10
4. Proposed V5.2 Backhaul Architecture .......................... 10
4.1. V5UA Message Header .................................... 11
4.2. V5 Naming Conventions for Interface Identifier ......... 12
4.3. V5 Additions to IUA Boundary Primitives ................ 13
4.4. Link Status Messages ................................... 14
4.5. Sa-Bit Messages ........................................ 16
4.6. Error Indication Message ............................... 17
5. Procedures ................................................... 18
5.1. V5 Layer 1 failure ..................................... 18
5.2. Loss of V5UA peer ...................................... 19
5.3. C-channel overload on SG ............................... 19
6. Examples ..................................................... 20
6.1. Link Identification Procedure (successful) ............. 20
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SCTP Payload Protocol Identifier ....................... 21
8.2. V5UA Port Number ....................................... 22
9. Acknowledgements ............................................. 22
10. References ................................................... 22
10.1. Normative References ................................... 22
10.2. Informative References ................................. 23
11. Authors’ Addresses ........................................... 23
12. Full Copyright Statement ..................................... 24
1. Introduction
This document describes a method of implementing V5.2 backhaul
messaging over IP using a modified version of the ISDN User
Adaptation Layer Protocol (IUAP) [1]. V5UA builds on top of IUA,
defining the necessary extensions to IUA for a V5.2 implementation.
Since V5UA is meant to be an extension to IUAP, everything defined in
[1] is also valid for V5UA unless otherwise specified in this
document.
This document does not describe the V5 standard itself. The V5
protocol is defined by ETSI standards [2,3]. Any description of the
V5 protocol in this document is meant to make the text easier to
understand.
1.1. Scope
There is a need for Switched Circuit Network (SCN) signaling protocol
delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway
Controller (MGC), analogous to the implementation of the ISDN Q.921
User Adaptation Layer (IUA) as described in [1].
This document supports analog telephone access, ISDN basic rate
access and ISDN Primary rate access over a V5.2 interface.
Since the V5.2 Layer 2, and especially Layer 3, differs from the
Q.921 [4] and Q.931 Adaptation layer, the IUA standard must be
extended to fulfil the needs for supporting V5.2.
1.2. Terminology
Bearer Channel Connection (BCC) protocol - A protocol which allows
the Local Exchange (LE) to instruct the Access Network (AN) to
allocate bearer channels, either singularly 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 may be
more than one C-path of the same information type, each allocated
to a different logical C-channel.
Envelope Function Address (EFA) - 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
CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191
Layer 1 Functional State Machine (L1 FSM) - Functional State Machine
in V5 System Management that tracks and controls the states of the
physical E1 links on the interface.
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 2048 kbit/s link which
together make up a V5.2 interface.
Multi-Slot - A group of more than one 64kbit/s channels providing
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 2048 kbit/s (E1) 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 2048 kbit/s (E1) 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.
V5 Link - A 2048 kbits/s E1 (PCM30) link used on a V5 interface. A
V5 interface may use up to 16 V5 links.
1.3. V5.2 Overview
V5.2 is an industry standard ETSI interface (reference ETS 300 347-1
[3]) defined between a Local Exchange (LE) and an Access Network (AN)
providing access to the following types:
- Analog telephone access
- ISDN Basic rate access
- ISDN Primary Rate access
- Other analog or digital accesses for semi-permanent connections
without associated outband signaling information
The original V5 specification (V5.1 [2]) uses 2048 kbps links in a
non-concentrating fashion. In contrast, V5.2 may use up to 16 such
interface links and supports concentration.
---------- ---------- o--o
| | E1 | |------- /
| |--------------| | --
| LE | E1 | AN |
| |--------------| | o--o
| | | |------- /
---------- ---------- --
The 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 that exchange data between the
V5.2 protocol peer entities, as well as transfer the ISDN BRI
D-channel messages between the terminals and the LE. A logical
communication path between two peer entities for one protocol 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)
- 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 bearer
channels, the V5.2 protocol has several additions:
- A bearer channel connection protocol establishes and
disestablishes bearer connections on demand, as determined by
the signaling information, under the control of the Local
Exchange.
- A link control protocol is defined for multi-link management to
control link identification, link blocking and link failure
conditions.
- A protection protocol, operating on two separate V5 data links
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:
Layer 2:
- LAPV5-EF
- LAPV5-DL
Layer 3:
- V5-Link Control
- V5-BCC
- V5-PSTN
- V5-Control
- V5-Protection
1.4. Distribution of responsibilities between MGC and SG
In the V5UA backhaul architecture, the V5 protocol entities SHALL be
distributed over SG and MGC as shown below.
MGC SG
+------------+ +-------+-------+
| Lnk Cntrl | | | |
+------------+ | | |
| Cntrl | | | |
+------------+ V5UA | | | V5 +------+
| BCC | <--------> | LAPV5 | LAPV5 | <----> | AN |
+------------+ | -DL | -EF | +------+
| PSTN | | | |
+------------+ | | |
| Protection | | | |
+------------+ +-------+-------+
V5 System Management SHALL be located on the MGC. The V5 L1
Functional State Machine (FSM) SHALL be located on the SG.
Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the
MGC.
1.5. Client/Server Model
The Client/Server Model for V5UA shall follow the model as defined
for IUAP.
The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for
V5UA is 5675.
1.6. Addition to boundary primitives
1.6.1. V5 specific boundary primitives
Extending IUAP to V5UA to support V5.2 backhaul requires the
introduction of new boundary primitives for the Q.921/Q.931 boundary,
in accordance with the definitions in the V5 standards.
V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the
DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA
primitive is used for the transportation of both V5 Layer 3 messages
and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only
used for V5 ISDN messages and is used and defined as described for
IUAP.
In the V5 standards, V5 system management is responsible for
establishing and releasing data links. Therefore, for V5UA the DL-
Establish and DL-Release primitives defined in IUAP are replaced by
new primitives between system management and the data link layer in
accordance with the definitions in [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.
In contrast to ISDN, the V5 standards demand that V5.2 system
management interacts directly with V5.2 layer 1. Since V5.2 Layer 1
(including the L1 FSM) and parts of V5 system management are
physically separated in a V5 backhaul scenario, V5UA must support
some services for the communication between these two entities.
Specifically, these services include an indication of the status of a
specific link, and messages to support the link identification
procedure defined by the V5 standards.
The new primitive are defined as shown below:
MPH-LINK STATUS START REPORTING
The MPH-LINK STATUS START REPORTING primitive is used by V5 system
management to request that a link be brought into service for use in
a V5 interface. On reception of this message, the L1 FSM on the SG
SHALL start reporting the status of the V5 link to the MGC. This
primitive is used similarly to the MPH-proceed primitive defined by
V5.2, but it has a more extended meaning than MPH-proceed.
MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system
management to request that a link be taken out of service on a V5
interface. On reception of this message, L1 FSM on the SG SHALL stop
reporting the status of the V5 link to the GWC. This primitive is
used similarly to the MPH-stop primitive defined by V5.2, but it has
a more extended meaning than MPH-stop.
MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the
Signaling Gateway to report the status (operational/non-operational)
of a V5 link to V5 system management. This primitive is equivalent
to the MPH-AI and MPH-DI primitives in V5.2.
MPH-SA-BIT SET
The MPH-SA-BIT SET primitive is used by system management to request
that the L1 FSM in the SG sets or resets the value of a specified Sa
bit on the requested link. The SG uses it to report the successful
setting or resetting of this bit back to system management. For V5,
this message is used for the V5 specific Link Identification
procedure to set/reset the value of the Sa7 bit, or to confirm the
successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is
equivalent to the MPH-ID and MPH-NOR primitives in V5.2.
MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS primitives are used by system management in the
MGC to request that the L1 FSM in the SG reports the status of a
specified Sa bit on the requested link. The SG uses it to report
(indicate) the status of this bit back to system management. For V5,
these messages are used for the V5 specific Link identification
procedure to request or report the status of the Sa7 bit. This is
equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2.
Due to the separation of V5 System Management and V5 Layer1/Layer2 in
the V5UA backhaul architecture, it may be necessary to report error
conditions of the SG’s V5 stack to V5 System Management. For this
purpose, a new primitive is defined:
MDL-ERROR INDICATION
The MDL-ERROR INDICATION primitive is used to indicate an error
condition to V5 System Management. The only valid reason for this
primitive is ’Overload’, indicating an overload condition of the
C-channel on the SG. This reason is not defined in the V5/Q.921
standards.
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
they appear in this document, are to be interpreted as described in
[7].
3. SCTP Stream Management
A single SCTP stream SHOULD be used for grouping all of the following
protocols together: BCC, Link Control, Control and PSTN protocol on a
specific C-channel. A separate SCTP stream SHOULD be used for the
Protection protocol on a specific C-channel. One SCTP stream SHOULD
be used for all ISDN user ports on a specific C-channel. One single
stream SHOULD NOT be used to carry data of more than one C-channel.
In addition, one separate SCTP stream SHOULD be used for all MPH
(link related) messages.
4. Proposed V5.2 Backhaul Architecture
****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC *
****** ****** *******
+-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
Figure 1: V5.2 Backhaul Architecture
AN - Access Network
NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol
4.1. V5UA Message Header
The original IUA message header must be modified for V5UA. The
original header for the integer formatted Interface Identifier is
shown 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 (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Original IUA Message Header
V5UA extends the IUA Message Header by including the Envelope
Function Address (EFA) in the Spare field. The V5UA format for the
integer formatted Interface Identifier is shown 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 (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x81) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | EFA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: V5UA Message Header (Integer-based Interface identifier)
The EFA is defined by the V5 standard. It 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