path: root/doc/rfc/rfc3807.txt

Network Working Group                                        E. Weilandt
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.



















Weilandt, et al.            Standards Track                     [Page 1]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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.





Weilandt, et al.            Standards Track                     [Page 2]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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




Weilandt, et al.            Standards Track                     [Page 3]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


      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.






Weilandt, et al.            Standards Track                     [Page 4]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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




Weilandt, et al.            Standards Track                     [Page 5]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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









Weilandt, et al.            Standards Track                     [Page 6]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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.





Weilandt, et al.            Standards Track                     [Page 7]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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.






Weilandt, et al.            Standards Track                     [Page 8]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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




Weilandt, et al.            Standards Track                     [Page 9]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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

















Weilandt, et al.            Standards Track                    [Page 10]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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)














Weilandt, et al.            Standards Track                    [Page 11]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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 contains the possible values
   for the 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 which do not use DLCI and EFA, 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 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 keep track of the
   states of all links on a V5 interface.  To perform tasks like
   protection switching and bearer channel allocation on the V5 links,
   it is necessary that system management has the full picture of the
   signaling 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 message.

   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 for V5UA.







Weilandt, et al.            Standards Track                    [Page 12]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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

   If used, the text formatted interface identifier 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
   distinguish between these two message types by means of the Message
   Class parameter.

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

        14       V5 Boundary Primitives Transport
                 Messages (V5PTM)

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

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







Weilandt, et al.            Standards Track                    [Page 13]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM
   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 similarly to the QPTM messages.
   In 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, Indication)

   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 whether or not the E1 link 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 be set to '0' and SHALL be ignored
   by the receiver.

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

   As defined by the V5 standards, V5 System Management must know the
   status of the links on all active V5 interfaces.  The Link Status
   Start Reporting Message is used by V5 System Management on the MGC to
   request that the L1 FSM on the SG starts reporting the status of a
   particular link.



Weilandt, et al.            Standards Track                    [Page 14]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   V5 system management SHALL send this Message on interface activation
   for all links on the interface.  The SG SHALL respond immediately to
   this request with a Link Status Indication message, and it 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 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 System 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 respond in any way to this message.

   Since there is no other way for the SG to know that an interface has
   been deactivated, this message SHALL be sent on interface
   deactivation for all links on the interface.  On reception of this
   message, the SG 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
   System Management), the SG SHALL ignore the message.

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

   The Link Status Indication Message is used by L1 FSM in the SG in
   response to a Link Status Start Reporting Message to indicate the
   status of the particular link.  After a Link Status Start Reporting
   Message has been received by the L1 FSM, it SHALL automatically send
   a Link Status Indication Message every time the status of the
   particular link changes.  It 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
   following link status parameter:






Weilandt, et al.            Standards Track                    [Page 15]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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

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

      Define          Value      Description

      OPERATIONAL      0x0       Link operational
      NON-OPERATIONAL  0x1       Link not 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 for the Link Identification procedure as
   described by the V5 standards [3].

   All Sa-Bit Messages SHALL 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 Link Identifier MUST be the same as used in the Interface
   Identifier to identify on which link a C-channel is located.

   The Sa-Bit Set Request message is used to set the value of the
   specified Sa-Bit on the defined link.  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
   Confirm message when the setting of the bit is complete.  This
   message does not correspond to a V5 defined primitive.





Weilandt, et al.            Standards Track                    [Page 16]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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 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 (0x83)           |             Length           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             BIT ID             |        Bit Value             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

      Define          Value      Description

      ZERO             0x0       Bit value ZERO
      ONE              0x1       Bit 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
   SHALL be set to '0' by the sender and 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 at the SG.




Weilandt, et al.            Standards Track                    [Page 17]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   The only valid reason for the Error Indication Message is Overload.
   The SG SHOULD issue such an Error Indication with reason Overload for
   a C-channel 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).

   The Error Indication message SHALL contain the V5UA message header.

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

   The Error Indication message contains 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 (0x84)           |             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 be notified directly by V5 Layer 1 on the SG.  V5



Weilandt, et al.            Standards Track                    [Page 18]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   Layer 1 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 as defined by the V5.2 standard.
   V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind
   primitive to V5 Layer 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 be performed:

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

   The ASP SHALL attempt to re-establish the connection continuously.
   When the connection is re-established, 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 for re-establishment of the
   connection is shown below for one active link on the SG:

      ASP                                               SG

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

   If the association can be re-established before the V5UA layer is
   notified, communication SHALL proceed as usual and no other action
   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 SHOULD
   indicate this by sending an Error Indication message, with the reason
   Overload to the MGC.  The MGC SHOULD then take appropriate actions to
   clear this overload condition.

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






Weilandt, et al.            Standards Track                    [Page 19]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


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
   procedure over V5UA is shown below.  An active association between
   ASP and SG is established prior to the following message flows, and
   the V5 interface is already 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) -- |
       |                                                 |
























Weilandt, et al.            Standards Track                    [Page 20]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   The next example also shows a Link Identification procedure, but this
   time it is initiated by the AN.  Again, the ASP association and the
   V5 interface 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

   The security considerations discussed for the 'Security
   Considerations for SIGTRAN Protocols' [5] 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.






Weilandt, et al.            Standards Track                    [Page 21]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


   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
   valuable comments and suggestions.

10.  References

10.1.  Normative References

   [1]  Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN
        Q.921-User Adaptation Layer", RFC 3057, 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]  Loughney, J., Tuexen, M., Ed. and J. Pastor-Balbas, "Security
        Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
        3788, May 2004.















Weilandt, et al.            Standards Track                    [Page 22]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


10.2.  Informative References

   [6]  Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
        H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
        "Stream Control Transmission Protocol", RFC 2960, October 2000.

   [7]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

11.  Authors' Addresses

   Dr. Eva Weilandt
   Conti Temic microelectronic GmbH
   An der B31
   88090 Immenstaad
   Germany

   Phone: +49 7545 8-2917
   EMail: eva.weilandt@temic.com


   Sanjay Rao
   Nortel Networks
   35 Davis Drive
   Research Triangle Park, NC 27709
   USA

   Phone: +1-919-991-2251
   EMail: rsanjay@nortelnetworks.com


   Neeraj Khanchandani
   Nortel Networks
   35 Davis Drive
   Research Triangle Park, NC 27709
   USA

   Phone: +1-919-991-2274
   EMail: neerajk@nortelnetworks.com












Weilandt, et al.            Standards Track                    [Page 23]
^L
RFC 3807           V5.2-User Adaptation Layer (V5UA)           June 2004


12.  Full Copyright Statement

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Weilandt, et al.            Standards Track                    [Page 24]
^L