draft-ietf-sigtran-v5ua-04.txt   rfc3807.txt 
Internet Engineering Task Force E. Weilandt Network Working Group E. Weilandt
INTERNET DRAFT N. Khanchandani Request for Comments: 3807 N. Khanchandani
S. Rao Updates: 3057 S. Rao
Nortel Networks Category: Standards Track Nortel Networks
June 2004
Expires in six months May 2003
V5.2-User Adaptation Layer (V5UA) V5.2-User Adaptation Layer (V5UA)
<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 specifies an Internet standards track protocol for the
provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Task Official Protocol Standards" (STD 1) for the standardization state
Force (IETF), its areas, and its working groups. Note that other and status of this protocol. Distribution of this memo is unlimited.
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004).
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 the backhauling of V5.2
over IP using the Stream Control Transmission Protocol (SCTP). This messages over IP using the Stream Control Transmission Protocol
protocol may be used between a Signaling Gateway (SG) and a Media (SCTP). This protocol may be used between a Signaling Gateway (SG)
Gateway controller (MGC). It is assumed that the SG receives V5.2 sig- and a Media Gateway controller (MGC). It is assumed that the SG
naling over a standard V5.2 interface. receives V5.2 signaling over a standard V5.2 interface.
This document builds on top of the ISDN User Adaptation Layer Protocol This document builds on the ISDN User Adaptation Layer Protocol (RFC
(RFC 3057). It defines all necessary extensions to the IUA Protocol 3057). It defines all necessary extensions to the IUA Protocol
needed for the V5UA protocol implementation. needed for the V5UA protocol implementation.
Table of Contents Table of Contents
1. Introduction ................................................. 2
1.1. Scope .................................................. 3
1.2. Terminology ............................................ 3
1.3. V5.2 Overview .......................................... 5
1.4. Distribution of responsibilities between MGC and SG .... 7
1.5. Client/Server Model .................................... 7
1.6. Addition to boundary primitives ........................ 7
1.6.1. V5 specific boundary primitives ................ 7
2. Conventions .................................................. 9
3. SCTP Stream Management ....................................... 10
4. Proposed V5.2 Backhaul Architecture .......................... 10
4.1. V5UA Message Header .................................... 11
4.2. V5 Naming Conventions for Interface Identifier ......... 12
4.3. V5 Additions to IUA Boundary Primitives ................ 13
4.4. Link Status Messages ................................... 14
4.5. Sa-Bit Messages ........................................ 16
4.6. Error Indication Message ............................... 17
5. Procedures ................................................... 18
5.1. V5 Layer 1 failure ..................................... 18
5.2. Loss of V5UA peer ...................................... 19
5.3. C-channel overload on SG ............................... 19
6. Examples ..................................................... 20
6.1. Link Identification Procedure (successful) ............. 20
7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21
8.1. SCTP Payload Protocol Identifier ....................... 21
8.2. V5UA Port Number ....................................... 22
9. Acknowledgements ............................................. 22
10. References ................................................... 22
10.1. Normative References ................................... 22
10.2. Informative References ................................. 23
11. Authors' Addresses ........................................... 23
12. Full Copyright Statement ..................................... 24
1. Introduction ................................................. 3
1.1. Scope .................................................... 3
1.2. Terminology .............................................. 3
1.3. V5.2 Overview ............................................ 5
1.4. Distribution of responsibilities between MGC and SG ...... 7
1.5. Client/Server Model ...................................... 7
1.6. Addition to boundary primitives .......................... 7
1.6.1. V5 specific boundary primitives ...................... 7
2. Conventions .................................................. 9
3. SCTP Stream Management ....................................... 9
4. Proposed V5.2 Backhaul Architecture .......................... 10
4.1. V5UA Message Header ...................................... 10
4.2. V5 Naming Conventions for Interface Identifier ........... 11
4.3. V5 Additions to IUA Boundary Primitives .................. 12
4.4. Link Status Messages ..................................... 13
4.5. Sa-Bit Messages .......................................... 15
4.6. Error Indication Message ................................. 16
5. Procedures ................................................... 17
5.1. V5 Layer 1 failure ....................................... 17
5.2. Loss of V5UA peer ........................................ 18
5.3. C-channel overload on SG ................................. 18
6. Examples ..................................................... 18
6.1. Link Identification Procedure (successful) ............... 18
7. Security Considerations ...................................... 20
8. IANA Considerations .......................................... 20
8.1. SCTP Payload Protocol Identifier ......................... 20
8.2. V5UA Port Number ......................................... 20
9. Acknowledgements ............................................. 20
10. References .................................................. 20
10.1. Normative References .................................... 20
10.2. Informative References .................................. 21
11. Author's Addresses .......................................... 21
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
ing over IP using a modified version of the ISDN User Adaptation Layer messaging over IP using a modified version of the ISDN User
Protocol (IUAP) [1]. V5UA builds on top of IUA, defining the necessary Adaptation Layer Protocol (IUAP) [1]. V5UA builds on top of IUA,
extensions to IUA for a V5.2 implementation. defining the necessary 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 otherwise specified in this
ment. document.
This document does not describe the V5 standard itself. The V5 proto- This document does not describe the V5 standard itself. The V5
col is defined by ETSI standards [2,3]. Any description of the V5 pro- protocol is defined by ETSI standards [2,3]. Any description of the
tocol in this document is meant to make the text easier to understand. V5 protocol 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
troller (MGC), analogous to the implementation of the ISDN Q.921 User Controller (MGC), analogous to the implementation of the ISDN Q.921
Adaptation Layer (IUA) as described in [1]. User Adaptation Layer (IUA) as described in [1].
This draft supports analog telephone access, ISDN basic rate access This document supports analog telephone access, ISDN basic rate
and ISDN Primary rate access over a V5.2 interface. access and ISDN Primary rate access over a V5.2 interface.
Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 Since the V5.2 Layer 2, and especially Layer 3, differs from the
and Q.931 Adaptation layer, the IUA standard must be extended to ful- Q.921 [4] and Q.931 Adaptation layer, the IUA standard must be
fil the needs for supporting V5.2. extended to fulfil 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
Local Exchange (LE) to instruct the Access Network (AN) to allo- the Local Exchange (LE) to instruct the Access Network (AN) to
cate bearer channels, either singly or in multiples, on demand. allocate bearer channels, either singularly 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.
Communication path (C-path) - Any one of the following information Communication path (C-path) - Any one of the following information
types: types:
- 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 p-type data from one or more user ports - All the ISDN Ds-type data from one or more user ports
- All the ISDN t-type data from one or more user ports - All the ISDN p-type data from one or more user ports
Note: This definition includes the possibility that there may be - All the ISDN t-type data from one or more user ports
more than one C-path of the same information type, each allocated Note: This definition includes the possibility that there may be
to a different logical C-channel. more than one C-path of the same information type, each allocated
to a different logical C-channel.
Envelope Function Address (EFA) - 13 bit number, ranging from 0 to 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
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
Layer 1 Functional State Machine (L1 FSM) - Functional State Machine Layer 1 Functional State Machine (L1 FSM) - Functional State Machine
in V5 System Management that tracks and controls the states of in V5 System Management that tracks and controls the states of the
the physical E1 links on the interface. physical E1 links on the interface.
Logical Communication channel (Logical C-channel) - A group of one or Logical Communication channel (Logical C-channel) - A group of one or
more C-paths, all of different types, but excluding the C-path more C-paths, all of different types, but excluding the C-path for
for the protection protocol. the protection protocol.
Multi-link - A collection of more than one 2048 kbit/s link which Multi-link - A collection of more than one 2048 kbit/s link which
together make up a V5.2 interface. together make up a V5.2 interface.
Multi-Slot - A group of more than one 64kbit/s channels providing 8Khz Multi-Slot - A group of more than one 64kbit/s channels providing
and time slot sequence integrity, generally used together within 8Khz and time slot sequence integrity, generally used together
an ISDN Primary Rate Access (ISDN-PRA) user port, in order to within an ISDN Primary Rate Access (ISDN-PRA) user port, in order
supply a higher bit-rate service. to 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
rying bearer channels. carrying 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 pro- for the control protocol, link control protocol, and the BCC
tocol. Other C-paths may also be carried in the time slot 16. protocol. 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
face whose time slot 16 carries a C-path for the protection pro- interface whose time slot 16 carries a C-path for the protection
tocol, and, on V5.2 initialization, acts as the standby C-channel protocol, and, on V5.2 initialization, acts as the standby C-
for the control protocol, link control protocol, and BCC protocol channel for the control protocol, link control protocol, and BCC
and any other C-paths initially carried in time slot 16 of the protocol and any other C-paths initially carried in time slot 16
primary link. of the 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
interface may use up to 16 V5 links. V5 interface may use up to 16 V5 links.
1.3. V5.2 Overview 1.3. V5.2 Overview
V5.2 is an industry standard ETSI interface (reference ETS 300 347-1 V5.2 is an industry standard ETSI interface (reference ETS 300 347-1
[3]) defined between a Local Exchange (LE) and an Access Network (AN) [3]) defined between a Local Exchange (LE) and an Access Network (AN)
providing access to the following types: providing access to the following types:
- 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
a non-concentrating fashion. In contrast V5.2 may use up to 16 non-concentrating fashion. In contrast, V5.2 may use up to 16 such
such interface links and supports concentration. 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 between LE and AN. The channels reserved for data are called
"Communication Channels" or "C-channels." "Communication Channels" or "C-channels."
The C-channels are the physical media that exchange data between the 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- V5.2 protocol peer entities, as well as transfer the ISDN BRI
channel messages between the terminals and the LE. A logical communi- D-channel messages between the terminals and the LE. A logical
cation path between two peer entities for one protocol is called a communication path between two peer entities for one protocol is
"C-path". called a "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
(L3) (L3)
- 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 disestab- - A bearer channel connection protocol establishes and
lishes bearer connections on demand, as determined by the sig- disestablishes bearer connections on demand, as determined by
naling information, under the control of the Local Exchange. the signaling information, under the control of the Local
Exchange.
- A link control protocol is defined for multi-link management to - A link control protocol is defined for multi-link management to
control link identification, link blocking and link failure control link identification, link blocking and link failure
conditions. conditions.
- A protection protocol, operating on two separate V5 data links - A protection protocol, operating on two separate V5 data links
is defined to manage the protection switching of communication is defined to manage the protection 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
1.4. Distribution of responsibilities between MGC and SG 1.4. Distribution of responsibilities between MGC and SG
In the V5UA backhaul architectrue, the V5 protocol entities SHALL be In the V5UA backhaul architecture, the V5 protocol entities SHALL be
distributed over SG and MGC as shown below. 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 | | | |
+------------+ +-------+-------+ +------------+ +-------+-------+
V5 System Management SHALL be located on the MGC. The V5 L1 Functional V5 System Management SHALL be located on the MGC. The V5 L1
State Machine (FSM) SHALL be located on the SG. Functional State Machine (FSM) SHALL be located on the SG.
Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the
MGC. MGC.
1.5. Client/Server Model 1.5. Client/Server Model
The Client/Server Model for V5UA shall follow the model as defined for The Client/Server Model for V5UA shall follow the model as defined
IUAP. for IUAP.
The SCTP (and UDP/TCP) registered User Port Number Assignment for V5UA The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for
is 5675. V5UA 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 V5UA to support V5.2 backhaul requires the introduc- Extending IUAP to V5UA to support V5.2 backhaul requires the
tion of new boundary primitives for the Q.921/Q.931 boundary, in introduction of new boundary primitives for the Q.921/Q.931 boundary,
accordance with the definitions in the V5 standards. in accordance with the definitions in the V5 standards.
V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the
DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primi- DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA
tive is used for transport of both V5 Layer 3 messages and V5 ISDN primitive is used for the transportation of both V5 Layer 3 messages
Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only
messages and is used and defined as described for IUAP. used for V5 ISDN messages and is used and defined as described for
IUAP.
In the V5 standards, V5 system management is responsible for In the V5 standards, V5 system management is responsible for
establishing and releasing data links. Therefore, for V5UA the DL- establishing and releasing data links. Therefore, for V5UA the DL-
Establish and DL-Release primitives defined in IUAP are replaced by Establish and DL-Release primitives defined in IUAP are replaced by
new primitives between system management and the data link layer in new primitives between system management and the data link layer in
accordance with the definitions in [2]: 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
the outcome of the procedures for establishing multiple frame opera- confirm the outcome of the procedures for establishing multiple frame
tion. operation.
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
cedures for terminating multiple frame operation. procedures for terminating multiple frame operation.
In contrast to ISDN, the V5 standards demand that V5.2 system manage- In contrast to ISDN, the V5 standards demand that V5.2 system
ment interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (includ- management interacts directly with V5.2 layer 1. Since V5.2 Layer 1
ing the L1 FSM) and parts of V5 system management are physically (including the L1 FSM) and parts of V5 system management are
separated in a V5 backhaul scenario, V5UA must support some services physically separated in a V5 backhaul scenario, V5UA must support
for the communication between these two entities. Specifically, these some services for the communication between these two entities.
services include an indication of the status of a specific link, and Specifically, these services include an indication of the status of a
messages to support the link identification procedure defined by the specific link, and messages to support the link identification
V5 standards. 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 that a link be brought into service for use in a management to request that a link be brought into service for use in
V5 interface. On reception of this message, the L1 FSM on the SG SHALL a V5 interface. On reception of this message, the L1 FSM on the SG
start reporting the status of the V5 link to the MGC. This primitive SHALL start reporting the status of the V5 link to the MGC. This
is used similar to the MPH-proceed primitive defined by V5.2, but it primitive is used similarly to the MPH-proceed primitive defined by
has a more extended meaning than MPH-proceed. 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 that a link is taken out of service on a V5 management to request that a link be taken out of service on a V5
interface. On reception of this message L1 FSM on the SG SHALL stop interface. On reception of this message, L1 FSM on the SG SHALL stop
reporting the status of the V5 link to the GWC. This primitive is 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 used similarly to the MPH-stop primitive defined by V5.2, but it has
more extended meaning than MPH-stop. 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
naling Gateway to report the status (operational/non-operational) of a Signaling Gateway to report the status (operational/non-operational)
V5 link to V5 system management. This primitive is equivalent to the of a V5 link to V5 system management. This primitive is equivalent
MPH-AI and MPH-DI primitives in V5.2. 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. The SG uses it to report the successful bit on the requested link. The SG uses it to report the successful
setting or resetting of this bit back to system management. For V5 setting or resetting of this bit back to system management. For V5,
this message is used for the V5 specific Link Identification procedure this message is used for the V5 specific Link Identification
to set/reset the value of the Sa7 bit, or to confirm the successful procedure to set/reset the value of the Sa7 bit, or to confirm the
setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is
the MPH-ID and MPH-NOR primitves in V5.2. equivalent to the MPH-ID and MPH-NOR primitives in V5.2.
MPH-SA-BIT STATUS MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS primitives are used by system management in the The MPH-SA-BIT STATUS primitives are used by system management in the
MGC to request that the L1 FSM in the SG reports the status of a MGC to request that the L1 FSM in the SG reports the status of a
specified Sa bit on the requested link. The SG uses it to report 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 (indicate) the status of this bit back to system management. For V5,
these messages are used for the V5 specific Link identification pro- these messages are used for the V5 specific Link identification
cedure to request or report the status of the Sa7 bit. This is procedure to request or report the status of the Sa7 bit. This is
equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2. equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2.
Due to the separation of V5 System Management and V5 Layer1/Layer2 in Due to the separation of V5 System Management and V5 Layer1/Layer2 in
the V5UA backhaul architecture, it may be necessary to report error the V5UA backhaul architecture, it may be necessary to report error
conditions of the SG's V5 stack to V5 System Management. For this conditions of the SG's V5 stack to V5 System Management. For this
purpose, a new primitive is defined: 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
tion to V5 System Management. The only valid reason for this primi- condition to V5 System Management. The only valid reason for this
tive is 'Overload', indicating an overload condition of the C-channel primitive is 'Overload', indicating an overload condition of the
on the SG. This reason is not defined in the V5/Q.921 standards. C-channel 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
appear in this document, are to be interpreted as describd in [8]. they appear in this document, are to be interpreted as described in
[7].
3. SCTP Stream Management 3. SCTP Stream Management
A single SCTP stream SHOULD be used for grouping all of the following A single SCTP stream SHOULD be used for grouping all of the following
protocols together: BCC, Link Control, Control and PSTN protocol on a protocols together: BCC, Link Control, Control and PSTN protocol on a
specific C-channel. A separate SCTP stream SHOULD be used for the specific C-channel. A separate SCTP stream SHOULD be used for the
Protection protocol on a specific C-channel. One SCTP stream SHOULD be Protection protocol on a specific C-channel. One SCTP stream SHOULD
used for all ISDN user ports on a specific C-channel. One single be used for all ISDN user ports on a specific C-channel. One single
stream SHOULD NOT be used to carry data of more than one C-channel. stream SHOULD NOT be used to carry data of more than one C-channel.
In addition, one separate SCTP stream SHOULD be used for all MPH (link In addition, one separate SCTP stream SHOULD be used for all MPH
related) messages. (link 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 |
| | | +----+ +-----+ | | | +----+ +-----+
| | | | 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 must be modified for V5UA. The origi-
nal header for the integer formatted Interface Identifier is shown The original IUA message header must be modified for V5UA. The
below: original header for the integer formatted 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 | Spare | | DLCI | Spare |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2 Original IUA Message Header Figure 2: Original IUA Message Header
V5UA extends the IUA Message Header by including the Envelope Function V5UA extends the IUA Message Header by including the Envelope
Address (EFA) in the Spare field. The V5UA format for the integer for- Function Address (EFA) in the Spare field. The V5UA format for the
matted Interface Identifier is shown below: integer formatted 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 (0x81) | 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 is defined by the V5 standard. It identifies a C-path, which
The EFA is defined by the V5 standard. It identifies a C-path, which is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA
is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA uniquely uniquely identifies one of the five V5.2 protocols, or an ISDN agent
identifies one of the five V5.2 protocols, or an ISDN agent attached attached to an AN. The following list contains the possible values
to an AN. The following list contains the possible values for the EFA for the EFA as defined by V5:
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 which do not use DLCI and EFA, SAPI, TEI and EFA For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA
SHALL be set to ZERO and SHALL be ignored by the receiver. For all 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 keep 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
tion switching and bearer channel allocation on the V5 links, it is protection switching and bearer channel allocation on the V5 links,
neccessary that system management has the full picture of the signal- it is necessary that system management has the full picture of the
ing and bearer channels located on each link. signaling 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
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
it claims to be. Furthermore the V5 standard requires that the MGC link it claims to be. Furthermore the V5 standard requires that the
receives reports of the status of all links, and it defines a link MGC receives reports of the status of all links, and it defines a
identification procedure to ensure that AN and LE are referencing the link identification procedure to ensure that AN and LE are
same link when they address a link with a Link Control Protocol mes- referencing the same link when they address a link with a Link
sage. Control Protocol message.
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 for V5UA. 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).
be unique on the SG. This Link Identifier MUST match the Link MUST be unique on the SG. This Link Identifier MUST match the
Identifier used in the Link Management Messages defined later in Link Identifier used in the Link Management Messages defined later
this document. in 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-
number of the addressed time slot. Possible values are 15, 16 and slot number of the addressed time slot. Possible values are 15,
31 representing the possible time slots for C-channels on a V5 16 and 31 representing the possible time slots for C-channels on a
interface. For Link Management Messages the Chnl ID MUST be set V5 interface. For Link Management Messages, the Chnl ID MUST be
to 0. All other values are reserved for future use. set to 0. All other values are reserved for future use.
If used, the text formatted interface identifier SHALL be coded as the If used, the text formatted interface identifier SHALL be coded as
hex representation of the integer formatted interface identifier, the hex representation of the integer formatted interface identifier,
written 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
tinguish between these two message types by means of the Message Class distinguish between these two message types by means of the Message
parameter. Class parameter.
For all V5 interface boundary primitives, a new Message Class is
introduced:
9 V5 Boundary Primitives Transport For all V5 interface boundary primitives, a new Message Class is
Messages (V5PTM) introduced:
Other valid message classes for V5UA, which are also used by IUA, are: 14 V5 Boundary Primitives Transport
Messages (V5PTM)
0 Management (MGMT) Message Other valid message classes for V5UA, which are also used by IUA,
3 ASP State Maintenance (ASPSM) Messages are:
4 ASP Traffic Maintenance (ASPTM) Messages
Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM mes- 0 Management (MGMT) Message
sages are: 3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
1 Data Request Message (MGC -> SG) Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM
2 Data Indication Message (SG -> MGC) messages are:
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)
All these messages are defined similarly to the QPTM messages. 1 Data Request Message (MGC -> SG)
2 Data Indication Message (SG -> MGC)
3 Unit Data Request Message (MGC -> SG)
4 Unit Data Indication Message (SG -> MGC)
5 Establish Request (MGC -> SG)
6 Establish Confirm (SG -> MGC)
7 Establish Indication (SG -> MGC)
8 Release Request (MGC -> SG)
9 Release Confirm (SG -> MGC)
10 Release Indication (SG -> MGC)
In addition, new boundary primitive messages are defined: All these messages are defined similarly to the QPTM messages.
In addition, new boundary primitive messages are defined:
11 Link Status Start Reporting (MGC -> SG) 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, Indication)
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 whether or not the E1 link carries C-channels. link. This is required whether or not the E1 link carries
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
link on the SG addressed by the message. For all link status messages, physical link on the SG addressed by the message. For all link
the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver. status messages, the Chnl ID SHALL be set to '0' and SHALL be ignored
by the receiver.
The integer value used for the Link Identifier is of local signifi- The integer value used for the Link Identifier is of local
cance only, and is coordinated between the SG and MGC. It MUST be significance only, and is coordinated between the SG and MGC. It
unique for every V5 link on the SG. MUST be unique for every V5 link on the SG.
As defined by the V5 standards, V5 System Management must know the As defined by the V5 standards, V5 System Management must know the
status of the links on all active V5 interfaces. The Link Status status of the links on all active V5 interfaces. The Link Status
Start Reporting Message is used by V5 System Management on the MGC to Start Reporting Message is used by V5 System Management on the MGC to
request that the L1 FSM on the SG starts reporting the status of a request that the L1 FSM on the SG starts reporting the status of a
particular link. 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 SHALL 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 SHALL 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
link status. Since the SG has no other way to determine whether a link the link status. Since the SG has no other way to determine whether
is on an active interface or not, this message SHALL always be sent on a link is on an active interface or not, this message SHALL always be
interface startup. sent on interface startup.
If the L1 FSM in the SG receives a Link Status Start Reporting Message If the L1 FSM in the SG receives a Link Status Start Reporting
for a link that is already active (the link status is reported to Sys- Message for a link that is already active (the link status is
tem Management), the SG SHALL immediately report the actual status of reported to System Management), the SG SHALL immediately report the
this link by sending a Link Status Indication Message. The SG SHALL actual status of this link by sending a Link Status Indication
then proceed with the automatic link status reporting as described Message. The SG SHALL then proceed with the automatic link status
above. 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
status of the particular link and will assume the link to be out of the status of the particular link and will assume the link to be out
service. It MUST NOT respond in any way to this message. of service. It MUST NOT respond in any way to this message.
Since there is no other way for the SG to know that an interface is Since there is no other way for the SG to know that an interface has
deactivated, this message SHALL be sent on interface deactivation for been deactivated, this message SHALL be sent on interface
all links on the interface. On reception of this message, the SG SHALL deactivation for all links on the interface. On reception of this
take L2 down on this link. message, the SG SHALL take L2 down on this link.
If the L1 FSM in the SG receives a Link Status Stop Reporting Message If the L1 FSM in the SG receives a Link Status Stop Reporting Message
for a link that is not active (the link status is not reported to Sys- for a link that is not active (the link status is not reported to
tem Management), the SG SHALL ignore the message. System Management), the SG SHALL ignore the message.
The Link Status Start/Stop Reporting Messages contain the common mes- The Link Status Start/Stop Reporting Messages contain the common
sage header followed by the V5UA message header. They do not contain message header followed by the V5UA message header. They do not
any additional parameters. 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 Start Reporting Message to indicate the response to a Link Status Start Reporting Message to indicate the
status of the particular link. After a Link Status Start Reporting status of the particular link. After a Link Status Start Reporting
Message has been received by the L1 FSM, it SHALL automatically send a Message has been received by the L1 FSM, it SHALL automatically send
Link Status Indication Message every time the status of the particular a Link Status Indication Message every time the status of the
link changes. It SHALL not stop this reporting until it receives a particular link changes. It SHALL not stop this reporting until it
Link Status Stop Report Message from System Management. receives a 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
lowing link status parameter: following 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 (0x82) | 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 operational OPERATIONAL 0x0 Link operational
NON-OPERATIONAL 0x1 Link not 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
Sa7 bit that is used for the Link Identification procedure as the Sa7 bit that is used for the Link Identification procedure as
described by the V5 standards [3]. described by the V5 standards [3].
All Sa-Bit Messages SHALL contain the V5UA message header. The Link All Sa-Bit Messages SHALL contain the V5UA message header. The Link
Identifier portion of the Interface Identifier identifies the physical Identifier portion of the Interface Identifier identifies the
link on the SG addressed by the message. For all link status messages, physical link on the SG addressed by the message. For all link
the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver. status messages, the Chnl ID SHALL be set to '0' and SHALL be ignored
by the receiver.
The Link Identifier MUST be the same as used in the Interface Identif- The Link Identifier MUST be the same as used in the Interface
ier to identify on which link a C-channel is located. Identifier to identify on which link a C-channel is located.
The Sa-Bit Set Request message is used to set the value of the speci- The Sa-Bit Set Request message is used to set the value of the
fied Sa-Bit on the defined link. The value of the Sa7 bit in normal specified Sa-Bit on the defined link. 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
ZERO. is set to ZERO.
The Sa-Bit Set Request message for the Sa7 bit with Bit Value 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 corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set
message for the Sa7 bit with Bit Value ONE corresponds to the V5 Request message for the Sa7 bit with Bit Value ONE corresponds to the
defined primitive MPH-NOR. 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
firm message when the setting of the bit is complete. This message Confirm message when the setting of the bit is complete. This
does not correspond to a V5 defined primitive. 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
FSM. The Sa-Bit Status Request message for the Sa7 bit corresponds to L1 FSM. The Sa-Bit Status Request message for the Sa7 bit
the V5 defined primitive MPH-IDR. corresponds to the V5 defined primitive MPH-IDR.
L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status 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 Indication message in which the current setting of the bit will be
reported. The Sa-Bit Status Indication message for the Sa7 bit with reported. The Sa-Bit Status Indication message for the Sa7 bit with
Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The 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 Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE
corresponds to the V5 defined primitive MPH-Elg. 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 (0x83) | 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 value ZERO ZERO 0x0 Bit value ZERO
ONE 0x1 Bit value 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
SHALL be set to '0' by the sender and SHALL 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
at the SG. condition 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 SHOULD issue such an Error Indication with reason Overload for The SG SHOULD issue such an Error Indication with reason Overload for
a C-channel if it is not able to process all Layer 3 messages on this a C-channel if it is not able to process all Layer 3 messages on this
C-channel in a timely manner (overload condition of the C-channel). C-channel in a timely manner (overload condition of the C-channel).
The Error Indication message SHALL contain the V5UA message header. The Error Indication message SHALL contain the V5UA message header.
The Interface Identifier indicates the affected C-channel. SAPI, TEI The Interface Identifier indicates the affected C-channel. SAPI, TEI
and EFA SHALL be set to '0' and SHALL be ignored by the receiver. and EFA SHALL be set to '0' and SHALL be ignored by the receiver.
The Error Indication message contains the following additional parame- The Error Indication message contains the following additional
ter: 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 (0x13) | Length | | Tag (0x84) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason | | Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Error Reason are shown in the following table: The valid values for Error Reason are shown in the following table:
Define Value Description Define Value Description
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 V5 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 V5 Layer 1 failure. It reports this to - The L1 FSM detects the V5 Layer 1 failure. It reports this to
V5 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 V5 Layer 2 of the V5 Layer 1 - V5 System management notifies V5 Layer 2 of the V5 Layer 1
outage by sending a MPH-Layer_1 Failure Ind primitive. outage by sending a MPH-Layer_1 Failure Ind primitive.
Since V5 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
the backhaul architecture, it does not make sense to notify V5 Layer 2 in the backhaul architecture, it does not make sense to notify V5
about V5 Layer 1 failure via V5 system management. Instead V5 Layer 2 Layer 2 about V5 Layer 1 failure via V5 system management. Instead,
SHALL be notified directly by V5 Layer 1 on the SG. V5 Layer 1 SHALL V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG. V5
report the outage to V5 system management by sending a Link Status Layer 1 SHALL report the outage to V5 system management by sending a
Indication message with status NON-OPERATIONAL, corresponding to an Link Status Indication message with status NON-OPERATIONAL,
MPH-DI primitive as defined by the V5.2 standard. V5 system management corresponding to an MPH-DI primitive as defined by the V5.2 standard.
SHALL NOT send an MPH-Layer_1 Failure Ind primitive to V5 Layer 2 in V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind
response to this message. 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 re-establish the connection continuously.
the connection is reestablished, the ASP SHALL send a Link Status When the connection is re-established, the ASP SHALL send a Link
Start Reporting message to the SG for all links on active V5 inter- Status Start Reporting message to the SG for all links on active V5
faces on the SG. interfaces on the SG.
An example for the message flow for reestablishment of the connection An example for the message flow for re-establishment of the
is shown below for one active link on the SG: connection 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) --------- |
| | | |
If the association can be reestablished before the V5UA layer is noti- If the association can be re-established before the V5UA layer is
fied, communication SHALL proceed as usual and no other action SHALL notified, communication SHALL proceed as usual and no other action
be taken by the ASP. SHALL 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 SHOULD If the SG detects an overload condition on a C-channel, it SHOULD
indicate this by sending an Error Indication message, reason Overload indicate this by sending an Error Indication message, with the reason
to the MGC. The MGC SHOULD then take appropriate actions to clear this Overload to the MGC. The MGC SHOULD then take appropriate actions to
overload condition. clear this overload condition.
The SG SHALL resend the Error Indication message with reason Overload The SG SHALL resend the Error Indication message with the reason
as long as the overload condition persist. An interval of 120 seconds Overload as long as the overload condition persists. An interval of
for resend of this message is RECOMMENDED. 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)
The Link Identification Procedures themselves are described by the The Link Identification Procedures themselves are described by the
V5.2 standard [3]. V5.2 standard [3].
A message flow example for an LE initiated Link Identification A message flow example for an LE initiated Link Identification
procedure over V5UA is shown below. An active association between ASP procedure over V5UA is shown below. An active association between
and SG is established prior to the following message flows, and the V5 ASP and SG is established prior to the following message flows, and
interface is already in service: 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 also 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 it is initiated by the AN. Again, the ASP association and the
face are already in service: V5 interface 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 ) ------> |
| <--------- Sa-Bit Set Conf (Sa7) -------------- | | <--------- Sa-Bit Set Conf (Sa7) -------------- |
| | | |
| ------- Data Request (LnkCtrl: FE-IDAck) -----> | | ------- Data Request (LnkCtrl: FE-IDAck) -----> |
| <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- | | <-- Data Indication (LnkCtrl Ack: FE-IDAck) --- |
| | | |
| <---- 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
The security considerations discussed for the 'Security Considerations The security considerations discussed for the 'Security
for SIGTRAN Protocols' [7] document apply to this document. Considerations for SIGTRAN Protocols' [5] 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
registered: is registered:
V5UA "6" V5UA "6"
the SCTP Payload Protocol identifier value "6" SHOULD be included in The SCTP Payload Protocol identifier value "6" SHOULD be included in
each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA each SCTP DATA chunk to indicate that the SCTP is carrying the V5UA
protocol. The value "0" (unspecified) is also allowed but any other protocol. The value "0" (unspecified) is also allowed but any other
values MUST not be used. This Payload Protocol Identifier is not values MUST not be used. This Payload Protocol Identifier is not
directly used by SCTP but MAY be used by certain network entities to directly used by SCTP but MAY be used by certain network entities to
identify the type of information being carried in a Data chunk. identify the type of information being 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.
8.2. V5UA Port Number 8.2. V5UA Port Number
IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA. IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme
Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their valu- Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their
able comments and suggestions. valuable comments and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[1] RFC 3057, "ISDN Q.921-User Adaptation Layer", K. Morneault, S. [1] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN
Rengasami, M. Kalla, G. Sidebottom, February 2001 Q.921-User Adaptation Layer", RFC 3057, February 2001.
[2] ETSI EN 300 324-1 (1999): V interfaces at the digital Local [2] ETSI EN 300 324-1 (1999): V interfaces at the digital Local
Exchange (LE); V5.1 interface for the support of Access Network Exchange (LE); V5.1 interface for the support of Access Network
(AN); Part 1: V5.1 interface specification. (AN); Part 1: V5.1 interface specification.
[3] ETSI EN 300 347-1 (1999): V interfaces at the digital Local [3] ETSI EN 300 347-1 (1999): V interfaces at the digital Local
Exchange (LE); V5.2 interface for the support of Access Network Exchange (LE); V5.2 interface for the support of Access Network
(AN); Part 1: V5.2 interface specification. (AN); Part 1: V5.2 interface specification.
[4] ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface [4] ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface
data link layer specification; (Standard is based on : ITU Q.920, data link layer specification; (Standard is based on : ITU
Q.921). Q.920, Q.921).
[5] ETSI ETS 300 166 (08/1993) : Transmission and Multiplexing; Phy- [5] Loughney, J., Tuexen, M., Ed. and J. Pastor-Balbas, "Security
sical and electrical characteristic of hierarchical digital Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
interfaces (Standard is based on G.703). 3788, May 2004.
[6] ETSI ETS 300 167 (08/1993) : Transmission and Multiplexing; Func- 10.2. Informative References
tional characteristic of 2048 kbits/s interfaces (Standard is
based on G.704, G.706).
[7] J. Loughney, M. Tuexen, J. Pastor-Balbas, 'Security Considera- [6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
tions for SIGTRAN Protocols', Work in Progress. H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
10.2. Informative References [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] RFC 2960, "Stream Control Transport Protocol", R. Stewart et al, 11. Authors' Addresses
October 2000
[8] RFC 2119, "Key words for use in RFCs to Indicate Requirement Lev- Dr. Eva Weilandt
els", S. Bradner, March 1997 Conti Temic microelectronic GmbH
An der B31
88090 Immenstaad
Germany
[9] <draft-rfc-editor-rfc2223bis-02.txt>, "Instructions to Request Phone: +49 7545 8-2917
for Comments (RFC) Authors", J.Reynolds, R. Braden, April 2002 EMail: eva.weilandt@temic.com
(Work in Progress)
11. Author's Addresses Sanjay Rao
Nortel Networks
35 Davis Drive
Research Triangle Park, NC 27709
USA
Dr. Eva Weilandt Tel +49 7545 96 7267 Phone: +1-919-991-2251
Nortel Networks Germany Email eva.weilandt@nortelnetworks.com EMail: rsanjay@nortelnetworks.com
88039 Friedrichshafen
Germany
Sanjay Rao Tel +1-919-991-2251 Neeraj Khanchandani
Nortel Networks Email rsanjay@nortelnetworks.com Nortel Networks
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 Phone: +1-919-991-2274
Nortel Networks Email neerajk@nortelnetworks.com EMail: neerajk@nortelnetworks.com
35 Davis Drive
Research Triangle Park, NC 27709 12. Full Copyright Statement
USA
This Draft Expires in 6 months from May 2003 Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 204 change blocks. 
683 lines changed or deleted 687 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/