draft-ietf-sigtran-v5ua-01.txt   draft-ietf-sigtran-v5ua-02.txt 
Internet Engineering Task Force Eva Weilandt Internet Engineering Task Force Eva Weilandt
INTERNET DRAFT Neeraj Khanchandani INTERNET DRAFT Neeraj Khanchandani
Fahir Ergincan
Sanjay Rao Sanjay Rao
Nortel Networks Nortel Networks
Expires in six months July 2001 Expires in six months February 2002
V5.2-User Adaption Layer (V5UA) V5.2-User Adaptation Layer (V5UA)
<draft-ietf-sigtran-v5ua-01.txt> <draft-ietf-sigtran-v5ua-02.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 2, line 22 skipping to change at page 2, line 22
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. SCTP Stream Management ....................................... 9 2. SCTP Stream Management ....................................... 9
3. Proposed V5.2 Backhaul Architecture .......................... 9 3. Proposed V5.2 Backhaul Architecture .......................... 9
3.1. V5UA Message Header ...................................... 10 3.1. V5UA Message Header ...................................... 10
3.2. V5 Naming Conventions for Interface Identifier ........... 11 3.2. V5 Naming Conventions for Interface Identifier ........... 11
3.3. V5 Additions to IUA Boundary Primitives .................. 12 3.3. V5 Additions to IUA Boundary Primitives .................. 12
3.4. Link Status Messages ..................................... 13 3.4. Link Status Messages ..................................... 13
3.5. Sa-Bit Messages .......................................... 14 3.5. Sa-Bit Messages .......................................... 14
4. Procedures ................................................... 15 3.6. Error Indication Message ................................. 15
4.1. V5 Layer 1 failure ....................................... 15 4. Procedures ................................................... 16
4.2. Loss of V5UA peer ........................................ 16 4.1. V5 Layer 1 failure ....................................... 16
4.2. Loss of V5UA peer ........................................ 17
4.3. C-channel overload on SG ................................. 17
5. Examples ..................................................... 17 5. Examples ..................................................... 17
5.1. Link Identification Procedure (successful) ............... 17 5.1. Link Identification Procedure (successful) ............... 18
6. IANA Considerations .......................................... 18 6. IANA Considerations .......................................... 19
6.1. SCTP Payload Protocol Identifier ......................... 18
7. Acknowledgements ............................................. 18
8. References ................................................... 19
9. Author's Addresses ........................................... 19
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 Adapation Layer ing over IP using a modified version of the ISDN User Adaption Layer
Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the neces- Protocol (IUAP) [1]. The V5UA builds on top of IUA defining the neces-
sary extensions to IUA for a V5.2 implementation. sary extensions to IUA for a V5.2 implementation.
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) analog to the implementation of the ISDN Q.921 User
Adaption Layer (IUA) as described in [1]. Adaption Layer (IUA) as described in [1].
skipping to change at page 7, line 28 skipping to change at page 7, line 28
1.4. TEI Management for BRI over V5UA 1.4. TEI Management for BRI over V5UA
Dynamic TEI Management for BRI over V5 shall be located on the MGC. Dynamic TEI Management for BRI over V5 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 should follow the model as defined
for IUAP. for 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 ? (tbd). 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 support V5.2 requires the introduction of new boun-
dary primitives for the Q.921/Q.931 boundary in accordance with the dary primitives for the Q.921/Q.931 boundary in accordance with the
definitions in V5.2. definitions in V5.2.
V5.2 reuses the primitives from the Q.921/Q.931 boundary: the DL-DATA V5.2 reuses the primitives from the Q.921/Q.931 boundary: the DL-DATA
skipping to change at page 8, line 21 skipping to change at page 8, line 21
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 contrary to ISDN, the V5 standards demand that V5.2 system manage-
ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ- 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 may be physically
separated in a V5 backhaul scenario, V5UA needs to support some ser- separated in a V5 backhaul scenario, V5UA needs to support some ser-
vice for the communication between these two entities. Specifically vice for the communication between these two entities. Specifically
these services include an indication of the status of a link, and mes- these services include an indication of the status of a link, and mes-
sages to support link identification procedure. sages to support link identification procedure.
The new messages 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 message 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 to take the link in service for use 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 also
start reporting the status of the V5 link to the GWC. start reporting the status of the V5 link to the GWC.
MPH-LINK STATUS STOP REPORTING MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING message 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 to take the link out of service for use on a V5
interface. On reception of this message L1 FSM on the SG shall also interface. On reception of this message L1 FSM on the SG shall also
stop reporting the status of the V5 link to the GWC. stop reporting the status of the V5 link to the GWC.
MPH-LINK STATUS INDICATION MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION message is used by L1 FSM on the Sig- The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the Sig-
nalling Gateway to report the status (operational/non-operational) of nalling Gateway to report the status (operational/non-operational) of
a V5 link to V5 system management. a V5 link to V5 system management.
MPH-SA-BIT SET MPH-SA-BIT SET
The MPH-SA-BIT SET message 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. For V5 this message will be used for the bit on the requested link, or to report the successful setting or
Link Identification procedure to set or reset the value of the Sa7 resetting of this bit back to system management. For V5 this message
bit. This would be equivalent to the MPH-ID and MPH-NOR primitves in will be used for the Link Identification procedure to set/reset the
V5.2. value of the Sa7 bit, or to confirm the successful setting of the Sa
bit. The MPH-SA BIT SET REQUEST would be equivalent to the MPH-ID and
MPH-SA-BIT SET ACK MPH-NOR primitves in V5.2.
The MPH-SA-BIT SET ACK message is used by L1 FSM in the SG to indicate
to system management in response to a MPH-SA-BIT-SET message. The mes-
sage indicates that the setting of the Sa bit has been performed suc-
cessfully.
MPH-SA-BIT STATUS MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS messages are used between system management in The MPH-SA-BIT STATUS primitives are used between system management in
the MGC and L1 FSM in the SG to request reporting of the status of a the MGC and L1 FSM in the SG to request reporting of the status of a
specified Sa bit on the requested link, or to report the status of specified Sa bit on the requested link, or to report (indicate) the
this bit back to system management. For V5 these messages will be
used for the Link identification procedure to request or report the status of this bit back to system management. For V5 these messages
status of the Sa7 bit. This would be equivalent to the MPH-IDR, MPH- will be used for the Link identification procedure to request or
IDI or MPH-Elg primitive in V5.2. report the status of the Sa7 bit. This would be equivalent to the
MPH-IDR, MPH-IDI or MPH-Elg primitive in V5.2.
MDL-ERROR INDICATION
The MDL-ERROR INDICATION primitive is used to indicate an error condi-
tion to V5 System Management. The only valid reason for this primi-
tive is 'Overload', indicating an overload condition of the c-channel
on the SG. This reason is not defined in the V5/Q.921 standards.
2. SCTP Stream Management 2. SCTP Stream Management
It is recommended that one SCTP stream be used for BCC, Link Control, It is recommended that one SCTP stream be used for BCC, Link Control,
Common Control and PSTN protocol on a specific c-channel. It is Common Control and PSTN protocol on a specific c-channel. It is
recommended to use a separate SCTP stream for Protection protocol on a recommended to use a separate SCTP stream for Protection protocol on a
specific c-channel. It is also recommended to use one SCTP stream for specific c-channel. It is also recommended to use one SCTP stream for
all ISDN user ports on a specific c-channel. One single stream should 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. not be used to carry data of more than one c-channel.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
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| 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 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 to 8191 (decimal). An EFA uniquely identifies one of the five V5.2
protocols, or an ISDN agent attached to an AN. The following list con- protocols, or an ISDN agent attached to an AN. The following list con-
tains the possible values for the EFA: tains the possible values for the EFA:
Definition Value Definition Value
skipping to change at page 11, line 20 skipping to change at page 11, line 20
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 for which DLCI and EFA are not used, SAPI, TEI and
EFA shall be set to ZERO and shall be ignored by the receiver. For all 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 other messages the DLCI shall be set as defined in the V5.2 standard
[2]. [2].
The text formatted Interface Identifier SHALL not be supported due to The Interface Identifier SHALL follow the naming conventions for the
the neccessary naming conventions for the Interface Identifier. Interface Identifier as defined below.
3.2. V5 Naming Conventions for Interface Identifier 3.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
neccessary that system management has the full picture of the signal- neccessary that system management has the full picture of the signal-
ling and bearer channels located on each link. ling and bearer channels located on each link.
The IUA protocol identifies C-Channels by endpoints without a defined The IUA protocol identifies C-Channels by endpoints without a defined
skipping to change at page 12, line 16 skipping to change at page 12, line 16
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
representation of the integer formatted interface identifier, written
as a variable length string.
3.3. V5 Additions to IUA Boundary Primitives 3.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:
skipping to change at page 13, line 6 skipping to change at page 13, line 11
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 similar to the QPTM messages. In addi-
tion, Layer 1 boundary primitive messages are defined: tion, Layer 1 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 Value (MGC -> SG) 14 Sa-Bit Set Request (MGC -> SG)
15 Sa-Bit Set Ack (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)
3.4. Link Status Messages (Start Reporting, Stop Reporting, Indica- 3.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 regardless of whether or not the E1 link car-
ries 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
skipping to change at page 14, line 35 skipping to change at page 14, line 40
| 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 OPERATIONAL 0x0 Link is in operation
NON-OPERATIONAL 0x1 Link is not in operation NON-OPERATIONAL 0x1 Link is not in operation
3.5. Sa-Bit Messages (Set, Set Ack, Status Request, Status Indica- 3.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request,
tion) 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 in the V5 defined Link Identification procedure.
All Sa-Bit Messages contain the V5UA message header. The Link Identif- All Sa-Bit Messages contain the V5UA message header. The Link Identif-
ier portion of the Interface Identifier identifies the physical link ier portion of the Interface Identifier identifies the physical link
on the SG addressed by the message. For all link status messages, the 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. 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 message is used to set the value of the specified Sa- The Sa-Bit Set Request message is used to set the value of the speci-
Bit on the defined link. For V5, the value of the Sa7 bit in normal fied Sa-Bit on the defined link. For V5, the value of the Sa7 bit in
operation is ONE. For the Link Identification procedure, it is set to normal operation is ONE. For the Link Identification procedure, it is
ZERO. set to ZERO.
The SG MUST answer a Sa-Bit Set message with a Sa-Bit Set Ack message The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Con-
when the setting of the bit is complete. firm message when the setting of the bit is complete.
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. L1 FSM answers this request by a Sa-Bit Status Indication message
in which the current setting of the bit will be reported. in which the current setting of the bit will be reported.
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
skipping to change at page 15, line 39 skipping to change at page 15, line 44
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 Ack 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 should be set to '0' by the sender and should be ignored by the
receiver. receiver.
3.6. Error Indication Message
The Error Indication Message is used between the V5 stack on the SG
and the V5 System Management in the MGC to indicate an error condition
of the SG.
The only valid reason for the Error Indication Message is Overload.
The SG shall issue such an Error Indication with reason Overload for a
c-channel in case 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 contain the V5UA message header. The
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-
ter:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x13) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Error Reason are shown in the following table:
Define Value Description
OVERLOAD 0x1 C-Channel is in overload state
There are no other valid values for V5UA. All other values are
reserved for future use.
4. Procedures 4. Procedures
4.1. V5 Layer 1 failure 4.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 Layer 1 failure is described in the V5
standards[2,3] as follows: standards[2,3] as follows:
- L1FSM detects the Layer 1 failure. It reports this to V5 System - L1FSM detects the Layer 1 failure. It reports this to V5 System
management by sending a MPH-DI primitive for the affected link. management by sending a MPH-DI primitive for the affected link.
skipping to change at page 16, line 22 skipping to change at page 17, line 15
be notified directly by Layer 1 on the SG. Layer 1 shall still report be notified directly by Layer 1 on the SG. Layer 1 shall still report
the outage to V5 system management by sending an MPH-DI primitive, but the outage to V5 system management by sending an MPH-DI primitive, but
V5 system management shall not send a MPH-Layer_1 Failure Ind primi- V5 system management shall not send a MPH-Layer_1 Failure Ind primi-
tive to Layer 2. tive to Layer 2.
4.2. Loss of V5UA peer 4.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 detected, the SG will start a timer T1(r) When loss of V5UA peer is reported to the V5UA layer, the ASP shall
(tbd). If the connection is reestablished before T1(r) expires, com- behave as if it had received a Link Status Indication (non-
munication should proceed as usual. operational) for all links on this SG.
After expiry of timer T1(r) and if the connection can not be reesta-
blished, the SG shall behave as if it had received a Link Status Stop
Reporting message for all links connected to this SG.
In case of loss of the V5UA peer, the ASP will start a timer T2(r)
(tbd). This timer shall expire earlier than T1(r) in the SG. The ASP
will continuously try to reestablish the connection. In case it is
successful before T2(r) expires, communication should proceed as
usual.
After expiry of timer T2(r) and if the connection can not be reesta-
blished, the ASP shall behave as if it had received a Link Status
Indication (non-operational) for all links on this SG. The ASP shall
proceed in attempting to reestablish the connection.
When the connection is reestablished after timer T2(r) has expired, The ASP shall attempt to reestablish the connection continuously. When
the ASP shall send a Link Status Start Reporting message to the SG for the connection is reestablished, the ASP shall send a Link Status
all links on active V5 interfaces on the SG. Start Reporting message to the SG for all links on active V5 inter-
faces on the SG.
An example for the message flow in case of reestablishment of the con- An example for the message flow in case of reestablishment of the con-
nection is shown below for one active link on the SG: nection 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 (op) --------------- | | <--------- Link Status Ind (op) --------------- |
| | | |
In case the association can be reestablished before the V5UA layer
gets notified, communication should proceed as usual and no other
action shall be taken by the ASP.
4.3. C-channel overload on SG
If the SG detects an overload condition on a c-channel, it shall indi-
cate this by sending an Error Indication message, reason Overload to
the MGC. The MGC may then take appropriate actions to clear this over-
load condition.
The SG shall resent the Error Indication message with reason Overload
as long as the overload condition persist. A recommended interval for
resent of this message is 120 seconds.
5. Examples 5. Examples
5.1. Link Identification Procedure (successful) 5.1. Link Identification Procedure (successful)
An example for the message flow for an LE initiated Link Identifica- An example for the message flow for an LE initiated Link Identifica-
tion procedure is shown below. An active association between ASP and tion procedure is shown below. An active association between ASP and
SG is established prior to the following messages flows, and the V5 SG is established prior to the following messages flows, and the V5
interface is already activated: interface is already activated:
ASP SG ASP SG
| | | |
| ------ Data Request (LnkCtrl: FE-IDReq) ------> | | ------ Data Request (LnkCtrl: FE-IDReq) ------> |
| <-------------- Data Indication --------------- | | <-- Data Indication (LnkCtrl Ack: FE-IDReq) --- |
| | | |
| <------- Data Request (LnkCtrl: FE-IDAck) ----- | | <---- Data Indication (LnkCtrl: FE-IDAck) ----- |
| ---------------- Data Indication -------------> | | ---- 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 --------------- | | <--- Data Indication (LnkCtrl Ack: FE-IDRel) -- |
| | | |
The next example again shows a Link Identification procedure, but this The next example again 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 Request (LnkCtrl: FE-IDReq) ------ | | <---- Data Indication (LnkCtrl: FE-IDReq) ----- |
| ---------------- Data Indication -------------> | | -- Data Request (LnkCtrl Ack: FE-IDReq) ------> |
| | | |
| ---------- Sa-Bit Set ( Sa7, ZERO ) ----------> | | ---------- Sa-Bit Set Req ( Sa7, ZERO ) ------> |
| <--------- Sa-Bit Set Ack (Sa7) --------------- | | <--------- Sa-Bit Set Conf (Sa7) -------------- |
| | | |
| ------- Data Request (LnkCtrl: FE-IDAck) -----> | | ------- Data Request (LnkCtrl: FE-IDAck) -----> |
| <----------------- Data Indication -----------> | | <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- |
| | | |
| <------ Data Request (LnkCtrl: FE-IDRel) ------ | | <---- Data Indication (LnkCtrl: FE-IDRel) ----- |
| ---------------- Data Indication -------------> | | ---- Data Request (LnkCtrl Ack: FE-IDRel) ----> |
| | | |
| ------------ Sa-Bit Set ( Sa7, ONE ) ---------> | | ------------ Sa-Bit Set Req ( Sa7, ONE ) -----> |
| <----------- Sa-Bit Set Ack (Sa 7) ------------ | | <----------- Sa-Bit Set Conf (Sa 7) ----------- |
| | | |
6. IANA Considerations 6. IANA Considerations
6.1. SCTP Payload Protocol Identifiers 6.1. SCTP Payload Protocol Identifiers
A request will be made to IANA to assign an V5UA value for the Payload A request will be made to IANA to assign an V5UA value for the Payload
Protocol Identifier in SCTP Payload Data chunk. The following SCTP Protocol Identifier in SCTP Payload Data chunk. The following SCTP
Payload Protocol Identifier will be registered: Payload Protocol Identifier will be registered:
V5UA "?" V5UA "6"
The SCTP Payload Protocol Identifier is included in each SCTP Data The SCTP Payload Protocol Identifier is included in each SCTP Data
chunk, to indicate which protocol the SCTP is carrying. This Payload chunk, to indicate which protocol the SCTP is carrying. This Payload
Protocol Identifier is not directly used by SCTP but MAY be used by Protocol Identifier is not directly used by SCTP but MAY be used by
certain network entities to identify the type of information being certain network entities to identify the type of information being
carried in a Data chunk. carried in a Data chunk.
The User Adaptation peer MAY use the Payload Protocol Identifier as a The User Adaptation peer MAY use the Payload Protocol Identifier as a
way of determining additional information about the data being way of determining additional information about the data being
presented to it by SCTP. presented to it by SCTP.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Milos Pujic, Graeme Currie, Berthold The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme
Jaekle for their valuable comments and suggestions. Currie, Berthold Jaekle for their valuable comments and suggestions.
8. References 8. References
[1] ISDN Q.921-User Adaptation Layer RFC 3057 [1] ISDN Q.921-User Adaptation Layer RFC 3057
[2] EN 300 324-1 (1999): V interfaces at the digital Local Exchange [2] EN 300 324-1 (1999): V interfaces at the digital Local Exchange
(LE); V5.1 interface for the support of Access Network (AN); Part (LE); V5.1 interface for the support of Access Network (AN); Part
1: V5.1 interface specification. 1: V5.1 interface specification.
[3] EN 300 347-1 (1999): V interfaces at the digital Local Exchange [3] EN 300 347-1 (1999): V interfaces at the digital Local Exchange
skipping to change at page 19, line 48 skipping to change at page 20, line 25
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
Dr. Fahir Ergincan Tel +1-613-763-4929 This Draft Expires in 6 months from February,2002
Nortel Networks Email fahir@nortelnetworks.com
100 Constellation Crecent
Nepean, ON K2G6J8
Canada
This Draft Expires in 6 months from July,2001
 End of changes. 

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