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