draft-ietf-sigtran-v5ua-03.txt   draft-ietf-sigtran-v5ua-04.txt 
Internet Engineering Task Force E. Weilandt Internet Engineering Task Force E. Weilandt
INTERNET DRAFT N. Khanchandani INTERNET DRAFT N. Khanchandani
S. Rao S. Rao
Nortel Networks Nortel Networks
Expires in six months June 2002 Expires in six months May 2003
V5.2-User Adaptation Layer (V5UA) V5.2-User Adaptation Layer (V5UA)
<draft-ietf-sigtran-v5ua-03.txt> <draft-ietf-sigtran-v5ua-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts. groups may also distribute working documents as Internet- Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document defines a mechanism for backhauling of V5.2 messages This document defines a mechanism for backhauling of V5.2 messages
over IP using the Stream control Transmission Protocol (SCTP). This over IP using the Stream Control Transmission Protocol (SCTP). This
protocol would be used between a Signaling Gateway (SG) and a Media protocol may be used between a Signaling Gateway (SG) and a Media
Gateway controller (MGC). It is assumed that the SG receives V5.2 sig- Gateway controller (MGC). It is assumed that the SG receives V5.2 sig-
naling over a standard V5.2 interface. naling over a standard V5.2 interface.
This document aims to build on top of the ISDN User Adaptation Layer This document builds on top of the ISDN User Adaptation Layer Protocol
Protocol (RFC 3057). It defines all differences to the IUAP needed for (RFC 3057). It defines all necessary extensions to the IUA Protocol
the V5.2 implementation. needed for the V5UA protocol implementation.
Table of Contents Table of Contents
1. Introduction ................................................. 3 1. Introduction ................................................. 3
1.1. Scope .................................................... 3 1.1. Scope .................................................... 3
1.2. Terminology .............................................. 3 1.2. Terminology .............................................. 3
1.3. V5.2 Overview ............................................ 5 1.3. V5.2 Overview ............................................ 5
1.4. TEI Management for BRI over V5UA ......................... 7 1.4. Distribution of responsibilities between MGC and SG ...... 7
1.5. Client/Server Model ...................................... 7 1.5. Client/Server Model ...................................... 7
1.6. Addition to boundary primitives .......................... 7 1.6. Addition to boundary primitives .......................... 7
1.6.1. V5 specific boundary primitives ...................... 7 1.6.1. V5 specific boundary primitives ...................... 7
2. Conventions .................................................. 9 2. Conventions .................................................. 9
3. SCTP Stream Management ....................................... 9 3. SCTP Stream Management ....................................... 9
4. Proposed V5.2 Backhaul Architecture .......................... 9 4. Proposed V5.2 Backhaul Architecture .......................... 10
4.1. V5UA Message Header ...................................... 10 4.1. V5UA Message Header ...................................... 10
4.2. V5 Naming Conventions for Interface Identifier ........... 11 4.2. V5 Naming Conventions for Interface Identifier ........... 11
4.3. V5 Additions to IUA Boundary Primitives .................. 12 4.3. V5 Additions to IUA Boundary Primitives .................. 12
4.4. Link Status Messages ..................................... 13 4.4. Link Status Messages ..................................... 13
4.5. Sa-Bit Messages .......................................... 15 4.5. Sa-Bit Messages .......................................... 15
4.6. Error Indication Message ................................. 16 4.6. Error Indication Message ................................. 16
5. Procedures ................................................... 17 5. Procedures ................................................... 17
5.1. V5 Layer 1 failure ....................................... 17 5.1. V5 Layer 1 failure ....................................... 17
5.2. Loss of V5UA peer ........................................ 17 5.2. Loss of V5UA peer ........................................ 18
5.3. C-channel overload on SG ................................. 18 5.3. C-channel overload on SG ................................. 18
6. Examples ..................................................... 18 6. Examples ..................................................... 18
6.1. Link Identification Procedure (successful) ............... 18 6.1. Link Identification Procedure (successful) ............... 18
7. Security Considerations ...................................... 19 7. Security Considerations ...................................... 20
8. IANA Considerations .......................................... 19 8. IANA Considerations .......................................... 20
8.1. SCTP Payload Protocol Identifier ......................... 19 8.1. SCTP Payload Protocol Identifier ......................... 20
8.2. V5UA Port Number ......................................... 20 8.2. V5UA Port Number ......................................... 20
9. Acknowledgements ............................................. 20 9. Acknowledgements ............................................. 20
10. References .................................................. 20 10. References .................................................. 20
10.1. Normative References .................................... 20 10.1. Normative References .................................... 20
10.2. Informative References .................................. 20 10.2. Informative References .................................. 21
11. Author's Addresses .......................................... 21 11. Author's Addresses .......................................... 21
1. Introduction 1. Introduction 1. Introduction
This document describes a method of implementing V5.2 backhaul messag- This document describes a method of implementing V5.2 backhaul messag-
ing over IP using a modified version of the ISDN User Adaption Layer ing over IP using a modified version of the ISDN User Adaptation Layer
Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the neces- Protocol (IUAP) [1]. V5UA builds on top of IUA, defining the necessary
sary extensions to IUA for a V5.2 implementation. extensions to IUA for a V5.2 implementation.
Since V5UA is meant to be an extension to IUAP, everything defined in 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- [1] is also valid for V5UA unless specified otherwise in this docu-
ment. 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 1.1. Scope
There is a need for Switched Circuit Network (SCN) signaling protocol There is a need for Switched Circuit Network (SCN) signaling protocol
delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Con- 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 troller (MGC), analogous to the implementation of the ISDN Q.921 User
Adaption Layer (IUA) as described in [1]. Adaptation Layer (IUA) as described in [1].
This draft supports analog telephone access, ISDN basic rate access This draft supports analog telephone access, ISDN basic rate access
and ISDN Primary rate access over a V5.2 interface. 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 Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921
and Q.931 Adaption layer, the IUA standard needs to be extended to and Q.931 Adaptation layer, the IUA standard must be extended to ful-
fulfil the needs for supporting V5.2. fil the needs for supporting V5.2.
1.2. Terminology 1.2. Terminology
Bearer Channel Connection (BCC) protocol - A protocol which allows the Bearer Channel Connection (BCC) protocol - A protocol which allows the
Local Exchange (LE) to instruct the Access Network (AN) to allo- Local Exchange (LE) to instruct the Access Network (AN) to allo-
cate bearer channels, either singly or in multiples, on demand. cate bearer channels, either singly or in multiples, on demand.
Communication channel (C-channel) - A 64 kbit/s time slot on a V5.2 Communication channel (C-channel) - A 64 kbit/s time slot on a V5.2
interface provisioned to carry communication paths. interface provisioned to carry communication paths.
skipping to change at page 3, line 51 skipping to change at page 4, line 4
- The layer 2 data link carrying the Control protocol - 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 Link Control protocol
- The layer 2 data link carrying the PSTN signaling - The layer 2 data link carrying the PSTN signaling
- Each of the layer 2 data links carrying the protection protocol - Each of the layer 2 data links carrying the protection protocol
- The layer 2 data link carrying the BCC 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 Ds-type data from one or more user ports
- All the ISDN p-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 - All the ISDN t-type data from one or more user ports
Note: This definition includes the possibility that there is more Note: This definition includes the possibility that there may be
than one C-path of the same information type, each allocated to a more than one C-path of the same information type, each allocated
different logical C-channel. to a different logical C-channel.
Envelope Function Address (EFA) - 13 bit number, ranging from 0 to Envelope Function Address (EFA) - 13 bit number, ranging from 0 to
8191 (decimal). An EFA uniquely identifies one of the five V5.2 8191 (decimal). An EFA uniquely identifies one of the five V5.2
protocols, or an ISDN agent attached to an AN. The following list protocols, or an ISDN agent attached to an AN. The following list
contains the possible values for the EFA: contains the possible values for the EFA:
Definition Value Definition Value
---------- ------ ---------- ------
ISDN_PROTOCOL 0 - 8175 ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176 PSTN_PROTOCOL 8176
skipping to change at page 4, line 49 skipping to change at page 5, line 8
supply a higher bit-rate service. supply a higher bit-rate service.
Physical Communication Channel (Physical C-channel) - A 64kbit/s time Physical Communication Channel (Physical C-channel) - A 64kbit/s time
slot on a V5.2 interface which has been assigned for carrying 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- logical C-channels. A physical C-channel may not be used for car-
rying bearer channels. rying bearer channels.
Primary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 interface 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 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 protection protocol and, on V5.2 initialization, also the C-path
for the control protocol, link control protocol, and the BCC for the control protocol, link control protocol, and the BCC pro-
protocol. Other C-paths may also be carried in the time slot 16. 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- 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- 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 tocol, and, on V5.2 initialization, acts as the standby C-channel
for the control protocol, link control protocol, and BCC protocol for the control protocol, link control protocol, and BCC protocol
and any other C-paths initially carried in time slot 16 of the and any other C-paths initially carried in time slot 16 of the
primary link. primary link.
V5 Link - A 2048 kbits/s E1 (PCM30) link used on a V5 interface. A V5 V5 Link - A 2048 kbits/s E1 (PCM30) link used on a V5 interface. A V5
interface may use up to 16 V5 links. interface may use up to 16 V5 links.
skipping to change at page 5, line 32 skipping to change at page 5, line 37
- Analog telephone access - Analog telephone access
- ISDN Basic rate access - ISDN Basic rate access
- ISDN Primary Rate access - ISDN Primary Rate access
- Other analog or digital accesses for semi-permanent connections - Other analog or digital accesses for semi-permanent connections
without associated outband signaling information without associated outband signaling information
The original V5 specification (V5.1 [2]) uses 2048 kbps links in The original V5 specification (V5.1 [2]) uses 2048 kbps links in
a non-concentrating fashion. V5.2 may use up to 16 such interface a non-concentrating fashion. In contrast V5.2 may use up to 16
links and supports concentration. such interface links and supports concentration.
---------- ---------- o--o ---------- ---------- o--o
| | E1 | |------- /\ | | E1 | |------- /
| |--------------| | -- | |--------------| | --
| LE | E1 | AN | | LE | E1 | AN |
| |--------------| | o--o | |--------------| | o--o
| | | |------- /\ | | | |------- /
---------- ---------- -- ---------- ---------- --
The LE and AN are connected with up to 16 E1 (PCM30) links. Channels 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 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- between LE and AN. The channels reserved for data are called
cation Channels" or "C-channels."
The C-channels are the physical media to exchange data between the "Communication Channels" or "C-channels."
V5.2 protocol peer entities, as well as to transfer the ISDN BRI D-
The C-channels are the physical media 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- channel messages between the terminals and the LE. A logical communi-
cation path between two peer entities for one protocol is called a cation path between two peer entities for one protocol is called a
"C-path". "C-path".
The signaling information in V5.2 are defined as: The signaling information in V5.2 are defined as:
- Analog signals are carried by means of the V5 PSTN protocol - Analog signals are carried by means of the V5 PSTN protocol
(L3) (L3)
- ISDN/analog ports are controlled by the V5 Control protocol - ISDN/analog ports are controlled by the V5 Control protocol
skipping to change at page 6, line 26 skipping to change at page 6, line 30
- ISDN protocol messages are mapped to LAPD frames, which are - ISDN protocol messages are mapped to LAPD frames, which are
carried by means of LAPV5-EF sublayer (L2) carried by means of LAPV5-EF sublayer (L2)
- V5 protocol messages are mapped to LAPV5-DL frames, which are - V5 protocol messages are mapped to LAPV5-DL frames, which are
carried by means of LAPV5-EF sublayer (L2) carried by means of LAPV5-EF sublayer (L2)
In order to support more traffic and dynamic allocation of bearer In order to support more traffic and dynamic allocation of bearer
channels, the V5.2 protocol has several additions: channels, the V5.2 protocol has several additions:
- A bearer channel connection protocol establishes and de- - A bearer channel connection protocol establishes and disestab-
establishes bearer connections required on demand, identified lishes bearer connections on demand, as determined by the sig-
by the signaling information, under the control of the Local naling information, under the control of the Local Exchange.
Exchange.
- A link control protocol is defined for the multi-link manage- - A link control protocol is defined for multi-link management to
ment to control link identification, link blocking and link control link identification, link blocking and link failure
failure conditions. conditions.
- A protection protocol, operated on two separate V5 data links - A protection protocol, operating on two separate V5 data links
for security reasons, is defined to manage the protection is defined to manage the protection switching of communication
switching of communication channels in case of link failures. channels in case of link failures.
The following protocols are defined for the various protocol layers: The following protocols are defined for the various protocol layers:
Layer 2: Layer 2:
- LAPV5-EF - LAPV5-EF
- LAPV5-DL - LAPV5-DL
Layer 3: Layer 3:
- V5-Link Control - V5-Link Control
- V5-BCC - V5-BCC
- V5-PSTN - V5-PSTN
- V5-Control - V5-Control
- V5-Protection - V5-Protection
In the backhaul architecture, the protocols are distributed over SG 1.4. Distribution of responsibilities between MGC and SG
and MGC as shown below.
In the V5UA backhaul architectrue, the V5 protocol entities SHALL be
distributed over SG and MGC as shown below.
MGC SG MGC SG
+------------+ +-------+-------+ +------------+ +-------+-------+
| Lnk Cntrl | | | | | Lnk Cntrl | | | |
+------------+ | | | +------------+ | | |
| Cntrl | | | | | Cntrl | | | |
+------------+ V5UA | | | V5 +------+ +------------+ V5UA | | | V5 +------+
| BCC | <--------> | LAPV5 | LAPV5 | <----> | AN | | BCC | <--------> | LAPV5 | LAPV5 | <----> | AN |
+------------+ | -DL | -EF | +------+ +------------+ | -DL | -EF | +------+
| PSTN | | | | | PSTN | | | |
+------------+ | | | +------------+ | | |
| Protection | | | | | Protection | | | |
+------------+ +-------+-------+ +------------+ +-------+-------+
1.4. TEI Management for BRI over V5UA 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 BRI over V5 shall be located on the MGC. Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the
MGC.
1.5. Client/Server Model 1.5. Client/Server Model
The Client/Server Model for V5UA should follow the model as defined The Client/Server Model for V5UA shall follow the model as defined for
for IUAP. IUAP.
The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA
is 5675. is 5675.
1.6. Addition to boundary primitives 1.6. Addition to boundary primitives
1.6.1. V5 specific boundary primitives 1.6.1. V5 specific boundary primitives
Extending IUAP to support V5.2 requires the introduction of new boun- Extending IUAP to V5UA to support V5.2 backhaul requires the introduc-
dary primitives for the Q.921/Q.931 boundary in accordance with the tion of new boundary primitives for the Q.921/Q.931 boundary, in
definitions in V5.2. accordance with the definitions in the V5 standards.
V5.2 reuses the primitives from the Q.921/Q.931 boundary: the DL-DATA V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the
primitive and the DL-UNIT DATA primitive. The DL-UNIT DATA primitive DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primi-
is only used for ISDN messages and is used and defined as described tive is used for transport of both V5 Layer 3 messages and V5 ISDN
for IUAP. 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 is responsible for
V5 system management. Therefore the DL-Establish and DL-Release primi-
tives are replaced by new primitives between system management and the establishing and releasing data links. Therefore, for V5UA the DL-
data link layer [2]: 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 MDL-ESTABLISH
The MDL-Establish primitives are used to request, indicate and confirm The MDL-Establish primitives are used to request, indicate and confirm
the outcome of the procedures for establishing multiple frame opera- the outcome of the procedures for establishing multiple frame opera-
tion. tion.
MDL-RELEASE MDL-RELEASE
The MDL-Release primitive is used to indicate the outcome of the pro- The MDL-Release primitive is used to indicate the outcome of the pro-
cedures for terminating multiple frame operation. cedures for terminating multiple frame operation.
In contrary to ISDN, the V5 standards demand that V5.2 system manage- In 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- 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 ing the L1 FSM) and parts of V5 system management are physically
separated in a V5 backhaul scenario, V5UA needs to support some ser- separated in a V5 backhaul scenario, V5UA must support some services
vices for the communication between these two entities. Specifically for the communication between these two entities. Specifically, these
these services include an indication of the status of a link, and mes- services include an indication of the status of a specific link, and
sages to support link identification procedure. messages to support the link identification procedure defined by the
V5 standards.
The new primitive are defined as shown below: The new primitive are defined as shown below:
MPH-LINK STATUS START REPORTING MPH-LINK STATUS START REPORTING
The MPH-LINK STATUS START REPORTING primitive is used by V5 system The MPH-LINK STATUS START REPORTING primitive is used by V5 system
management to request to take the link in service for use on a V5 management to request that a link be brought into service for use in a
interface. On reception of this message L1 FSM on the SG shall also V5 interface. On reception of this message, the L1 FSM on the SG SHALL
start reporting the status of the V5 link to the GWC. start reporting the status of the V5 link to the 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 MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system
management to request to take the link out of service for use on a V5 management to request that a link is taken out of service on a V5
interface. On reception of this message L1 FSM on the SG shall also interface. On reception of this message L1 FSM on the SG SHALL stop
stop reporting the status of the V5 link to the GWC. 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 MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the Sig- 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 naling Gateway to report the status (operational/non-operational) of a
V5 link to V5 system management. 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 MPH-SA-BIT SET
The MPH-SA-BIT SET primitive is used by system management to request 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 that the L1 FSM in the SG sets or resets the value of a specified Sa
bit on the requested link, or to report the successful setting or bit on the requested link. The SG uses it to report the successful
resetting of this bit back to system management. For V5 this message setting or resetting of this bit back to system management. For V5
will be used for the Link Identification procedure to set/reset the this message is used for the V5 specific Link Identification procedure
value of the Sa7 bit, or to confirm the successful setting of the Sa to set/reset the value of the Sa7 bit, or to confirm the successful
bit. The MPH-SA BIT SET REQUEST is equivalent to the MPH-ID and MPH- setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to
NOR primitves in V5.2. the MPH-ID and MPH-NOR primitves in V5.2.
MPH-SA-BIT STATUS MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS primitives are used between system management in The MPH-SA-BIT STATUS primitives are used by system management in the
the MGC and L1 FSM in the SG to request reporting of the status of a MGC to request that the L1 FSM in the SG reports the status of a
specified Sa bit on the requested link, or to report (indicate) the 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
status of this bit back to system management. For V5 these messages these messages are used for the V5 specific Link identification pro-
will be used for the Link identification procedure to request or cedure to request or report the status of the Sa7 bit. This is
report the status of the Sa7 bit. This is equivalent to the MPH-IDR, equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2.
MPH-IDI or MPH-Elg primitive in V5.2.
Due to the separation of V5 System Management and V5 Layer1/Layer2, it Due to the separation of V5 System Management and V5 Layer1/Layer2 in
may be necessary to report error conditions of the SG's V5 stack to V5 the V5UA backhaul architecture, it may be necessary to report error
System Management. For this a new primitive is defined: conditions of the SG's V5 stack to V5 System Management. For this
purpose, a new primitive is defined:
MDL-ERROR INDICATION MDL-ERROR INDICATION
The MDL-ERROR INDICATION primitive is used to indicate an error condi- The MDL-ERROR INDICATION primitive is used to indicate an error condi-
tion to V5 System Management. The only valid reason for this primi- tion to V5 System Management. The only valid reason for this primi-
tive is 'Overload', indicating an overload condition of the C-channel 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. on the SG. This reason is not defined in the V5/Q.921 standards.
2. Conventions 2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they
appear in this document, are to be interpreted as describd in [8]. appear in this document, are to be interpreted as describd in [8].
3. SCTP Stream Management 3. SCTP Stream Management
It is recommended that one SCTP stream be used for BCC, Link Control, A single SCTP stream SHOULD be used for grouping all of the following
Control and PSTN protocol on a specific C-channel. It is recommended protocols together: BCC, Link Control, Control and PSTN protocol on a
to use a separate SCTP stream for Protection protocol on a specific specific C-channel. A separate SCTP stream SHOULD be used for the
C-channel. It is also recommended to use one SCTP stream for all ISDN Protection protocol on a specific C-channel. One SCTP stream SHOULD be
user ports on a specific C-channel. One single stream should not be used for all ISDN user ports on a specific C-channel. One single
used to carry data of more than one C-channel. 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 In addition, one separate SCTP stream SHOULD be used for all MPH (link
for all MPH (link related) messages. related) messages.
4. Proposed V5.2 Backhaul Architecture 4. Proposed V5.2 Backhaul Architecture
****** V5.2 ****** IP ******* ****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC * * AN *---------------* SG *--------------* MGC *
****** ****** ******* ****** ****** *******
+-----+ +-----+ +-----+ +-----+
|V5.2 | (NIF) |V5.2 | |V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+ +-----+ +----------+ +-----+
| | | |V5UA| |V5UA | | | | |V5UA| |V5UA |
| | | +----+ +-----+ | | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP | |LAPV5| |LAPV5|SCTP| |SCTP |
skipping to change at page 10, line 25 skipping to change at page 10, line 28
| | | | IP + | IP | | | | | IP + | IP |
+-----+ +-----+----+ +-----+ +-----+ +-----+----+ +-----+
Figure 1 V5.2 Backhaul Architecture Figure 1 V5.2 Backhaul Architecture
AN - Access Network AN - Access Network
NIF - Nodal Interworking Function NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol SCTP - Stream Control Transmission Protocol
4.1. V5UA Message Header 4.1. V5UA Message Header
The original IUA message header needs to be modified for V5. The ori- The original IUA message header must be modified for V5UA. The origi-
ginal header for the integer formatted Interface Identifier is shown nal header for the integer formatted Interface Identifier is shown
below: below:
0 1 2 3 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 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 | | Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) | | Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 | | Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | Spare | | DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Original IUA Message Header Figure 2 Original IUA Message Header
For the V5 extension of the IUA Message Header, the Envelope Function V5UA extends the IUA Message Header by including the Envelope Function
Address (EFA) field is included in the Spare field. Below the V5UA Address (EFA) in the Spare field. The V5UA format for the integer for-
format for the integer formatted Interface Identifier is shown: matted Interface Identifier is shown below:
0 1 2 3 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 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 | | Tag (0x1) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Identifier (integer) | | Interface Identifier (integer) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x5) | Length=8 | | Tag (0x5) | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DLCI | EFA | | DLCI | EFA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 V5UA Message Header (Integer-based Interface identifier) Figure 3 V5UA Message Header (Integer-based Interface identifier)
The EFA identifies a C-path, which is a 13-bit number, ranging from 0 The EFA is defined by the V5 standard. It identifies a C-path, which
to 8191 (decimal). An EFA uniquely identifies one of the five V5.2 is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA uniquely
protocols, or an ISDN agent attached to an AN. The following list con- identifies one of the five V5.2 protocols, or an ISDN agent attached
tains the possible values for the EFA: to an AN. The following list contains the possible values for the EFA
as defined by V5:
Definition Value Definition Value
---------- ------ ---------- ------
ISDN_PROTOCOL 0 - 8175 ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176 PSTN_PROTOCOL 8176
CONTROL_PROTOCOL 8177 CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178 BCC_PROTOCOL 8178
PROT_PROTOCOL 8179 PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180 LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191 RESERVED 8181 - 8191
For MPH messages for which DLCI and EFA are not used, SAPI, TEI and For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA
EFA shall be set to ZERO and shall be ignored by the receiver. For all 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 other messages the DLCI SHALL be set as defined in the V5.2 standard
[2]. [2].
The Interface Identifier SHALL follow the naming conventions for the The Interface Identifier SHALL follow the naming conventions for the
Interface Identifier as defined below. Interface Identifier as defined below.
4.2. V5 Naming Conventions for Interface Identifier 4.2. V5 Naming Conventions for Interface Identifier
The V5 standard demands that V5 System Management keeps track of the 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- 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 tion switching and bearer channel allocation on the V5 links, it is
skipping to change at page 12, line 15 skipping to change at page 12, line 16
association with a specific link. Since no naming convention exists, association with a specific link. Since no naming convention exists,
there is no guarantee that a C-channel is actually located at the link 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 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 receives reports of the status of all links, and it defines a link
identification procedure to ensure that AN and LE are referencing the identification procedure to ensure that AN and LE are referencing the
same link when they address a link with a Link Control Protocol mes- same link when they address a link with a Link Control Protocol mes-
sage. sage.
It would clearly be against the concept of V5.2 if there was no clear 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 association between E1 links and channels. To solve this problem a
naming convention MUST be used to ensure this association: naming convention MUST be used for V5UA.
The format of the integer formatted Interface Identifier is shown The format of the integer formatted Interface Identifier is shown
below: below:
0 1 2 3 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 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 | Chnl ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Identifier - Identifier for an E1 link on the SG (27 bits). Must 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 be unique on the SG. This Link Identifier MUST match the Link
Identifier used in the Link Management Messages defined later in Identifier used in the Link Management Messages defined later in
this document. this document.
Chnl ID - Channel Identifier (5 bits). This is equal to the time-slot 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 number of the addressed time slot. Possible values are 15, 16 and
31 representing the possible time slots for C-channels on a V5 31 representing the possible time slots for C-channels on a V5
interface. For Link Management Messages the Chnl ID must be set interface. For Link Management Messages the Chnl ID MUST be set
to 0. All other values are reserved for future use. to 0. All other values are reserved for future use.
The text formatted interface identifier shall be coded as the hex If used, the text formatted interface identifier SHALL be coded as the
representation of the integer formatted interface identifier, written hex representation of the integer formatted interface identifier,
as a variable length string. written as a variable length string.
4.3. V5 Additions to IUA Boundary Primitives 4.3. V5 Additions to IUA Boundary Primitives
Some primitives for the V5 interface boundaries are similar to the Some primitives for the V5 interface boundaries are similar to the
Q.921/Q.931 boundary primitive messages defined in IUA, but they need 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- 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 tinguish between these two message types by means of the Message Class
parameter. parameter.
For all V5 interface boundary primitives, a new Message Class is For all V5 interface boundary primitives, a new Message Class is
introduced: introduced:
9 V5 Boundary Primitives Transport 9 V5 Boundary Primitives Transport
Messages (V5PTM) Messages (V5PTM)
Similar to IUA, other valid message classes for V5UA are: Other valid message classes for V5UA, which are also used by IUA, are:
0 Management (MGMT) Message 0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages 3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages 4 ASP Traffic Maintenance (ASPTM) Messages
Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM mes- Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM mes-
sages are: sages are:
1 Data Request Message (MGC -> SG) 1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC) 2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG) 3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC) 4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG) 5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC) 6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC) 7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG) 8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC) 9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC) 10 Release Indication (SG -> MGC)
All these messages are defined similar to the QPTM messages. In addi- All these messages are defined similarly to the QPTM messages.
tion, new boundary primitive messages are defined:
In addition, new boundary primitive messages are defined:
11 Link Status Start Reporting (MGC -> SG) 11 Link Status Start Reporting (MGC -> SG)
12 Link Status Stop Reporting (MGC -> SG) 12 Link Status Stop Reporting (MGC -> SG)
13 Link Status Indication (SG -> MGC) 13 Link Status Indication (SG -> MGC)
14 Sa-Bit Set Request (MGC -> SG) 14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Confirm (SG -> MGC) 15 Sa-Bit Set Confirm (SG -> MGC)
16 Sa-Bit Status Request (MGC -> SG) 16 Sa-Bit Status Request (MGC -> SG)
17 Sa-Bit Status Indication (SG -> MGC) 17 Sa-Bit Status Indication (SG -> MGC)
18 Error Indication (SG -> MGC) 18 Error Indication (SG -> MGC)
4.4. Link Status Messages (Start Reporting, Stop Reporting, Indica- 4.4. Link Status Messages (Start Reporting, Stop Reporting, Indica-
tion) tion)
The Link Status Messages are used between V5 System Management on the 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 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- link. This is required whether or not the E1 link carries C-channels.
ries C-channels.
All Link Status Messages contain the V5UA Message Header. The Link All Link Status Messages contain the V5UA Message Header. The Link
Identifier portion of the Interface Identifier identifies the physical Identifier portion of the Interface Identifier identifies the physical
link on the SG addressed by the message. For all link status messages, 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 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- 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 cance only, and is coordinated between the SG and MGC. It MUST be
for every V5 link on the SG. unique for every V5 link on the SG.
The Link Status Start Report Message is used by V5 System Management As defined by the V5 standards, V5 System Management must know the
to request from L1 FSM to start reporting the status of a particular status of the links on all active V5 interfaces. The Link Status
link, since V5 System Management on the MGC must know the status of Start Reporting Message is used by V5 System Management on the MGC to
the links on all active V5 interfaces. This message is also an indica- request that the L1 FSM on the SG starts reporting the status of a
tion for the SG that this link is located on a now active interface. particular link.
V5 system management shall send this Message on interface activation V5 system management SHALL send this Message on interface activation
for all links on the interface. The SG will respond immediately to for all links on the interface. The SG SHALL respond immediately to
this request with a Link Status Indication message, and it will then this request with a Link Status Indication message, and it SHALL then
send a Link Status Indication message on all subsequent changes of the 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 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 is on an active interface or not, this message SHALL always be sent on
interface startup. 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 To stop this reporting of the status of a link, e.g. at interface
deactivation, System Management sends a Link Status Stop Reporting deactivation, System Management sends a Link Status Stop Reporting
Message to the L1 FSM. The SG will then immediately stop reporting the 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 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. 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 is Since there is no other way for the SG to know that an interface is
deactivated, this message shall be sent on interface deactivation for deactivated, this message SHALL be sent on interface deactivation for
all links on the interface. On reception of this message, the SG may all links on the interface. On reception of this message, the SG SHALL
take L2 down on this link. take L2 down on this link.
The Link Status Start/Stop Report Messages contain the common message If the L1 FSM in the SG receives a Link Status Stop Reporting Message
header followed by the V5UA message header. They do not contain any for a link that is not active (the link status is not reported to Sys-
addition parameters. tem Management), the SG SHALL ignore the message.
The Link Status Start/Stop Reporting Messages contain the common mes-
sage 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 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 response to a Link Status Start Reporting Message to indicate the
the particular link. After a Link Status Start Report Message has been status of the particular link. After a Link Status Start Reporting
received by the L1 FSM, it will automatically send a Link Status Indi- Message has been received by the L1 FSM, it SHALL automatically send a
cation Message every time the status of the particular link changes. Link Status Indication Message every time the status of the particular
It will not stop this reporting until it receives a Link Status Stop link changes. It SHALL not stop this reporting until it receives a
Report Message from System Management. Link Status Stop Report Message from System Management.
The Link Status Indication Message contains the common message header The Link Status Indication Message contains the common message header
followed by the V5UA message header. In addition it contains the fol- followed by the V5UA message header. In addition it contains the fol-
lowing parameter: lowing link status parameter:
0 1 2 3 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 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 | | Tag (0x11) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Status | | Link Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Link Status are shown in the following table: The valid values for Link Status are shown in the following table:
Define Value Description Define Value Description
OPERATIONAL 0x0 Link is in operation
NON-OPERATIONAL 0x1 Link is not in operation OPERATIONAL 0x0 Link operational
NON-OPERATIONAL 0x1 Link not operational
4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request, 4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request,
Status Indication) Status Indication)
The Sa-Bit Messages are used between V5 System Management in the MGC 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 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 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. Sa7 bit that is used for the Link Identification procedure as
described by the V5 standards [3].
All Sa-Bit Messages contain the V5UA message header. The Link Identif- All Sa-Bit Messages SHALL contain the V5UA message header. The Link
ier portion of the Interface Identifier identifies the physical link Identifier portion of the Interface Identifier identifies the physical
on the SG addressed by the message. For all link status messages, the link on the SG addressed by the message. For all link status messages,
Chnl ID shall be set to '0' and shall be ignored by the receiver. 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- The Link Identifier MUST be the same as used in the Interface Identif-
ier to identify on which link a C-channel is located. 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- 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 value of the Sa7 bit in fied Sa-Bit on the defined link. The value of the Sa7 bit in normal
normal operation is ONE. For the Link Identification procedure, it is operation is ONE. For the Link Identification procedure, it is set to
set to ZERO. 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- 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. 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 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 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 FSM. The Sa-Bit Status Request message for the Sa7 bit corresponds to
in which the current setting of the bit will be reported. 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: All Sa-Bit Messages contain the following additional parameter:
0 1 2 3 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 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 | | Tag (0x12) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIT ID | Bit Value | | BIT ID | Bit Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Bit Value are shown in the following table: The valid values for Bit Value are shown in the following table:
Define Value Description Define Value Description
ZERO 0x0 Bit is set to ZERO ZERO 0x0 Bit value ZERO
ONE 0x1 Bit is set to ONE ONE 0x1 Bit value ONE
The valid value for BIT ID is shown in the following table: The valid value for BIT ID is shown in the following table:
Define Value Description Define Value Description
Sa7 0x7 Addresses the Sa7 bit Sa7 0x7 Addresses the Sa7 bit
There are no other valid values for V5UA. All other values are There are no other valid values for V5UA. All other values are
reserved for future use. reserved for future use.
For the Sa-Bit Status Request and Set Confirm messages, the BIT Value For the Sa-Bit Status Request and Set Confirm messages, the BIT Value
should be set to '0' by the sender and should be ignored by the SHALL be set to '0' by the sender and SHALL be ignored by the
receiver. receiver.
4.6. Error Indication Message 4.6. Error Indication Message
The Error Indication Message is used between the V5 stack on the SG 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 and the V5 System Management in the MGC to indicate an error condition
of the SG. at the SG.
The only valid reason for the Error Indication Message is Overload. The only valid reason for the Error Indication Message is Overload.
The SG shall issue such an Error Indication with reason Overload for a The SG SHOULD issue such an Error Indication with reason Overload for
C-channel in case it is not able to process all Layer 3 messages on a C-channel if it is not able to process all Layer 3 messages on this
this C-channel in a timely manner (overload condition of the C- C-channel in a timely manner (overload condition of the C-channel).
channel).
The Error Indication message contain the V5UA message header. The The Error Indication message SHALL contain the V5UA message header.
Interface Identifiers 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 contain the following additional parame- 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 parame-
ter: ter:
0 1 2 3 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 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 | | Tag (0x13) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason | | Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 9 skipping to change at page 17, line 32
OVERLOAD 0x1 C-channel is in overload state OVERLOAD 0x1 C-channel is in overload state
There are no other valid values for V5UA. All other values are There are no other valid values for V5UA. All other values are
reserved for future use. reserved for future use.
5. Procedures 5. Procedures
5.1. V5 Layer 1 failure 5.1. V5 Layer 1 failure
The normal way to handle a Layer 1 failure is described in the V5 The normal way to handle a V5 Layer 1 failure is described in the V5
standards[2,3] as follows: standards[2,3] as follows:
- The L1 FSM detects the Layer 1 failure. It reports this to V5 - The L1 FSM detects the V5 Layer 1 failure. It reports this to
System management by sending a MPH-DI primitive for the V5 System management by sending a MPH-DI primitive for the
affected link. affected link.
- V5 System management notifies Layer 2 of the Layer 1 outage by - V5 System management notifies V5 Layer 2 of the V5 Layer 1
sending a MPH-Layer_1 Failure Ind primitive. outage by sending a MPH-Layer_1 Failure Ind primitive.
Since Layer1/2 and V5 System Management are no longer co-located in Since V5 Layer1/2 and V5 System Management are no longer co-located in
the backhaul architecture, it does not make sense to notify Layer 2 the backhaul architecture, it does not make sense to notify V5 Layer 2
about Layer 1 failure via V5 system management. Instead Layer 2 shall about V5 Layer 1 failure via V5 system management. Instead V5 Layer 2
be notified directly by Layer 1 on the SG. Layer 1 shall still report SHALL be notified directly by V5 Layer 1 on the SG. V5 Layer 1 SHALL
the outage to V5 system management by sending an MPH-DI primitive, but report the outage to V5 system management by sending a Link Status
V5 system management shall not send a MPH-Layer_1 Failure Ind primi- Indication message with status NON-OPERATIONAL, corresponding to an
tive to Layer 2. 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 5.2. Loss of V5UA peer
If SCTP failure is detected or the heartbeat is lost, the following If SCTP failure is detected or the heartbeat is lost, the following
procedure shall be performed: procedure SHALL be performed:
When loss of V5UA peer is reported to the V5UA layer, the ASP shall 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- behave as if it had received a Link Status Indication (non-
operational) for all links on this SG. operational) for all links on this SG.
The ASP shall attempt to reestablish the connection continuously. When The ASP SHALL attempt to reestablish the connection continuously. When
the connection is reestablished, the ASP shall send a Link Status the connection is reestablished, the ASP SHALL send a Link Status
Start Reporting message to the SG for all links on active V5 inter- Start Reporting message to the SG for all links on active V5 inter-
faces on the SG. faces on the SG.
An example for the message flow in case of reestablishment of the con- An example for the message flow for reestablishment of the connection
nection is shown below for one active link on the SG: is shown below for one active link on the SG:
ASP SG ASP SG
| | | |
| -------- Link Status Start Reporting ---------> | | -------- Link Status Start Reporting ---------> |
| | | |
| <------ Link Status Ind (operational) --------- | | <------ Link Status Ind (operational) --------- |
| | | |
In case the association can be reestablished before the V5UA layer If the association can be reestablished before the V5UA layer is noti-
gets notified, communication should proceed as usual and no other fied, communication SHALL proceed as usual and no other action SHALL
action shall be taken by the ASP. be taken by the ASP.
5.3. C-channel overload on SG 5.3. C-channel overload on SG
If the SG detects an overload condition on a C-channel, it shall indi- If the SG detects an overload condition on a C-channel, it SHOULD
cate this by sending an Error Indication message, reason Overload to indicate this by sending an Error Indication message, reason Overload
the MGC. The MGC may then take appropriate actions to clear this over- to the MGC. The MGC SHOULD then take appropriate actions to clear this
load condition. overload condition.
The SG shall resent the Error Indication message with reason Overload The SG SHALL resend the Error Indication message with reason Overload
as long as the overload condition persist. A recommended interval for as long as the overload condition persist. An interval of 120 seconds
resent of this message is 120 seconds. for resend of this message is RECOMMENDED.
6. Examples 6. Examples
6.1. Link Identification Procedure (successful) 6.1. Link Identification Procedure (successful)
A message flow example for an LE initiated Link Identification pro- The Link Identification Procedures themselves are described by the
cedure is shown below. An active association between ASP and SG is V5.2 standard [3].
established prior to the following messages flows, and the V5 inter-
face is already activated: 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 ASP SG
| | | |
| ------ Data Request (LnkCtrl: FE-IDReq) ------> | | ------ Data Request (LnkCtrl: FE-IDReq) ------> |
| <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- | | <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- |
| | | |
| <---- Data Indication (LnkCtrl: FE-IDAck) ----- | | <---- Data Indication (LnkCtrl: FE-IDAck) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> | | ---- Data Request (LnkCtrl Ack: FE-IDAck) ----> |
| | | |
| ------ Sa-Bit Status Request ( Sa7 ) ---------> | | ------ Sa-Bit Status Request ( Sa7 ) ---------> |
| <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- | | <--- Sa-Bit Status Indication ( Sa7, ZERO ) --- |
| | | |
| ------- Data Request (LnkCtrl: FE-IDRel) -----> | | ------- Data Request (LnkCtrl: FE-IDRel) -----> |
| <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- | | <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- |
| | | |
The next example again shows a Link Identification procedure, but this The next example also shows a Link Identification procedure, but this
time initiated by the AN. Again the ASP association and the V5 inter- time initiated by the AN. Again the ASP association and the V5 inter-
face are already in service: face are already in service:
ASP SG ASP SG
| | | |
| <---- Data Indication (LnkCtrl: FE-IDReq) ----- | | <---- Data Indication (LnkCtrl: FE-IDReq) ----- |
| -- Data Request (LnkCtrl Ack: FE-IDReq) ------> | | -- Data Request (LnkCtrl Ack: FE-IDReq) ------> |
| | | |
| ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> | | ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> |
skipping to change at page 19, line 26 skipping to change at page 20, line 7
| | | |
| <---- Data Indication (LnkCtrl: FE-IDRel) ----- | | <---- Data Indication (LnkCtrl: FE-IDRel) ----- |
| ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> | | ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> |
| | | |
| ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> | | ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> |
| <----------- Sa-Bit Set Conf (Sa 7) ----------- | | <----------- Sa-Bit Set Conf (Sa 7) ----------- |
| | | |
7. Security Considerations 7. Security Considerations
All security considerations applicable for IUA shall also be applica- The security considerations discussed for the 'Security Considerations
ble for V5UA. for SIGTRAN Protocols' [7] document apply to this document.
8. IANA Considerations 8. IANA Considerations
8.1. SCTP Payload Protocol Identifiers 8.1. SCTP Payload Protocol Identifiers
IANA has assigned a V5UA value for the Payload Protocol Identifier in IANA has assigned a V5UA value for the Payload Protocol Identifier in
the SCTP DATA chunk. The following SCTP Payload Protocol identifier is the SCTP DATA chunk. The following SCTP Payload Protocol identifier is
registered: registered:
V5UA "6" V5UA "6"
skipping to change at page 20, line 42 skipping to change at page 21, line 23
Q.921). Q.921).
[5] ETSI ETS 300 166 (08/1993) : Transmission and Multiplexing; Phy- [5] ETSI ETS 300 166 (08/1993) : Transmission and Multiplexing; Phy-
sical and electrical characteristic of hierarchical digital sical and electrical characteristic of hierarchical digital
interfaces (Standard is based on G.703). interfaces (Standard is based on G.703).
[6] ETSI ETS 300 167 (08/1993) : Transmission and Multiplexing; Func- [6] ETSI ETS 300 167 (08/1993) : Transmission and Multiplexing; Func-
tional characteristic of 2048 kbits/s interfaces (Standard is tional characteristic of 2048 kbits/s interfaces (Standard is
based on G.704, G.706). 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 10.2. Informative References
[7] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, [7] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al,
October 2000 October 2000
[8] RFC 2119, "Kay words for use in RFCs to Indicate Requirement Lev- [8] RFC 2119, "Key words for use in RFCs to Indicate Requirement Lev-
els", S. Bradner, March 1997 els", S. Bradner, March 1997
[9] <draft-rfc-editor-rfc2223bis-02.txt>, "Instructions to Request [9] <draft-rfc-editor-rfc2223bis-02.txt>, "Instructions to Request
for Comments (RFC) Authors", J.Reynolds, R. Braden, April 2002 for Comments (RFC) Authors", J.Reynolds, R. Braden, April 2002
(Work in Progress) (Work in Progress)
11. Author's Addresses 11. Author's Addresses
Dr. Eva Weilandt Tel +49 7545 96 7267 Dr. Eva Weilandt Tel +49 7545 96 7267
Nortel Networks Germany Email eva.weilandt@nortelnetworks.com Nortel Networks Germany Email eva.weilandt@nortelnetworks.com
skipping to change at page 21, line 24 skipping to change at page 22, line 4
Nortel Networks Email rsanjay@nortelnetworks.com Nortel Networks Email rsanjay@nortelnetworks.com
35 Davis Drive 35 Davis Drive
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
Neeraj Khanchandani Tel +1-919-991-2274 Neeraj Khanchandani Tel +1-919-991-2274
Nortel Networks Email neerajk@nortelnetworks.com Nortel Networks Email neerajk@nortelnetworks.com
35 Davis Drive 35 Davis Drive
Research Triangle Park, NC 27709 Research Triangle Park, NC 27709
USA USA
This Draft Expires in 6 months from May 2003
This Draft Expires in 6 months from June 2002
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/