Internet Engineering Task Force                  E. Weilandt
INTERNET DRAFT                               N. Khanchandani
                                                      S. Rao
                                             Nortel Networks

Expires in six months                              June 2002                               May 2003

                  V5.2-User Adaptation Layer (V5UA)
                   <draft-ietf-sigtran-v5ua-03.txt>
                   <draft-ietf-sigtran-v5ua-04.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.

Abstract

This document defines a mechanism for backhauling of V5.2 messages
over IP using the Stream control Control Transmission Protocol (SCTP). This
protocol would may be used between a Signaling Gateway (SG) and a Media
Gateway controller (MGC). It is assumed that the SG receives V5.2 sig-
naling over a standard V5.2 interface.

This document aims to build builds on top of the ISDN User Adaptation Layer Protocol
(RFC 3057). It defines all differences necessary extensions to the IUAP IUA Protocol
needed for the V5.2 V5UA protocol implementation.

                     Table of Contents

1. Introduction .................................................    3
  1.1. Scope ....................................................    3
  1.2. Terminology ..............................................    3
  1.3. V5.2 Overview ............................................    5
  1.4. TEI Management for BRI over V5UA ......................... 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 .......................................    9
4. Proposed V5.2 Backhaul Architecture ..........................    9   10
  4.1. V5UA Message Header ......................................   10
  4.2. V5 Naming Conventions for Interface Identifier ...........   11
  4.3. V5 Additions to IUA Boundary Primitives ..................   12
  4.4. Link Status Messages .....................................   13
  4.5. Sa-Bit Messages ..........................................   15
  4.6. Error Indication Message .................................   16
5. Procedures ...................................................   17
  5.1. V5 Layer 1 failure .......................................   17
  5.2. Loss of V5UA peer ........................................   17   18
  5.3. C-channel overload on SG .................................   18
6. Examples .....................................................   18
  6.1. Link Identification Procedure (successful) ...............   18
7. Security Considerations ......................................   19   20
8. IANA Considerations ..........................................   19   20
  8.1. SCTP Payload Protocol Identifier .........................   19   20
  8.2. V5UA Port Number .........................................   20
9. Acknowledgements .............................................   20
10. References ..................................................   20
  10.1. Normative References ....................................   20
  10.2. Informative References ..................................   20   21
11. Author's Addresses ..........................................   21

1.  Introduction 1. Introduction

This document describes a method of implementing V5.2 backhaul messag-
ing over IP using a modified version of the ISDN User Adaption Adaptation Layer
Protocol (IUAP) [1]. The V5UA builds on top of IUA IUA, defining the neces-
sary 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 specified otherwise in this docu-
ment.

This document does not describe the V5 standard itself. The V5 proto-
col is defined by ETSI standards [2,3]. Any description of the V5 pro-
tocol 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 Con-
troller (MGC) analog (MGC), analogous to the implementation of the ISDN Q.921 User
Adaption
Adaptation Layer (IUA) as described in [1].

This draft supports analog telephone access, ISDN basic rate access
and ISDN Primary rate access over a V5.2 interface.

Since the V5.2 Layer 2 2, and specifically especially Layer 3 3, differs from the Q.921
and Q.931 Adaption Adaptation layer, the IUA standard needs to must be extended to
fulfil ful-
fil 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 allo-
     cate 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 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 car-
     rying 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. pro-
     tocol. 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 inter-
     face whose time slot 16 carries a C-path for the protection pro-
     tocol, 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 "Communi-
cation

"Communication Channels" or "C-channels."

The C-channels are the physical media to that exchange data between the
V5.2 protocol peer entities, as well as to transfer the ISDN BRI D-
channel messages between the terminals and the LE. A logical communi-
cation 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 de-
       establishes disestab-
       lishes bearer connections required on demand, identified as determined by the signaling sig-
       naling information, under the control of the Local Exchange.

     - A link control protocol is defined for the multi-link manage-
       ment management to
       control link identification, link blocking and link failure
       conditions.

     - A protection protocol, operated operating on two separate V5 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:

 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, architectrue, the protocols are 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 |            |       |       |
  +------------+            +-------+-------+

1.4.  TEI

V5 System Management for BRI over V5UA 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 V5 shall V5UA SHALL be located on the
MGC.

1.5.  Client/Server Model

The Client/Server Model for V5UA should shall follow the model as defined for
IUAP.

The SCTP (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 introduc-
tion of new boun-
dary boundary primitives for the Q.921/Q.931 boundary boundary, in
accordance with the definitions in V5.2.

V5.2 reuses 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 primi-
tive is used for transport 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.

The responsibility to establish and release data links is shifted to

In the V5 standards, V5 system management. Therefore management is responsible for

establishing and releasing data links. Therefore, for V5UA the DL-Establish DL-
Establish and DL-Release primi-
tives 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 opera-
tion.

MDL-RELEASE

The MDL-Release primitive is used to indicate the outcome of the pro-
cedures for terminating multiple frame operation.

In contrary contrast to ISDN, the V5 standards demand that V5.2 system manage-
ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ-
ing the L1 FSM) and parts of V5 system management may be are physically
separated in a V5 backhaul scenario, V5UA needs to must support some ser-
vices services
for the communication between these two entities. Specifically Specifically, these
services include an indication of the status of a specific link, and mes-
sages
messages to support the link identification procedure. 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 to take the that a link in be brought into service for use on in a
V5 interface. On reception of this message message, the L1 FSM on the SG shall also SHALL
start reporting the status of the V5 link to the GWC.

MPH-LINK STATUS STOP REPORTING

The MPH-LINK STATUS MGC.  This primitive
is used similar 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 to take the that a link is taken out of service for use on a V5
interface. On reception of this message L1 FSM on the SG shall also SHALL stop
reporting the status of the V5 link to the GWC.  This primitive is
used similar 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 Sig-
naling 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, or link. The SG uses it to report the successful
setting or resetting of this bit back to system management. For V5
this message
will be 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 MPH-NOR primitves in V5.2.

MPH-SA-BIT STATUS

The MPH-SA-BIT STATUS primitives are used between by system management in the
MGC and to request that the L1 FSM in the SG to request reporting of reports the status of a
specified Sa bit on the requested link, or link. The SG uses it to report
(indicate) the status of this bit back to system management.  For V5
these messages
will be are used for the V5 specific Link identification procedure pro-
cedure to request or report the status of the Sa7 bit. This is
equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitive primitives in V5.2.

Due to the separation of V5 System Management and V5 Layer1/Layer2, 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 condi-
tion to V5 System Management.  The only valid reason for this primi-
tive 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 describd in [8].

3.  SCTP Stream Management

It is recommended that one

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.  It is recommended
to use a  A separate SCTP stream SHOULD be used for the
Protection protocol on a specific C-channel. It is also recommended to use one One SCTP stream SHOULD be
used for all ISDN user ports on a specific C-channel. One single
stream should not SHOULD NOT be used to carry data of more than one C-channel.

In addition, it is recommended that 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 needs to must be modified for V5. V5UA. The ori-
ginal origi-
nal 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

For the V5 extension of

V5UA extends the IUA Message Header, Header by including the Envelope Function
Address (EFA) field is included in the Spare field. Below the The V5UA format for the integer formatted for-
matted Interface Identifier is shown: 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               |                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 attached
to an AN. The following list con-
tains contains the possible values for the EFA: EFA
as defined by V5:

        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

For MPH messages for which do not use DLCI and EFA are not used, EFA, SAPI, TEI and EFA shall
SHALL be set to ZERO and shall SHALL be ignored by the receiver. For all
other messages the DLCI shall SHALL be set as defined in the V5.2 standard
[2].

The Interface Identifier SHALL follow the naming conventions for the
Interface Identifier as defined below.

4.2.  V5 Naming Conventions for Interface Identifier

The V5 standard demands that V5 System Management keeps track of the
states of all links on a V5 interface. To perform tasks like protec-
tion switching and bearer channel allocation on the V5 links, it is
neccessary that system management has the full picture of the signal-
ing and bearer channels located on each link.

The IUA protocol identifies C-channels by endpoints without a defined
association with a specific link. Since no naming convention exists,
there is no guarantee that a C-channel is actually located at the link
it claims to be. Furthermore the V5 standard requires that the MGC
receives reports of the status of all links, and it defines a link
identification procedure to ensure that AN and LE are referencing the
same link when they address a link with a Link Control Protocol mes-
sage.

It would clearly be against the concept of V5.2 if there was no clear
association between E1 links and channels. To solve this problem a
naming convention MUST be used to ensure this association: for V5UA.

The format of 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Link Identifier                              | Chnl ID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Link Identifier - Identifier for an E1 link on the SG (27 bits). Must MUST
     be unique on the SG. This Link Identifier MUST match the Link
     Identifier used in the Link Management Messages defined later in
     this document.

Chnl ID - Channel Identifier (5 bits). This is equal to the time-slot
     number of the addressed time slot. Possible values are 15, 16 and
     31 representing the possible time slots for C-channels on a V5
     interface. For Link Management Messages the Chnl ID must MUST be set
     to 0. All other values are reserved for future use.

The

If used, the text formatted interface identifier shall SHALL be coded as the
hex representation of the integer formatted interface identifier,
written as a variable length string.

4.3.  V5 Additions to IUA Boundary Primitives

Some primitives for the V5 interface boundaries are similar to the
Q.921/Q.931 boundary primitive messages defined in IUA, but they need
to be handled in a different way. Therefore it is neccessary to dis-
tinguish between these two message types by means of the Message Class
parameter.

For all V5 interface boundary primitives, a new Message Class is
introduced:

        9       V5 Boundary Primitives Transport
                Messages (V5PTM)

Similar to IUA, other

Other valid message classes for V5UA V5UA, which are also used by IUA, are:

        0       Management (MGMT) Message
        3       ASP State Maintenance (ASPSM) Messages
        4       ASP Traffic Maintenance (ASPTM) Messages

Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM mes-
sages are:

        1       Data Request Message         (MGC -> SG)
        2       Data Indication Message      (SG -> MGC)
        3       Unit Data Request Message    (MGC -> SG)
        4       Unit Data Indication Message (SG -> MGC)
        5       Establish Request            (MGC -> SG)
        6       Establish Confirm            (SG -> MGC)
        7       Establish Indication         (SG -> MGC)
        8       Release Request              (MGC -> SG)
        9       Release Confirm              (SG -> MGC)
       10       Release Indication           (SG -> MGC)

All these messages are defined similar similarly to the QPTM messages.

In addi-
tion, addition, new boundary primitive messages are defined:

       11       Link Status Start Reporting    (MGC -> SG)
       12       Link Status Stop Reporting     (MGC -> SG)
       13       Link Status Indication         (SG -> MGC)
       14       Sa-Bit Set Request             (MGC -> SG)
       15       Sa-Bit Set Confirm             (SG -> MGC)
       16       Sa-Bit Status Request          (MGC -> SG)
       17       Sa-Bit Status Indication       (SG -> MGC)
       18       Error Indication               (SG -> MGC)

4.4.  Link Status Messages (Start Reporting, Stop Reporting, Indica-
tion)

The Link Status Messages are used between V5 System Management on the
MGC and the L1 FSM on the SG to track the status of a particular E1
link. This is required regardless of whether or not the E1 link car-
ries carries C-channels.

All Link Status Messages contain the V5UA Message Header. The Link
Identifier portion of the Interface Identifier identifies the physical
link on the SG addressed by the message. For all link status messages,
the Chnl ID shall SHALL be set to '0' and shall SHALL be ignored by the receiver.

The integer value used for the Link Identifier is of local signifi-
cance only, and is coordinated between the SG and MGC. It has to MUST be
unique for every V5 link on the SG.

The Link Status Start Report Message is used

As defined by V5 System Management
to request from L1 FSM to start reporting the status of a particular
link, since V5 standards, V5 System Management on the MGC must know the
status of the links on all active V5 interfaces. This message  The Link Status
Start Reporting Message is also an indica-
tion for used by V5 System Management on the SG MGC to
request that this link is located the L1 FSM on the SG starts reporting the status of a now active interface.
particular link.

V5 system management shall SHALL send this Message on interface activation
for all links on the interface. The SG will SHALL respond immediately to
this request with a Link Status Indication message, and it will SHALL then
send a Link Status Indication message on all subsequent changes of the
link status. Since the SG has no other way to determine whether a link
is on an active interface or not, this message shall SHALL always be sent on
interface startup.

If the L1 FSM in the SG receives a Link Status Start Reporting Message
for a link that is already active (the link status is reported to Sys-
tem Management), the SG SHALL immediately report the actual status of
this link by sending a Link Status Indication Message. The SG SHALL
then proceed with the automatic link status reporting as described
above.

To stop this reporting of the status of a link, e.g. at interface
deactivation, System Management sends a Link Status Stop Reporting
Message to the L1 FSM. The SG will then immediately stop reporting the
status of the particular link and will assume the link to be out of
service. It must not MUST NOT respond in any way to this message.

Since there is no other way for the SG to know that an interface is
deactivated, this message shall SHALL be sent on interface deactivation for
all links on the interface. On reception of this message, the SG may SHALL
take L2 down on this link.

If the L1 FSM in the SG receives a Link Status Stop Reporting Message
for a link that is not active (the link status is not reported to Sys-
tem Management), the SG SHALL ignore the message.

The Link Status Start/Stop Report Reporting Messages contain the common message mes-
sage header followed by the V5UA message header. They do not contain
any
addition additional parameters.

The Link Status Indication Message is used by L1 FSM in the SG in
response to a Link Status Request Start Reporting Message to indicate the
status of the particular link. After a Link Status Start Report Reporting
Message has been received by the L1 FSM, it will SHALL automatically send a
Link Status Indi-
cation Indication Message every time the status of the particular
link changes. It will SHALL not stop this reporting until it receives a
Link Status Stop Report Message from System Management.

The Link Status Indication Message contains the common message header
followed by the V5UA message header. In addition it contains the fol-
lowing link status parameter:

   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 (0x11)           |             Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Link Status                                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The valid values for Link Status are shown in the following table:

     Define          Value      Description

     OPERATIONAL      0x0       Link is in operation operational
     NON-OPERATIONAL  0x1       Link is not in operation operational

4.5.  Sa-Bit Messages (Set Request, Set Confirm, Status Request,
Status Indication)

The Sa-Bit Messages are used between V5 System Management in the MGC
and the L1 FSM in the SG to set and read the status of Sa bits on the
E1 links. For V5 it is only required to set and read the status of the
Sa7 bit that is used in for the V5 defined Link Identification procedure. procedure as
described by the V5 standards [3].

All Sa-Bit Messages SHALL contain the V5UA message header. The Link Identif-
ier
Identifier portion of the Interface Identifier identifies the physical
link on the SG addressed by the message. For all link status messages,
the Chnl ID shall SHALL be set to '0' and shall SHALL be ignored by the receiver.

The Link Identifier must MUST be the same as used in the Interface Identif-
ier to identify on which link a C-channel is located.

The Sa-Bit Set Request message is used to set the value of the speci-
fied Sa-Bit on the defined link. For V5, the The value of the Sa7 bit in normal
operation is ONE. For the Link Identification procedure, it is set to
ZERO.

The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO
corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set Request
message for the Sa7 bit with Bit Value ONE corresponds to the V5
defined primitive MPH-NOR.

The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Con-
firm message when the setting of the bit is complete. This message
does not correspond to a V5 defined primitive.

The Sa-Bit Status Request message is used by system management to
request the status of the specified Sa-Bit on the defined link from L1
FSM. The Sa-Bit Status Request message for the Sa7 bit corresponds to
the V5 defined primitive MPH-IDR.

L1 FSM answers this the Sa-Bit Status request message by a Sa-Bit Status
Indication message in which the current setting of the bit will be
reported. The Sa-Bit Status Indication message for the Sa7 bit with
Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The
Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE
corresponds to the V5 defined primitive MPH-Elg.

All Sa-Bit Messages contain the following additional parameter:

    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           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             BIT ID             |        Bit Value             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The valid values for Bit Value are shown in the following table:

     Define          Value      Description

     ZERO             0x0       Bit is set to value ZERO
     ONE              0x1       Bit is set to value ONE

The valid value for BIT ID is shown in the following table:

     Define          Value      Description

     Sa7              0x7       Addresses the Sa7 bit

There are no other valid values for V5UA. All other values are
reserved for future use.

For the Sa-Bit Status Request and Set Confirm messages, the BIT Value
should
SHALL be set to '0' by the sender and should SHALL be ignored by the
receiver.

4.6.  Error Indication Message

The Error Indication Message is used between the V5 stack on the SG
and the V5 System Management in the MGC to indicate an error condition
of
at the SG.

The only valid reason for the Error Indication Message is Overload.
The SG shall SHOULD issue such an Error Indication with reason Overload for
a C-channel in case if it is not able to process all Layer 3 messages on this
C-channel in a timely manner (overload condition of the C-
channel). C-channel).

The Error Indication message SHALL contain the V5UA message header.

The Interface Identifiers Identifier indicates the affected C-channel. SAPI, TEI
and EFA shall SHALL be set to '0' and shall SHALL be ignored by the receiver.

The Error Indication message contain contains the following additional parame-
ter:

    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 (0x13)           |             Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Error Reason                                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The valid values for Error Reason are shown in the following table:

     Define          Value      Description

     OVERLOAD         0x1       C-channel is in overload state

There are no other valid values for V5UA. All other values are
reserved for future use.

5.  Procedures

5.1.  V5 Layer 1 failure

The normal way to handle a V5 Layer 1 failure is described in the V5
standards[2,3] as follows:

     - The L1 FSM detects the V5 Layer 1 failure. It reports this to
       V5 System management by sending a MPH-DI primitive for the
       affected link.

     - V5 System management notifies V5 Layer 2 of the V5 Layer 1
       outage by sending a MPH-Layer_1 Failure Ind primitive.

Since V5 Layer1/2 and V5 System Management are no longer co-located in
the backhaul architecture, it does not make sense to notify V5 Layer 2
about V5 Layer 1 failure via V5 system management. Instead V5 Layer 2 shall
SHALL be notified directly by V5 Layer 1 on the SG. V5 Layer 1 shall still SHALL
report the outage to V5 system management by sending a Link Status
Indication message with status NON-OPERATIONAL, corresponding to an
MPH-DI primitive, but primitive as defined by the V5.2 standard. V5 system management shall not
SHALL NOT send a an MPH-Layer_1 Failure Ind primi-
tive primitive to V5 Layer 2. 2 in
response to this message.

5.2.  Loss of V5UA peer

If SCTP failure is detected or the heartbeat is lost, the following
procedure shall SHALL be performed:

When loss of V5UA peer is reported to the V5UA layer, the ASP shall SHALL
behave as if it had received a Link Status Indication (non-
operational) for all links on this SG.

The ASP shall SHALL attempt to reestablish the connection continuously. When
the connection is reestablished, the ASP shall SHALL send a Link Status
Start Reporting message to the SG for all links on active V5 inter-
faces on the SG.

An example for the message flow in case of for reestablishment of the con-
nection connection
is shown below for one active link on the SG:

     ASP                                               SG

      |                                                 |
      | -------- Link Status Start Reporting ---------> |
      |                                                 |
      | <------ Link Status Ind (operational) --------- |
      |                                                 |

In case

If the association can be reestablished before the V5UA layer
gets notified, is noti-
fied, communication should SHALL proceed as usual and no other action shall SHALL
be taken by the ASP.

5.3.  C-channel overload on SG

If the SG detects an overload condition on a C-channel, it shall indi-
cate SHOULD
indicate this by sending an Error Indication message, reason Overload
to the MGC. The MGC may SHOULD then take appropriate actions to clear this over-
load
overload condition.

The SG shall resent SHALL resend the Error Indication message with reason Overload
as long as the overload condition persist. A recommended An interval of 120 seconds
for
resent resend of this message is 120 seconds. RECOMMENDED.

6.  Examples

6.1.  Link Identification Procedure (successful)

The Link Identification Procedures themselves are described by the
V5.2 standard [3].

A message flow example for an LE initiated Link Identification pro-
cedure

procedure over V5UA is shown below. An active association between ASP
and SG is established prior to the following messages message flows, and the V5 inter-
face
interface is already activated: in service:

     ASP                                               SG

      |                                                 |
      | ------ Data Request (LnkCtrl: FE-IDReq) ------> |
      | <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- |
      |                                                 |
      | <---- Data Indication (LnkCtrl: FE-IDAck) ----- |
      | ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> |
      |                                                 |
      | ------ Sa-Bit Status Request ( Sa7 ) ---------> |
      | <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- |
      |                                                 |
      | ------- Data Request (LnkCtrl: FE-IDRel) -----> |
      | <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- |
      |                                                 |

The next example again also shows a Link Identification procedure, but this
time initiated by the AN. Again the ASP association and the V5 inter-
face are already in service:

     ASP                                               SG

      |                                                 |
      | <---- Data Indication (LnkCtrl: FE-IDReq) ----- |
      | -- Data Request (LnkCtrl Ack: FE-IDReq) ------> |
      |                                                 |
      | ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> |
      | <--------- Sa-Bit Set Conf (Sa7) -------------- |
      |                                                 |
      | ------- Data Request (LnkCtrl: FE-IDAck) -----> |
      | <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- |
      |                                                 |
      | <---- Data Indication (LnkCtrl: FE-IDRel) ----- |
      | ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> |
      |                                                 |
      | ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> |
      | <----------- Sa-Bit Set Conf (Sa 7) ----------- |
      |                                                 |

7.  Security Considerations

All

The security considerations applicable discussed for IUA shall also be applica-
ble the 'Security Considerations
for V5UA. SIGTRAN Protocols' [7] document apply to this document.

8.  IANA Considerations

8.1.  SCTP Payload Protocol Identifiers

IANA has assigned a V5UA value for the Payload Protocol Identifier in
the SCTP DATA chunk. The following SCTP Payload Protocol identifier is
registered:

     V5UA    "6"

the SCTP Payload Protocol identifier value "6" SHOULD be included in
each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA
protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. 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 a
way of determining additional information about the data being
presented to it by SCTP.

8.2.  V5UA Port Number

IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA.

9.  Acknowledgements

The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme
Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their valu-
able comments and suggestions.

10.  References

10.1.  Normative References

[1]  RFC 3057, "ISDN Q.921-User Adaptation Layer", K. Morneault, S.
     Rengasami, M. Kalla, G. Sidebottom, February 2001

[2]  ETSI 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]  ETSI 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]  ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface
     data link layer specification; (Standard is based on : ITU Q.920,
     Q.921).

[5]  ETSI ETS 300 166 (08/1993) : Transmission and Multiplexing; Phy-
     sical and electrical characteristic of hierarchical digital
     interfaces (Standard is based on G.703).

[6]  ETSI ETS 300 167 (08/1993) : Transmission and Multiplexing; Func-
     tional characteristic of 2048 kbits/s interfaces (Standard is
     based on G.704, G.706).

[7]  J. Loughney, M. Tuexen, J. Pastor-Balbas, 'Security Considera-
     tions for SIGTRAN Protocols', Work in Progress.

10.2.  Informative References

[7]  RFC 2960, "Stream Control Transport Protocol", R. Stewart et al,
     October 2000

[8]  RFC 2119, "Kay "Key words for use in RFCs to Indicate Requirement Lev-
     els", S. Bradner, March 1997

[9]  <draft-rfc-editor-rfc2223bis-02.txt>, "Instructions to Request
     for Comments (RFC) Authors", J.Reynolds, R. Braden, April 2002
     (Work in Progress)

11.  Author's Addresses

Dr. Eva Weilandt                                  Tel +49 7545 96 7267
Nortel Networks Germany          Email eva.weilandt@nortelnetworks.com
88039 Friedrichshafen
Germany

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
USA
          This Draft Expires in 6 months from June 2002 May 2003