Links

GitHub

Open HUB

Quick Links

Download

STREAMS

SIGTRAN

SS7

Hardware

SCTP

SIGTRAN

SCTP

UA

TUA

SUA

ISUA

M3UA

M2UA

M2PA

IUA

TALI

SS7 over IP

Documentation

FAQ

SIGTRAN

Design

Conformance

Performance

References

Man Pages

Manuals

Papers

Home

Overview

Status

Documentation

Resources

About

News

draft-ietf-sigtran-v5ua-01

Description: Request For Comments

You can download source copies of the file as follows:

draft-ietf-sigtran-v5ua-01.txt in text format.

Listed below is the contents of file draft-ietf-sigtran-v5ua-01.txt.




Internet Engineering Task Force                 Eva Weilandt
INTERNET DRAFT                           Neeraj Khanchandani
                                              Fahir Ergincan
                                                  Sanjay Rao
                                             Nortel Networks

Expires in six months                              July 2001

                   V5.2-User Adaption Layer (V5UA)
                   <draft-ietf-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.

Abstract

This document defines a mechanism for backhauling of V5.2 messages
over IP using the Stream control Transmission Protocol (SCTP). This
protocol would 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 on top of the ISDN User Adaptation Layer
Protocol (RFC 3057). It defines all differences to the IUAP needed for
the V5.2 implementation.

Weilandt,Khanchandani,Ergincan,Rao                            [Page 1]

Internet Draft V5.2-User Adaption Layer                     July, 2001

                     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 .........................    7
  1.5. Client/Server Model ......................................    7
  1.6. Addition to boundary primitives ..........................    7
    1.6.1. V5 specific boundary primitives ......................    7
2. SCTP Stream Management .......................................    9
3. Proposed V5.2 Backhaul Architecture ..........................    9
  3.1. V5UA Message Header ......................................   10
  3.2. V5 Naming Conventions for Interface Identifier ...........   11
  3.3. V5 Additions to IUA Boundary Primitives ..................   12
  3.4. Link Status Messages .....................................   13
  3.5. Sa-Bit Messages ..........................................   14
4. Procedures ...................................................   15
  4.1. V5 Layer 1 failure .......................................   15
  4.2. Loss of V5UA peer ........................................   16
5. Examples .....................................................   17
  5.1. Link Identification Procedure (successful) ...............   17
6. IANA Considerations ..........................................   18
  6.1. SCTP Payload Protocol Identifier .........................   18
7. Acknowledgements .............................................   18
8. References ...................................................   19
9. Author's Addresses ...........................................   19

Weilandt,Khanchandani,Ergincan,Rao                            [Page 2]

Internet Draft V5.2-User Adaption Layer                     July, 2001

1.  Introduction

This document describes a method of implementing V5.2 backhaul messag-
ing over IP using a modified version of the ISDN User Adapation Layer
Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the neces-
sary extensions to IUA for a V5.2 implementation.

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 to the implementation of the ISDN Q.921 User
Adaption 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 and specifically Layer 3 differs from the Q.921
and Q.931 Adaption layer, the IUA standard needs to 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 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 signalling

     - 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

Weilandt,Khanchandani,Ergincan,Rao                            [Page 3]

Internet Draft V5.2-User Adaption Layer                     July, 2001

     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
             CC_PROTOCOL             8177
             BCC_PROTOCOL            8178
             PROT_PROTOCOL           8179
             LINK_CONTROL_PROTOCOL   8180
             RESERVED                8181 - 8191

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 link in a multi-link V5.2 interface whose
     physical C-channel in time slot 16 carries a C-path for the pro-
     tection protocol and, on V5.2 initialization, also the C-path for
     the control protocol, link control protocol, and the BCC proto-
     col. Other C-paths may also be carried in the time slot 16.

Secondary Link  - A 2048 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

Weilandt,Khanchandani,Ergincan,Rao                            [Page 4]

Internet Draft V5.2-User Adaption Layer                     July, 2001

     primary link.

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.

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) pro-
viding 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) uses 2048 kbps links in a
     non-concentrating fashion. 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 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 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)

Weilandt,Khanchandani,Ergincan,Rao                            [Page 5]

Internet Draft V5.2-User Adaption Layer                     July, 2001

     - 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 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 manage-
       ment 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:

 Layer 2:
   - LAPV5-EF
   - LAPV5-DL

 Layer 3:
   - V5-Link Control
   - V5-BCC
   - V5-PSTN
   - V5-Control
   - V5-Protection

In the backhaul architecture, the protocols are distributed over SG
and MGC as shown below.

Weilandt,Khanchandani,Ergincan,Rao                            [Page 6]

Internet Draft V5.2-User Adaption Layer                     July, 2001

       MGC                         SG
  +------------+            +-------+-------+
  | Lnk Cntrl  |            |       |       |
  +------------+            |       |       |
  |   Cntrl    |            |       |       |
  +------------+    V5UA    |       |       |   V5   +------+
  |    BCC     | <--------> | LAPV5 | LAPV5 | <----> |  AN  |
  +------------+            |  -DL  |  -EF  |        +------+
  |   PSTN     |            |       |       |
  +------------+            |       |       |
  | Protection |            |       |       |
  +------------+            +-------+-------+

1.4.  TEI Management for BRI over V5UA

Dynamic TEI Management for BRI over V5 shall be located on the MGC.

1.5.  Client/Server Model

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

The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA
is ? (tbd).

1.6.  Addition to boundary primitives

1.6.1.  V5 specific boundary primitives

Extending IUAP to support V5.2 requires the introduction of new boun-
dary primitives for the Q.921/Q.931 boundary in accordance with the
definitions in V5.2.

V5.2 reuses the primitives from the Q.921/Q.931 boundary: the DL-DATA
primitive and the DL-UNIT DATA primitive. The DL-UNIT DATA primitive
is only used for ISDN messages and is used and defined as described
for IUAP.

The responsibility to establish and release data links is shifted to
V5 system management. Therefore the DL-Establish and DL-Release primi-
tives are replaced by new primitives between system management and the
data link layer [2]:

MDL-ESTABLISH

The MDL-Establish primitives are used to request, indicate and confirm

Weilandt,Khanchandani,Ergincan,Rao                            [Page 7]

Internet Draft V5.2-User Adaption Layer                     July, 2001

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 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 physically
separated in a V5 backhaul scenario, V5UA needs to support some ser-
vice for the communication between these two entities. Specifically
these services include an indication of the status of a link, and mes-
sages to support link identification procedure.

The new messages are defined as shown below:

MPH-LINK STATUS START REPORTING

The MPH-LINK STATUS START REPORTING message is used by V5 system
management to request to take the link in service for use on a V5
interface. On reception of this message L1 FSM on the SG shall also
start reporting the status of the V5 link to the GWC.

MPH-LINK STATUS STOP REPORTING

The MPH-LINK STATUS STOP REPORTING message is used by V5 system
management to request to take the link out of service for use on a V5
interface. On reception of this message L1 FSM on the SG shall also
stop reporting the status of the V5 link to the GWC.

MPH-LINK STATUS INDICATION

The MPH-LINK STATUS INDICATION message is used by L1 FSM on the Sig-
nalling Gateway to report the status (operational/non-operational) of
a V5 link to V5 system management.

MPH-SA-BIT SET

The MPH-SA-BIT SET message 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. For V5 this message will be used for the
Link Identification procedure to set or reset the value of the Sa7
bit. This would be equivalent to the MPH-ID and MPH-NOR primitves in
V5.2.

MPH-SA-BIT SET ACK

The MPH-SA-BIT SET ACK message is used by L1 FSM in the SG to indicate
to system management in response to a MPH-SA-BIT-SET message. The mes-
sage indicates that the setting of the Sa bit has been performed suc-
cessfully.

Weilandt,Khanchandani,Ergincan,Rao                            [Page 8]

Internet Draft V5.2-User Adaption Layer                     July, 2001

MPH-SA-BIT STATUS

The MPH-SA-BIT STATUS messages are used between system management in
the MGC and L1 FSM in the SG to request reporting of the status of a
specified Sa bit on the requested link, or to report the status of
this bit back to system management.  For V5 these messages will be
used for the Link identification procedure to request or report the
status of the Sa7 bit. This would be equivalent to the MPH-IDR, MPH-
IDI or MPH-Elg primitive in V5.2.

2.  SCTP Stream Management

It is recommended that one SCTP stream be used for BCC, Link Control,
Common Control and PSTN protocol on a specific c-channel.  It is
recommended to use a separate SCTP stream for Protection protocol on a
specific c-channel. It is also recommended to use one SCTP stream 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, it is recommended that one separate SCTP stream be used
for all MPH (link related) messages.

3.  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

        SCTP - Stream Control Transmission Protocol

Weilandt,Khanchandani,Ergincan,Rao                            [Page 9]

Internet Draft V5.2-User Adaption Layer                     July, 2001

3.1.  V5UA Message Header
The original IUA message header needs to be modified for V5. The ori-
ginal 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 the IUA Message Header, the Envelope Function
Address (EFA) field is included in the last 13 bits of the Spare
field. Below the V5UA format for the integer formatted Interface Iden-
tifier is shown:

   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|          EFA            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3 V5UA Message Header (Integer-based Interface identifier)

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 con-
tains the possible values for the EFA:

Weilandt,Khanchandani,Ergincan,Rao                           [Page 10]

Internet Draft V5.2-User Adaption Layer                     July, 2001

        Definition              Value
        ----------              ------
        ISDN_PROTOCOL           0 - 8175
        PSTN_PROTOCOL           8176
        CC_PROTOCOL             8177
        BCC_PROTOCOL            8178
        PROT_PROTOCOL           8179
        LINK_CONTROL_PROTOCOL   8180
        RESERVED                8181 - 8191

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

The text formatted Interface Identifier SHALL not be supported due to
the neccessary naming conventions for the Interface Identifier.

3.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-
ling 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:

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 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Weilandt,Khanchandani,Ergincan,Rao                           [Page 11]

Internet Draft V5.2-User Adaption Layer                     July, 2001

Link Identifier - Identifier for an E1 link on the SG (27 bits). 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 be set
     to 0. All other values are reserved for future use.

3.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 valid message classes for V5UA 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 QPTMV5
     messages 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 to the QPTM messages. In addi-
tion, Layer 1 boundary primitive messages are defined:

       11       Link Status Start Reporting    (MGC -> SG)

Weilandt,Khanchandani,Ergincan,Rao                           [Page 12]

Internet Draft V5.2-User Adaption Layer                     July, 2001

       12       Link Status Stop Reporting     (MGC -> SG)
       13       Link Status Indication         (SG -> MGC)
       14       Sa-Bit Set Value               (MGC -> SG)
       15       Sa-Bit Set Ack                 (SG -> MGC)
       16       Sa-Bit Status Request          (MGC -> SG)
       17       Sa-Bit Status Indication       (SG -> MGC)

3.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 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 be set to '0' and shall be ignored by the receiver.

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

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

V5 system management shall send this Message on interface activation
for all links on the interface. The SG will respond immediately to
this request with a Link Status Indication message, and it will 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 always be sent on
interface startup.

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 respond in any way to this message.

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

The Link Status Start/Stop Report Messages contain the common message

Weilandt,Khanchandani,Ergincan,Rao                           [Page 13]

Internet Draft V5.2-User Adaption Layer                     July, 2001

header followed by the V5UA message header. They do not contain any
addition parameters.

The Link Status Indication Message is used by L1 FSM in the SG in
response to a Link Status Request Message to indicate the status of
the particular link. After a Link Status Start Report Message has been
received by the L1 FSM, it will automatically send a Link Status Indi-
cation Message every time the status of the particular link changes.
It will 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 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
     NON-OPERATIONAL  0x1       Link is not in operation

3.5.  Sa-Bit Messages (Set, Set Ack, Status Request, Status Indica-
tion)

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 the V5 defined Link Identification procedure.

All Sa-Bit Messages contain the V5UA message header. The Link Identif-
ier 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 be set to '0' and shall be ignored by the receiver.

The Link Identifier 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 message is used to set the value of the specified Sa-
Bit on the defined link. For V5, the value of the Sa7 bit in normal
operation is ONE. For the Link Identification procedure, it is set to
ZERO.

Weilandt,Khanchandani,Ergincan,Rao                           [Page 14]

Internet Draft V5.2-User Adaption Layer                     July, 2001

The SG MUST answer a Sa-Bit Set message with a Sa-Bit Set Ack message
when the setting of the bit is complete.

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. L1 FSM answers this request by a Sa-Bit Status Indication message
in which the current setting of the bit will be reported.

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 ZERO
     ONE              0x1       Bit is set to 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 Ack messages, the BIT Value
should be set to '0' by the sender and should be ignored by the
receiver.

4.  Procedures

4.1.  V5 Layer 1 failure

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

     - L1FSM detects the Layer 1 failure. It reports this to V5 System

Weilandt,Khanchandani,Ergincan,Rao                           [Page 15]

Internet Draft V5.2-User Adaption Layer                     July, 2001

       management by sending a MPH-DI primitive for the affected link.

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

Since Layer1/2 and V5 System Management are no longer co-located in
the backhaul architecture, it does not make sense to notify Layer 2
about Layer 1 failure via V5 system management. Instead Layer 2 shall
be notified directly by Layer 1 on the SG. Layer 1 shall still report
the outage to V5 system management by sending an MPH-DI primitive, but
V5 system management shall not send a MPH-Layer_1 Failure Ind primi-
tive to Layer 2.

4.2.  Loss of V5UA peer

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

When loss of V5UA peer is detected, the SG will start a timer T1(r)
(tbd). If the connection is reestablished before T1(r) expires, com-
munication should proceed as usual.

After expiry of timer T1(r) and if the connection can not be reesta-
blished, the SG shall behave as if it had received a Link Status Stop
Reporting message for all links connected to this SG.

In case of loss of the V5UA peer, the ASP will start a timer T2(r)
(tbd). This timer shall expire earlier than T1(r) in the SG. The ASP
will continuously try to reestablish the connection. In case it is
successful before T2(r) expires, communication should proceed as
usual.

After expiry of timer T2(r) and if the connection can not be reesta-
blished, the ASP shall behave as if it had received a Link Status
Indication (non-operational) for all links on this SG. The ASP shall
proceed in attempting to reestablish the connection.

When the connection is reestablished after timer T2(r) has expired,
the ASP shall send a Link Status Start Reporting message to the SG for
all links on active V5 interfaces on the SG.

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

     ASP                                               SG

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

Weilandt,Khanchandani,Ergincan,Rao                           [Page 16]

Internet Draft V5.2-User Adaption Layer                     July, 2001

5.  Examples

5.1.  Link Identification Procedure (successful)

An example for the message flow for an LE initiated Link Identifica-
tion procedure is shown below. An active association between ASP and
SG is established prior to the following messages flows, and the V5
interface is already activated:

     ASP                                               SG

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

The next example again 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:

Weilandt,Khanchandani,Ergincan,Rao                           [Page 17]

Internet Draft V5.2-User Adaption Layer                     July, 2001

     ASP                                               SG

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

6.  IANA Considerations

6.1.  SCTP Payload Protocol Identifiers

A request will be made to IANA to assign an V5UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk.  The following SCTP
Payload Protocol Identifier will be registered:

     V5UA    "?"

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 a
way of determining additional information about the data being
presented to it by SCTP.

7.  Acknowledgements

The authors would like to thank Milos Pujic, Graeme Currie, Berthold
Jaekle for their valuable comments and suggestions.

Weilandt,Khanchandani,Ergincan,Rao                           [Page 18]

Internet Draft V5.2-User Adaption Layer                     July, 2001

8.  References

[1]  ISDN Q.921-User Adaptation Layer RFC 3057

[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 interface 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).

9.  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

Dr. Fahir Ergincan                                 Tel +1-613-763-4929
Nortel Networks                         Email fahir@nortelnetworks.com
100 Constellation Crecent
Nepean, ON K2G6J8
Canada

Weilandt,Khanchandani,Ergincan,Rao                           [Page 19]

Internet Draft V5.2-User Adaption Layer                     July, 2001

          This Draft Expires in 6 months from July,2001

Weilandt,Khanchandani,Ergincan,Rao                           [Page 20]



Last modified: Thu, 13 Nov 2014 05:02:11 GMT  
Copyright © 2014 OpenSS7 Corporation All Rights Reserved.