RFC3807 日本語訳
3807 V5.2-User Adaptation Layer (V5UA). E. Weilandt, N. Khanchandani,S. Rao. June 2004. (Format: TXT=49748 bytes) (Updates RFC3057) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Weilandt
Request for Comments: 3807 N. Khanchandani
Updates: 3057 S. Rao
Category: Standards Track Nortel Networks
June 2004
Network Working Group E. Weilandt Request for Comments: 3807 N. Khanchandani Updates: 3057 S. Rao Category: Standards Track Nortel Networks June 2004
V5.2-User Adaptation Layer (V5UA)
V5.2-User Adaptation Layer (V5UA)
Status of this Memo
Status of this Memo
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
Abstract
Abstract
This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface.
This document defines a mechanism for the backhauling of V5.2 messages over IP using the Stream Control Transmission Protocol (SCTP). This protocol may be used between a Signaling Gateway (SG) and a Media Gateway controller (MGC). It is assumed that the SG receives V5.2 signaling over a standard V5.2 interface.
This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation.
This document builds on the ISDN User Adaptation Layer Protocol (RFC 3057). It defines all necessary extensions to the IUA Protocol needed for the V5UA protocol implementation.
Weilandt, et al. Standards Track [Page 1] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 1] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
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 ................................................. 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
1. Introduction
This document describes a method of implementing V5.2 backhaul messaging over IP using a modified version of the ISDN User Adaptation Layer Protocol (IUAP) [1]. V5UA builds on top of IUA, defining the necessary extensions to IUA for a V5.2 implementation.
This document describes a method of implementing V5.2 backhaul messaging over IP using a modified version of the ISDN User Adaptation Layer Protocol (IUAP) [1]. V5UA builds on top of IUA, defining the necessary extensions to IUA for a V5.2 implementation.
Since V5UA is meant to be an extension to IUAP, everything defined in [1] is also valid for V5UA unless otherwise specified in this document.
Since V5UA is meant to be an extension to IUAP, everything defined in [1] is also valid for V5UA unless otherwise specified in this document.
Weilandt, et al. Standards Track [Page 2] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 2] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
This document does not describe the V5 standard itself. The V5 protocol is defined by ETSI standards [2,3]. Any description of the V5 protocol in this document is meant to make the text easier to understand.
This document does not describe the V5 standard itself. The V5 protocol is defined by ETSI standards [2,3]. Any description of the V5 protocol in this document is meant to make the text easier to understand.
1.1. Scope
1.1. Scope
There is a need for Switched Circuit Network (SCN) signaling protocol delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Controller (MGC), analogous to the implementation of the ISDN Q.921 User Adaptation Layer (IUA) as described in [1].
There is a need for Switched Circuit Network (SCN) signaling protocol delivery from a V5.2 Signaling Gateway (SG) to a Media Gateway Controller (MGC), analogous to the implementation of the ISDN Q.921 User Adaptation Layer (IUA) as described in [1].
This document supports analog telephone access, ISDN basic rate access and ISDN Primary rate access over a V5.2 interface.
This document supports analog telephone access, ISDN basic rate access and ISDN Primary rate access over a V5.2 interface.
Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 [4] and Q.931 Adaptation layer, the IUA standard must be extended to fulfil the needs for supporting V5.2.
Since the V5.2 Layer 2, and especially Layer 3, differs from the Q.921 [4] and Q.931 Adaptation layer, the IUA standard must be extended to fulfil the needs for supporting V5.2.
1.2. Terminology
1.2. Terminology
Bearer Channel Connection (BCC) protocol - A protocol which allows
the Local Exchange (LE) to instruct the Access Network (AN) to
allocate bearer channels, either singularly or in multiples, on
demand.
Bearer Channel Connection (BCC) protocol - A protocol which allows the Local Exchange (LE) to instruct the Access Network (AN) to allocate bearer channels, either singularly or in multiples, on demand.
Communication channel (C-channel) - A 64 kbit/s time slot on a V5.2
interface provisioned to carry communication paths.
Communication 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:
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 Control protocol
- The layer 2 data link carrying the Link Control protocol
- The layer 2 data link carrying the Link Control protocol
- The layer 2 data link carrying the PSTN signaling
- The layer 2 data link carrying the PSTN signaling
- Each of the layer 2 data links carrying the protection protocol
- Each of the layer 2 data links carrying the protection protocol
- The layer 2 data link carrying the BCC protocol
- The layer 2 data link carrying the BCC protocol
- All the ISDN Ds-type data from one or more user ports
- All the ISDN Ds-type data from one or more user ports
- All the ISDN p-type data from one or more user ports
- All the ISDN p-type data from one or more user ports
- All the ISDN t-type data from one or more user ports
- All the ISDN t-type data from one or more user ports
Weilandt, et al. Standards Track [Page 3] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 3] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Note: This definition includes the possibility that there may be
more than one C-path of the same information type, each allocated
to a different logical C-channel.
Note: This definition includes the possibility that there may be more than one C-path of the same information type, each allocated to a different logical C-channel.
Envelope Function Address (EFA) - 13 bit number, ranging from 0 to
8191 (decimal). An EFA uniquely identifies one of the five V5.2
protocols, or an ISDN agent attached to an AN. The following list
contains the possible values for the EFA:
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
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.
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.
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-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.
Multi-Slot - A group of more than one 64kbit/s channels providing 8Khz and time slot sequence integrity, generally used together within an ISDN Primary Rate Access (ISDN-PRA) user port, in order to supply a higher bit-rate service.
Physical Communication Channel (Physical C-channel) - A 64kbit/s time
slot on a V5.2 interface which has been assigned for carrying
logical C-channels. A physical C-channel may not be used for
carrying bearer channels.
Physical Communication Channel (Physical C-channel) - A 64kbit/s time slot on a V5.2 interface which has been assigned for carrying logical C-channels. A physical C-channel may not be used for carrying bearer channels.
Primary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 interface
whose physical C-channel in time slot 16 carries a C-path for the
protection protocol and, on V5.2 initialization, also the C-path
for the control protocol, link control protocol, and the BCC
protocol. Other C-paths may also be carried in the time slot 16.
Primary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 interface whose physical C-channel in time slot 16 carries a C-path for the protection protocol and, on V5.2 initialization, also the C-path for the control protocol, link control protocol, and the BCC protocol. Other C-paths may also be carried in the time slot 16.
Weilandt, et al. Standards Track [Page 4] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 4] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Secondary Link - A 2048 kbit/s (E1) link in a multi-link V5.2
interface whose time slot 16 carries a C-path for the protection
protocol, and, on V5.2 initialization, acts as the standby C-
channel for the control protocol, link control protocol, and BCC
protocol and any other C-paths initially carried in time slot 16
of the primary link.
Secondary Link - A 2048 kbit/s (E1) link in a multi-link V5.2 interface whose time slot 16 carries a C-path for the protection protocol, and, on V5.2 initialization, acts as the standby C- channel for the control protocol, link control protocol, and BCC protocol and any other C-paths initially carried in time slot 16 of the primary link.
V5 Link - A 2048 kbits/s E1 (PCM30) link used on a V5 interface. A
V5 interface may use up to 16 V5 links.
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
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:
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
- 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
without associated outband signaling information
- Other analog or digital accesses for semi-permanent connections without associated outband signaling information
The original V5 specification (V5.1 [2]) uses 2048 kbps links in a non-concentrating fashion. In contrast, V5.2 may use up to 16 such interface links and supports concentration.
The original V5 specification (V5.1 [2]) uses 2048 kbps links in a non-concentrating fashion. In contrast, V5.2 may use up to 16 such interface links and supports concentration.
---------- ---------- o--o
| | E1 | |------- /
| |--------------| | --
| LE | E1 | AN |
| |--------------| | o--o
| | | |------- /
---------- ---------- --
---------- ---------- o--o | | E1 | |------- / | |--------------| | -- | LE | E1 | AN | | |--------------| | o--o | | | |------- / ---------- ---------- --
The LE and AN are connected with up to 16 E1 (PCM30) links. Channels 16, 15 and 31 on any E1 link can be reserved for data communication between LE and AN. The channels reserved for data are called "Communication Channels" or "C-channels."
The LE and AN are connected with up to 16 E1 (PCM30) links. Channels 16, 15 and 31 on any E1 link can be reserved for data communication between LE and AN. The channels reserved for data are called "Communication Channels" or "C-channels."
The C-channels are the physical media that exchange data between the V5.2 protocol peer entities, as well as transfer the ISDN BRI D-channel messages between the terminals and the LE. A logical communication path between two peer entities for one protocol is called a "C-path".
The C-channels are the physical media that exchange data between the V5.2 protocol peer entities, as well as transfer the ISDN BRI D-channel messages between the terminals and the LE. A logical communication path between two peer entities for one protocol is called a "C-path".
Weilandt, et al. Standards Track [Page 5] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 5] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
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
(L3)
- Analog signals are carried by means of the V5 PSTN protocol (L3)
- ISDN/analog ports are controlled by the V5 Control 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)
- 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)
- 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:
In order to support more traffic and dynamic allocation of bearer channels, the V5.2 protocol has several additions:
- A bearer channel connection protocol establishes and
disestablishes bearer connections on demand, as determined by
the signaling information, under the control of the Local
Exchange.
- A bearer channel connection protocol establishes and disestablishes bearer connections on demand, as determined by the signaling information, under the control of the Local Exchange.
- A link control protocol is defined for multi-link management to
control link identification, link blocking and link failure
conditions.
- A link control protocol is defined for multi-link management to control link identification, link blocking and link failure conditions.
- A protection protocol, operating on two separate V5 data links
is defined to manage the protection switching of communication
channels in case of link failures.
- A protection protocol, operating on two separate V5 data links is defined to manage the protection switching of communication channels in case of link failures.
The following protocols are defined for the various protocol layers:
The following protocols are defined for the various protocol layers:
Layer 2:
- LAPV5-EF
- LAPV5-DL
Layer 2: - LAPV5-EF - LAPV5-DL
Layer 3:
- V5-Link Control
- V5-BCC
- V5-PSTN
- V5-Control
- V5-Protection
Layer 3: - V5-Link Control - V5-BCC - V5-PSTN - V5-Control - V5-Protection
Weilandt, et al. Standards Track [Page 6] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 6] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
1.4. Distribution of responsibilities between MGC and SG
1.4. Distribution of responsibilities between MGC and SG
In the V5UA backhaul architecture, the V5 protocol entities SHALL be distributed over SG and MGC as shown below.
In the V5UA backhaul architecture, the V5 protocol entities SHALL be distributed over SG and MGC as shown below.
MGC SG
+------------+ +-------+-------+
| Lnk Cntrl | | | |
+------------+ | | |
| Cntrl | | | |
+------------+ V5UA | | | V5 +------+
| BCC | <--------> | LAPV5 | LAPV5 | <----> | AN |
+------------+ | -DL | -EF | +------+
| PSTN | | | |
+------------+ | | |
| Protection | | | |
+------------+ +-------+-------+
MGC SG +------------+ +-------+-------+ | Lnk Cntrl | | | | +------------+ | | | | Cntrl | | | | +------------+ V5UA | | | V5 +------+ | BCC | <--------> | LAPV5 | LAPV5 | <----> | AN | +------------+ | -DL | -EF | +------+ | PSTN | | | | +------------+ | | | | Protection | | | | +------------+ +-------+-------+
V5 System Management SHALL be located on the MGC. The V5 L1 Functional State Machine (FSM) SHALL be located on the SG.
V5 System Management SHALL be located on the MGC. The V5 L1 Functional State Machine (FSM) SHALL be located on the SG.
Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the MGC.
Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the MGC.
1.5. Client/Server Model
1.5. Client/Server Model
The Client/Server Model for V5UA shall follow the model as defined for IUAP.
The Client/Server Model for V5UA shall follow the model as defined for IUAP.
The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for V5UA is 5675.
The SCTP [6] (and UDP/TCP) registered User Port Number Assignment for 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 introduction of new boundary primitives for the Q.921/Q.931 boundary, in accordance with the definitions in the V5 standards.
Extending IUAP to V5UA to support V5.2 backhaul requires the introduction of new boundary primitives for the Q.921/Q.931 boundary, in accordance with the definitions in the V5 standards.
V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primitive is used for the transportation of both V5 Layer 3 messages and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN messages and is used and defined as described for IUAP.
V5UA reuses some IUA primitives from the Q.921/Q.931 boundary: the DL-DATA primitive and the DL-UNIT DATA primitive. The DL-DATA primitive is used for the transportation of both V5 Layer 3 messages and V5 ISDN Layer 3 messages. The DL-UNIT DATA primitive is only used for V5 ISDN messages and is used and defined as described for IUAP.
Weilandt, et al. Standards Track [Page 7] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 7] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
In the V5 standards, V5 system management is responsible for establishing and releasing data links. Therefore, for V5UA the DL- Establish and DL-Release primitives defined in IUAP are replaced by new primitives between system management and the data link layer in accordance with the definitions in [2]:
In the V5 standards, V5 system management is responsible for establishing and releasing data links. Therefore, for V5UA the DL- Establish and DL-Release primitives defined in IUAP are replaced by new primitives between system management and the data link layer in accordance with the definitions in [2]:
MDL-ESTABLISH
MDL-ESTABLISH
The MDL-Establish primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation.
The MDL-Establish primitives are used to request, indicate and confirm the outcome of the procedures for establishing multiple frame operation.
MDL-RELEASE
MDL-RELEASE
The MDL-Release primitive is used to indicate the outcome of the procedures for terminating multiple frame operation.
The MDL-Release primitive is used to indicate the outcome of the procedures for terminating multiple frame operation.
In contrast to ISDN, the V5 standards demand that V5.2 system management interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (including the L1 FSM) and parts of V5 system management are physically separated in a V5 backhaul scenario, V5UA must support some services for the communication between these two entities. Specifically, these services include an indication of the status of a specific link, and messages to support the link identification procedure defined by the V5 standards.
In contrast to ISDN, the V5 standards demand that V5.2 system management interacts directly with V5.2 layer 1. Since V5.2 Layer 1 (including the L1 FSM) and parts of V5 system management are physically separated in a V5 backhaul scenario, V5UA must support some services for the communication between these two entities. Specifically, these services include an indication of the status of a specific link, and messages to support the link identification procedure defined by the V5 standards.
The new primitive are defined as shown below:
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 management to request that a link be brought into service for use in a V5 interface. On reception of this message, the L1 FSM on the SG SHALL start reporting the status of the V5 link to the MGC. This primitive is used similarly to the MPH-proceed primitive defined by V5.2, but it has a more extended meaning than MPH-proceed.
The MPH-LINK STATUS START REPORTING primitive is used by V5 system management to request that a link be brought into service for use in a V5 interface. On reception of this message, the L1 FSM on the SG SHALL start reporting the status of the V5 link to the MGC. This primitive is used similarly to the MPH-proceed primitive defined by V5.2, but it has a more extended meaning than MPH-proceed.
MPH-LINK STATUS STOP REPORTING
MPH-LINK STATUS STOP REPORTING
The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system management to request that a link be taken out of service on a V5 interface. On reception of this message, L1 FSM on the SG SHALL stop reporting the status of the V5 link to the GWC. This primitive is used similarly to the MPH-stop primitive defined by V5.2, but it has a more extended meaning than MPH-stop.
The MPH-LINK STATUS STOP REPORTING primitive is used by V5 system management to request that a link be taken out of service on a V5 interface. On reception of this message, L1 FSM on the SG SHALL stop reporting the status of the V5 link to the GWC. This primitive is used similarly to the MPH-stop primitive defined by V5.2, but it has a more extended meaning than MPH-stop.
Weilandt, et al. Standards Track [Page 8] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 8] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
MPH-LINK STATUS INDICATION
MPH-LINK STATUS INDICATION
The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the Signaling Gateway to report the status (operational/non-operational) of a V5 link to V5 system management. This primitive is equivalent to the MPH-AI and MPH-DI primitives in V5.2.
The MPH-LINK STATUS INDICATION primitive is used by L1 FSM on the Signaling Gateway to report the status (operational/non-operational) of a V5 link to V5 system management. This primitive is equivalent to the MPH-AI and MPH-DI primitives in V5.2.
MPH-SA-BIT SET
MPH-SA-BIT SET
The MPH-SA-BIT SET primitive is used by system management to request that the L1 FSM in the SG sets or resets the value of a specified Sa bit on the requested link. The SG uses it to report the successful setting or resetting of this bit back to system management. For V5, this message is used for the V5 specific Link Identification procedure to set/reset the value of the Sa7 bit, or to confirm the successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to the MPH-ID and MPH-NOR primitives in V5.2.
The MPH-SA-BIT SET primitive is used by system management to request that the L1 FSM in the SG sets or resets the value of a specified Sa bit on the requested link. The SG uses it to report the successful setting or resetting of this bit back to system management. For V5, this message is used for the V5 specific Link Identification procedure to set/reset the value of the Sa7 bit, or to confirm the successful setting of the Sa bit. The MPH-SA BIT SET REQUEST is equivalent to the MPH-ID and MPH-NOR primitives in V5.2.
MPH-SA-BIT STATUS
MPH-SA-BIT STATUS
The MPH-SA-BIT STATUS primitives are used by system management in the MGC to request that the L1 FSM in the SG reports the status of a specified Sa bit on the requested link. The SG uses it to report (indicate) the status of this bit back to system management. For V5, these messages are used for the V5 specific Link identification procedure to request or report the status of the Sa7 bit. This is equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2.
The MPH-SA-BIT STATUS primitives are used by system management in the MGC to request that the L1 FSM in the SG reports the status of a specified Sa bit on the requested link. The SG uses it to report (indicate) the status of this bit back to system management. For V5, these messages are used for the V5 specific Link identification procedure to request or report the status of the Sa7 bit. This is equivalent to the MPH-IDR, MPH-IDI or MPH-Elg primitives in V5.2.
Due to the separation of V5 System Management and V5 Layer1/Layer2 in the V5UA backhaul architecture, it may be necessary to report error conditions of the SG's V5 stack to V5 System Management. For this purpose, a new primitive is defined:
Due to the separation of V5 System Management and V5 Layer1/Layer2 in the V5UA backhaul architecture, it may be necessary to report error conditions of the SG's V5 stack to V5 System Management. For this purpose, a new primitive is defined:
MDL-ERROR INDICATION
MDL-ERROR INDICATION
The MDL-ERROR INDICATION primitive is used to indicate an error condition to V5 System Management. The only valid reason for this primitive is 'Overload', indicating an overload condition of the C-channel on the SG. This reason is not defined in the V5/Q.921 standards.
The MDL-ERROR INDICATION primitive is used to indicate an error condition to V5 System Management. The only valid reason for this primitive is 'Overload', indicating an overload condition of the C-channel on the SG. This reason is not defined in the V5/Q.921 standards.
2. Conventions
2. Conventions
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [7].
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [7].
Weilandt, et al. Standards Track [Page 9] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 9] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
3. SCTP Stream Management
3. SCTP Stream Management
A single SCTP stream SHOULD be used for grouping all of the following protocols together: BCC, Link Control, Control and PSTN protocol on a specific C-channel. A separate SCTP stream SHOULD be used for the Protection protocol on a specific C-channel. One SCTP stream SHOULD be used for all ISDN user ports on a specific C-channel. One single stream SHOULD NOT be used to carry data of more than one C-channel.
A single SCTP stream SHOULD be used for grouping all of the following protocols together: BCC, Link Control, Control and PSTN protocol on a specific C-channel. A separate SCTP stream SHOULD be used for the Protection protocol on a specific C-channel. One SCTP stream SHOULD be used for all ISDN user ports on a specific C-channel. One single stream SHOULD NOT be used to carry data of more than one C-channel.
In addition, one separate SCTP stream SHOULD be used for all MPH (link related) messages.
In addition, one separate SCTP stream SHOULD be used for all MPH (link related) messages.
4. Proposed V5.2 Backhaul Architecture
4. Proposed V5.2 Backhaul Architecture
****** V5.2 ****** IP *******
* AN *---------------* SG *--------------* MGC *
****** ****** *******
****** V5.2 ****** IP ******* * AN *---------------* SG *--------------* MGC * ****** ****** *******
+-----+ +-----+
|V5.2 | (NIF) |V5.2 |
+-----+ +----------+ +-----+
| | | |V5UA| |V5UA |
| | | +----+ +-----+
|LAPV5| |LAPV5|SCTP| |SCTP |
| | | +----+ +-----+
| | | | IP + | IP |
+-----+ +-----+----+ +-----+
+-----+ +-----+ |V5.2 | (NIF) |V5.2 | +-----+ +----------+ +-----+ | | | |V5UA| |V5UA | | | | +----+ +-----+ |LAPV5| |LAPV5|SCTP| |SCTP | | | | +----+ +-----+ | | | | IP + | IP | +-----+ +-----+----+ +-----+
Figure 1: V5.2 Backhaul Architecture
Figure 1: V5.2 Backhaul Architecture
AN - Access Network
NIF - Nodal Interworking Function
SCTP - Stream Control Transmission Protocol
AN - Access Network NIF - Nodal Interworking Function SCTP - Stream Control Transmission Protocol
Weilandt, et al. Standards Track [Page 10] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 10] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
4.1. V5UA Message Header
4.1. V5UA Message Header
The original IUA message header must be modified for V5UA. The original header for the integer formatted Interface Identifier is shown below:
The original IUA message header must be modified for V5UA. The original header for the integer formatted Interface Identifier is shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x5) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI | Spare | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
Figure 2: Original IUA Message Header
V5UA extends the IUA Message Header by including the Envelope Function Address (EFA) in the Spare field. The V5UA format for the integer formatted Interface Identifier is shown below:
V5UA extends the IUA Message Header by including the Envelope Function Address (EFA) in the Spare field. The V5UA format for the integer formatted Interface Identifier is shown below:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x81) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI | EFA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x1) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Identifier (integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x81) | Length=8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DLCI | EFA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: V5UA Message Header (Integer-based Interface identifier)
Figure 3: V5UA Message Header (Integer-based Interface identifier)
Weilandt, et al. Standards Track [Page 11] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt, et al. Standards Track [Page 11] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
The EFA is defined by the V5 standard. It identifies a C-path, which is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN. The following list contains the possible values for the EFA as defined by V5:
The EFA is defined by the V5 standard. It identifies a C-path, which is a 13-bit number, ranging from 0 to 8191 (decimal). An EFA uniquely identifies one of the five V5.2 protocols, or an ISDN agent attached to an AN. The following list contains the possible values for the EFA as defined by V5:
Definition Value
---------- ------
ISDN_PROTOCOL 0 - 8175
PSTN_PROTOCOL 8176
CONTROL_PROTOCOL 8177
BCC_PROTOCOL 8178
PROT_PROTOCOL 8179
LINK_CONTROL_PROTOCOL 8180
RESERVED 8181 - 8191
Definition Value ---------- ------ ISDN_PROTOCOL 0 - 8175 PSTN_PROTOCOL 8176 CONTROL_PROTOCOL 8177 BCC_PROTOCOL 8178 PROT_PROTOCOL 8179 LINK_CONTROL_PROTOCOL 8180 RESERVED 8181 - 8191
For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA SHALL be set to ZERO and SHALL be ignored by the receiver. For all other messages, the DLCI SHALL be set as defined in the V5.2 standard [2].
For MPH messages which do not use DLCI and EFA, SAPI, TEI and EFA SHALL be set to ZERO and SHALL be ignored by the receiver. For all other messages, the DLCI SHALL be set as defined in the V5.2 standard [2].
The Interface Identifier SHALL follow the naming conventions for the Interface Identifier as defined below.
The Interface Identifier SHALL follow the naming conventions for the 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 keep track of the states of all links on a V5 interface. To perform tasks like protection switching and bearer channel allocation on the V5 links, it is necessary that system management has the full picture of the signaling and bearer channels located on each link.
The V5 standard demands that V5 System Management keep track of the states of all links on a V5 interface. To perform tasks like protection switching and bearer channel allocation on the V5 links, it is necessary that system management has the full picture of the signaling and bearer channels located on each link.
The IUA protocol identifies C-channels by endpoints without a defined association with a specific link. Since no naming convention exists, there is no guarantee that a C-channel is actually located at the link it claims to be. Furthermore the V5 standard requires that the MGC receives reports of the status of all links, and it defines a link identification procedure to ensure that AN and LE are referencing the same link when they address a link with a Link Control Protocol message.
The IUA protocol identifies C-channels by endpoints without a defined association with a specific link. Since no naming convention exists, there is no guarantee that a C-channel is actually located at the link it claims to be. Furthermore the V5 standard requires that the MGC receives reports of the status of all links, and it defines a link identification procedure to ensure that AN and LE are referencing the same link when they address a link with a Link Control Protocol message.
It would clearly be against the concept of V5.2 if there was no clear association between E1 links and channels. To solve this problem, a naming convention MUST be used for V5UA.
1Eのリンクとチャンネルとのどんな明確な仲間もいなければ、それは明確にV5.2の概念に反対しているでしょうに。 この問題を解決するために、V5UAに命名規則を使用しなければなりません。
Weilandt, et al. Standards Track [Page 12] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[12ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
The format of the integer formatted Interface Identifier is shown below:
整数のフォーマットされたInterface Identifierの書式は以下に示されます:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンク識別子| 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.
Identifierをリンクしてください--SG(27ビット)の上の1Eのリンクのための識別子。 SGでユニークでなければならなくなってください。 このLink Identifierは後で本書では定義されたLink Management Messagesで使用されるLink Identifierに合わなければなりません。
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.
Chnl ID--チャンネルIdentifier(5ビット)。 これは記述された時間帯の時間スロット番号と等しいです。 可能な値は、C-チャンネルのためにV5インタフェースに可能な時間帯を表す15と、16と31です。 Link Management Messagesにおいて、Chnl IDを0に設定しなければなりません。 他のすべての値が今後の使用のために予約されます。
If used, the text formatted interface identifier SHALL be coded as the hex representation of the integer formatted interface identifier, written as a variable length string.
使用されるなら、整数の十六進法表現がインタフェース識別子をフォーマットしたのでコード化されて、可変長ストリングとして書かれていて、テキストはインタフェース識別子SHALLをフォーマットしました。
4.3. V5 Additions to IUA Boundary Primitives
4.3. IUA境界基関数へのV5追加
Some primitives for the V5 interface boundaries are similar to the Q.921/Q.931 boundary primitive messages defined in IUA, but they need to be handled in a different way. Therefore it is neccessary to distinguish between these two message types by means of the Message Class parameter.
V5インタフェース境界のためのいくつかの基関数がIUAで定義されたQ.921/Q.931の境界の原始のメッセージと同様ですが、それらは、異なった方法で扱われる必要があります。 したがって、それはMessage Classパラメタによってこれらの2つのメッセージタイプを見分けるneccessaryです。
For all V5 interface boundary primitives, a new Message Class is introduced:
すべてのV5インタフェース境界基関数に関しては、新しいMessage Classを導入します:
14 V5 Boundary Primitives Transport
Messages (V5PTM)
14 V5境界基関数はメッセージを輸送します。(V5PTM)
Other valid message classes for V5UA, which are also used by IUA, are:
他のまた、IUAが使用されるV5UAに、有効なメッセージのクラスは以下の通りです。
0 Management (MGMT) Message
3 ASP State Maintenance (ASPSM) Messages
4 ASP Traffic Maintenance (ASPTM) Messages
0 管理(管理)メッセージ3ASP州の維持(ASPSM)メッセージ4ASP交通維持(ASPTM)メッセージ
Weilandt, et al. Standards Track [Page 13] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[13ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM messages are:
V5PTMメッセージとしてV5.2によって再利用されたQ.921/Q.931の境界の原始のメッセージは以下の通りです。
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)
メッセージ(SG->MGC)5が6が確立する要求(MGC->SG)を確立するというデータ4つのデータ3つの1つのデータ要求メッセージ(MGC->SG)2データ指示メッセージ(SG->MGC)要求メッセージ(MGC->SG)指示が、7がリリース要求(MGC->SG)9がリリースする8が、10が指示をリリースすると確認するという(SG->MGC)指示(SG->MGC)を確立すると確認します(SG->MGC)。(SG->MGC)
All these messages are defined similarly to the QPTM messages. In addition, new boundary primitive messages are defined:
これらのすべてのメッセージが同様にQPTMメッセージと定義されます。 さらに、新しい境界原始のメッセージは定義されます:
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)
11 14Sa-ビットが要求(MGC->SG)15Sa-ビットセットを設定したという13リンク状態指示(SG->MGC)が17Sa-ビットの16Sa-ビット状態要求(MGC->SG)状態指示(SG->MGC)18誤り表示を確認する(SG->MGC)と報告する(MGC->SG)リンク状態スタート報告(MGC->SG)12リンク状態停止(SG->MGC)
4.4. Link Status Messages (Start Reporting, Stop Reporting, Indication)
4.4. リンクステータスメッセージ(スタート報告、停止報告、指示)
The Link Status Messages are used between V5 System Management on the MGC and the L1 FSM on the SG to track the status of a particular E1 link. This is required whether or not the E1 link carries C-channels.
Link Status Messagesは、特定の1Eのリンクの状態を追跡するのにMGCの上のV5 System ManagementとSGの上のL1 FSMの間で使用されます。 1EのリンクがC-チャンネルを運ぶか否かに関係なく、これが必要です。
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.
すべてのLink Status MessagesがV5UA Message Headerを含んでいます。 Interface IdentifierのLink Identifier部分はメッセージによって記述されたSGの上の物理的なリンクを特定します。 すべてに関して、''0へのセットがSHALLであったならステータスメッセージ、Chnl ID SHALLをリンクしてください。受信機で、無視されます。
The integer value used for the Link Identifier is of local significance only, and is coordinated between the SG and MGC. It MUST be unique for every V5 link on the SG.
Link Identifierに使用される整数値は、ローカルの意味しかなくて、SGとMGCの間で調整されます。 SGの上のあらゆるV5リンクに、それはユニークであるに違いありません。
As defined by the V5 standards, V5 System Management must know the status of the links on all active V5 interfaces. The Link Status Start Reporting Message is used by V5 System Management on the MGC to request that the L1 FSM on the SG starts reporting the status of a particular link.
V5規格によって定義されるように、V5 System ManagementはすべてのアクティブなV5インタフェースでリンクの状態を知らなければなりません。 Link Status Start Reporting Messageは、SGの上のL1 FSMが特定のリンクの状態を報告し始めるよう要求するのにMGCの上のV5 System Managementによって使用されます。
Weilandt, et al. Standards Track [Page 14] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[14ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
V5 system management SHALL send this Message on interface activation for all links on the interface. The SG SHALL respond immediately to this request with a Link Status Indication message, and it SHALL then send a Link Status Indication message on all subsequent changes of the link status. Since the SG has no other way to determine whether a link is on an active interface or not, this message SHALL always be sent on interface startup.
V5システム管理SHALLはインタフェースですべてのリンクのためのインタフェース起動にこのMessageを送ります。 SG SHALLはすぐ次に、SHALLがリンク状態のすべてのその後の変化にLink Status Indicationメッセージを送るというLink Status Indicationメッセージ、およびそれがあるこの要求に応じます。 SG以来、いつも何かリンクがアクティブなインタフェースにあるか否かに関係なく、ずっと決定しない他のもの、このメッセージSHALLをインタフェース始動に送りますか?
If the L1 FSM in the SG receives a Link Status Start Reporting Message for a link that is already active (the link status is reported to System Management), the SG SHALL immediately report the actual status of this link by sending a Link Status Indication Message. The SG SHALL then proceed with the automatic link status reporting as described above.
SGのL1 FSMが既にアクティブなリンクにLink Status Start Reporting Messageを受けるなら(リンク状態はSystem Managementに報告されます)、SG SHALLは、すぐに、Link Status Indication Messageを送ることによって、このリンクの実際の状態を報告します。 そして、SG SHALLは上で説明されるように自動リンク状態報告を続けます。
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.
例えば、インタフェース非活性化でリンクの状態のこの報告を止めるために、System ManagementはLink Status Stop Reporting MessageをL1 FSMに送ります。 SGは、次に、すぐに、特定のリンクの状態を報告するのを止めて、リンクが使われなくなっていると仮定するでしょう。 それは何らかの方法でこのメッセージに応じてはいけません。
Since there is no other way for the SG to know that an interface has been deactivated, this message SHALL be sent on interface deactivation for all links on the interface. On reception of this message, the SG SHALL take L2 down on this link.
他の道が全くないので、SGがインタフェースを非活性化してあって、このメッセージがSHALLであることを知るように、インタフェースでインタフェース非活性化ですべてのリンクに送ってください。 このメッセージのレセプションでは、SG SHALLはこのリンクにL2を降ろします。
If the L1 FSM in the SG receives a Link Status Stop Reporting Message for a link that is not active (the link status is not reported to System Management), the SG SHALL ignore the message.
SGのL1 FSMがアクティブでないリンクにLink Status Stop Reporting Messageを受けるなら(リンク状態はSystem Managementに報告されません)、SG SHALLはメッセージを無視します。
The Link Status Start/Stop Reporting Messages contain the common message header followed by the V5UA message header. They do not contain any additional parameters.
Link Status Start/停止Reporting MessagesはV5UAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 それらはどんな追加パラメタも含んでいません。
The Link Status Indication Message is used by L1 FSM in the SG in response to a Link Status Start Reporting Message to indicate the status of the particular link. After a Link Status Start Reporting Message has been received by the L1 FSM, it SHALL automatically send a Link Status Indication Message every time the status of the particular link changes. It SHALL not stop this reporting until it receives a Link Status Stop Report Message from System Management.
Link Status Indication Messageは、特定のリンクの状態を示すのにLink Status Start Reporting Messageに対応してSGのL1 FSMによって使用されます。 後に、Link Status Start Reporting MessageはL1 FSMによって受け取られました、それ。特定の状態が変化をリンクするときはいつも、SHALLは自動的にLink Status Indication Messageを送ります。 それ、それがSystem ManagementからLink Status Stop Report Messageを受けるまで、SHALLはこの報告を止めません。
The Link Status Indication Message contains the common message header followed by the V5UA message header. In addition, it contains the following link status parameter:
Link Status Indication MessageはV5UAメッセージヘッダーによってついて来られた一般的なメッセージヘッダーを含んでいます。 さらに、以下のリンクステータスパラメタを含んでいます:
Weilandt, et al. Standards Track [Page 15] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[15ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tag (0x82) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×82)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | リンク状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Link Status are shown in the following table:
Link Statusのための有効値は以下のテーブルに示されます:
Define Value Description
値の記述を定義してください。
OPERATIONAL 0x0 Link operational
NON-OPERATIONAL 0x1 Link not operational
OPERATIONAL0x0のLinkの操作上のNON-OPERATIONAL0x1Link、操作上でない
4.5. Sa-Bit Messages (Set Request, Set Confirm, Status Request,
Status Indication)
4.5. Sa-ビットメッセージ(セットが、状態が要求すると確認するセット要求、状態指示)
The Sa-Bit Messages are used between V5 System Management in the MGC and the L1 FSM in the SG to set and read the status of Sa bits on the E1 links. For V5, it is only required to set and read the status of the Sa7 bit that is used for the Link Identification procedure as described by the V5 standards [3].
Sa-ビットMessagesは、1Eのリンクの上にSaビットの状態を設定して、読むのにMGCのV5 System ManagementとSGのL1 FSMの間で使用されます。 V5に関しては、それが、Link Identification手順にV5規格[3]で説明されるように使用されるSa7ビットの状態を設定して、読むのに必要であるだけです。
All Sa-Bit Messages SHALL contain the V5UA message header. The Link Identifier portion of the Interface Identifier identifies the physical link on the SG addressed by the message. For all link status messages, the Chnl ID SHALL be set to '0' and SHALL be ignored by the receiver.
すべてのSa-ビットMessages SHALLがV5UAメッセージヘッダーを含んでいます。 Interface IdentifierのLink Identifier部分はメッセージによって記述されたSGの上の物理的なリンクを特定します。 すべてに関して、''0へのセットがSHALLであったならステータスメッセージ、Chnl ID SHALLをリンクしてください。受信機で、無視されます。
The Link Identifier MUST be the same as used in the Interface Identifier to identify on which link a C-channel is located.
Link Identifierはどれがリンクされるかに関してC-チャンネルが見つけられているかを特定するのにInterface Identifierで使用されるのと同じであるに違いありません。
The Sa-Bit Set Request message is used to set the value of the specified Sa-Bit on the defined link. The value of the Sa7 bit in normal operation is ONE. For the Link Identification procedure, it is set to ZERO.
Sa-ビットSet Requestメッセージは、定義されたリンクの上に指定されたSa-ビットの価値を設定するのに使用されます。 通常の操作における、Sa7ビットの価値はONEです。 Link Identification手順において、それはZEROに設定されます。
The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set Request message for the Sa7 bit with Bit Value ONE corresponds to the V5 defined primitive MPH-NOR.
Bit Value ZEROがあるSa7ビットがV5に対応しているので、Sa-ビットSet Requestメッセージは原始のMPH-IDを定義しました。 Bit Value ONEがあるSa7ビットがV5に対応しているので、Sa-ビットSet Requestメッセージは原始のMPH-NORを定義しました。
The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set Confirm message when the setting of the bit is complete. This message does not correspond to a V5 defined primitive.
ビットの設定が完全であるときに、SG MUSTはSa-ビットSet ConfirmメッセージでSa-ビットSet Requestメッセージに答えます。 このメッセージは原始的に定義されたV5に対応していません。
Weilandt, et al. Standards Track [Page 16] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[16ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
The Sa-Bit Status Request message is used by system management to request the status of the specified Sa-Bit on the defined link from L1 FSM. The Sa-Bit Status Request message for the Sa7 bit corresponds to the V5 defined primitive MPH-IDR.
Sa-ビットStatus Requestメッセージは、定義されたリンクの上にL1 FSMから指定されたSa-ビットの状態を要求するのにシステム管理で使用されます。 Sa7ビットがV5に対応しているので、Sa-ビットStatus Requestメッセージは原始のMPH-IDRを定義しました。
L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status Indication message in which the current setting of the bit will be reported. The Sa-Bit Status Indication message for the Sa7 bit with Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE corresponds to the V5 defined primitive MPH-Elg.
L1 FSMはビットの現在の設定が報告されるSa-ビットStatus IndicationメッセージでSa-ビットStatus要求メッセージに答えます。 Bit Value ZEROがあるSa7ビットがV5に対応しているので、Sa-ビットStatus Indicationメッセージは原始のMPH-IDIを定義しました。 Bit Value ONEがあるSa7ビットがV5に対応しているので、Sa-ビットStatus Indicationメッセージは原始のMPH-Elgを定義しました。
All Sa-Bit Messages contain the following additional parameter:
すべてのSa-ビットMessagesが以下の追加パラメタを含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x83) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BIT ID | Bit Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×83)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 噛み付いているID| 噛み付いている値| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Bit Value are shown in the following table:
Bit Valueのための有効値は以下のテーブルに示されます:
Define Value Description
値の記述を定義してください。
ZERO 0x0 Bit value ZERO
ONE 0x1 Bit value ONE
ZERO0x0Bit値のZERO ONE0x1Bit値のONE
The valid value for BIT ID is shown in the following table:
BIT IDのための有効値は以下のテーブルに示されます:
Define Value Description
値の記述を定義してください。
Sa7 0x7 Addresses the Sa7 bit
Sa7 0x7Addresses Sa7は噛み付きました。
There are no other valid values for V5UA. All other values are reserved for future use.
V5UAのための他の有効値が全くありません。 他のすべての値が今後の使用のために予約されます。
For the Sa-Bit Status Request and Set Confirm messages, the BIT Value SHALL be set to '0' by the sender and SHALL be ignored by the receiver.
Sa-ビットStatus Requestとメッセージ、Set Confirm BIT Value SHALLに、設定されてください。'0'受信機によって送付者とSHALLによって無視されます。
4.6. Error Indication Message
4.6. 誤り表示メッセージ
The Error Indication Message is used between the V5 stack on the SG and the V5 System Management in the MGC to indicate an error condition at the SG.
Error Indication Messageは、SGでエラー条件を示すのにSGの上のV5スタックとMGCのV5 System Managementの間で使用されます。
Weilandt, et al. Standards Track [Page 17] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[17ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
The only valid reason for the Error Indication Message is Overload. The SG SHOULD issue such an Error Indication with reason Overload for a C-channel if it is not able to process all Layer 3 messages on this C-channel in a timely manner (overload condition of the C-channel).
Error Indication Messageに関する唯一の正当な理由がOverloadです。 直ちに(C-チャンネルに関する過負荷条件)このC-チャンネルに関するすべてのLayer3メッセージを処理できるというわけではないなら、SG SHOULDはC-チャンネルのために理由Overloadと共にそのようなError Indicationを発行します。
The Error Indication message SHALL contain the V5UA message header.
Error IndicationメッセージSHALLはV5UAメッセージヘッダーを含んでいます。
The Interface Identifier indicates the affected C-channel. SAPI, TEI and EFA SHALL be set to '0' and SHALL be ignored by the receiver.
Interface Identifierは影響を受けるC-チャンネルを示します。 SAPI、TEI、およびEFA SHALL、''0へのセットがSHALLであったなら、受信機で、無視されてください。
The Error Indication message contains the following additional parameter:
Error Indicationメッセージは以下の追加パラメタを含んでいます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tag (0x84) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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×84)| 長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 誤り理由| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The valid values for Error Reason are shown in the following table:
Error Reasonのための有効値は以下のテーブルに示されます:
Define Value Description
値の記述を定義してください。
OVERLOAD 0x1 C-channel is in overload state
OVERLOAD0x1C-チャンネルがオーバーロード状態にあります。
There are no other valid values for V5UA. All other values are reserved for future use.
V5UAのための他の有効値が全くありません。 他のすべての値が今後の使用のために予約されます。
5. Procedures
5. 手順
5.1. V5 Layer 1 failure
5.1. V5層1の故障
The normal way to handle a V5 Layer 1 failure is described in the V5 standards[2,3] as follows:
V5 Layer1の故障を扱う正常な方法は以下のV5規格[2、3]で述べられます:
- The L1 FSM detects the V5 Layer 1 failure. It reports this to
V5 System management by sending a MPH-DI primitive for the
affected link.
- L1 FSMはV5 Layer1の故障を検出します。 それは、影響を受けるリンクにおける、原始のMPH-DIを送ることによって、V5 System管理にこれを報告します。
- V5 System management notifies V5 Layer 2 of the V5 Layer 1
outage by sending a MPH-Layer_1 Failure Ind primitive.
- _MPH-層に1つのFailureインディアン座を原始的に送ることによって、V5システム管理はV5 Layer1供給停止についてV5 Layer2に通知します。
Since V5 Layer1/2 and V5 System Management are no longer co-located in the backhaul architecture, it does not make sense to notify V5 Layer 2 about V5 Layer 1 failure via V5 system management. Instead, V5 Layer 2 SHALL be notified directly by V5 Layer 1 on the SG. V5
V5 Layer1/2とV5 System Managementがもう逆送構造で共同位置していないので、それはV5システム管理でV5 Layerに関してV5 Layer2に通知する意味を1つの失敗にしません。 代わりにV5 Layer2SHALL、直接SGの上のV5 Layer1によって通知されてください。 V5
Weilandt, et al. Standards Track [Page 18] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[18ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
Layer 1 SHALL report the outage to V5 system management by sending a Link Status Indication message with status NON-OPERATIONAL, corresponding to an MPH-DI primitive as defined by the V5.2 standard. V5 system management SHALL NOT send an MPH-Layer_1 Failure Ind primitive to V5 Layer 2 in response to this message.
層1のSHALLは状態NON-OPERATIONALと共にV5システム管理に供給停止をLink Status Indicationメッセージを送ることによって、報告します、V5.2規格によって定義されるようにMPH-DIに原始的に対応している。 V5システム管理SHALL NOTはこのメッセージに対応したV5 Layer2への原始の1つのFailureインディアン座を_MPH-層に送ります。
5.2. Loss of V5UA peer
5.2. V5UA同輩の損失
If SCTP failure is detected or the heartbeat is lost, the following procedure SHALL be performed:
SCTPの故障が検出されるか、そして、鼓動が無くなって、以下の手順は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- operational) for all links on this SG.
V5UA同輩の損失がV5UA層に報告されるとき、まるでLink Status Indication(非操作上の)をこのSGの上のすべてのリンクに受けたかのようにASP SHALLは振る舞います。
The ASP SHALL attempt to re-establish the connection continuously. When the connection is re-established, the ASP SHALL send a Link Status Start Reporting message to the SG for all links on active V5 interfaces on the SG.
ASP SHALLは、接続を絶え間なく復職させるのを試みます。 接続が復職するとき、ASP SHALLはすべてのリンクのためにSGでアクティブなV5インタフェースでLink Status Start ReportingメッセージをSGに送ります。
An example for the message flow for re-establishment of the connection is shown below for one active link on the SG:
接続の再建のためのメッセージ流動のための例は以下にSGの上の1個のアクティブなリンクに示されます:
ASP SG
ASP SG
| |
| -------- Link Status Start Reporting ---------> |
| |
| <------ Link Status Ind (operational) --------- |
| |
| | | -------- リンク状態スタート報告--------->|、|、|、| <、-、-、-、-、-- リンク状態インディアン座(操作上の)--------- | | |
If the association can be re-established before the V5UA layer is notified, communication SHALL proceed as usual and no other action SHALL be taken by the ASP.
V5UA層に通知される前に協会が復職できるなら、コミュニケーションSHALLはいつものように続きます、そして、いいえ、他の動作SHALL。ASPによって取られます。
5.3. C-channel overload on SG
5.3. SGの上のC-チャンネル過負荷
If the SG detects an overload condition on a C-channel, it SHOULD indicate this by sending an Error Indication message, with the reason Overload to the MGC. The MGC SHOULD then take appropriate actions to clear this overload condition.
SGはC-チャンネルに関する過負荷条件を検出します、それ。SHOULDはError Indicationメッセージを送ることによって、これを示します、MGCへの理由Overloadと共に。 そして、MGC SHOULDは、この過負荷条件をクリアするために適切な行動を取ります。
The SG SHALL resend the Error Indication message with the reason Overload as long as the overload condition persists. An interval of 120 seconds for resend of this message is RECOMMENDED.
過負荷条件が持続している限り、SG SHALLは理由OverloadがあるError Indicationメッセージを再送します。 120秒の間隔、再送、このメッセージにおいて、RECOMMENDEDはそうです。
Weilandt, et al. Standards Track [Page 19] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[19ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
6. Examples
6. 例
6.1. Link Identification Procedure (successful)
6.1. リンク識別手順(うまくいく)です。
The Link Identification Procedures themselves are described by the V5.2 standard [3].
Link Identification Procedures自身はV5.2規格[3]によって説明されます。
A message flow example for an LE initiated Link Identification procedure over V5UA is shown below. An active association between ASP and SG is established prior to the following message flows, and the V5 interface is already in service:
LEがV5UAの上でLink Identification手順に着手したので、メッセージ流れの例は以下に示されます。 ASPとSGとの活動的な協会は以下のメッセージ流れの前に設立されます、そして、V5インタフェースは既に使用中です:
ASP SG
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) -- |
| |
| | | ------ データ要求(LnkCtrl: FE-IDReq)------>|、| <-- データ指示(LnkCtrl Ack: FE-IDReq)--- | | | | <、-、-、-- データ指示(LnkCtrl: FE-IDAck)----- | | ---- データ要求(LnkCtrl Ack: FE-IDAck)---->|、|、|、| ------ Sa-ビット状態要求(Sa7)--------->|、| <-- Sa-ビット状態指示(Sa7、ゼロ)--- | | | | ------- データ要求(LnkCtrl: FE-IDRel)----->|、| <-- データ指示(LnkCtrl Ack: FE-IDRel)--| | |
Weilandt, et al. Standards Track [Page 20] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[20ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
The next example also shows a Link Identification procedure, but this time it is initiated by the AN. Again, the ASP association and the V5 interface are already in service:
また、次の例はLink Identification手順を示していますが、今回、それはANによって開始されます。 一方、ASP協会とV5インタフェースは既に使用中です:
ASP SG
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) ----------- |
| |
| | | <、-、-、-- データ指示(LnkCtrl: FE-IDReq)----- | | -- データ要求(LnkCtrl Ack: FE-IDReq)------>|、|、|、| ---------- Sa-ビットセットReq(Sa7、ゼロ)------>|、| <、-、-、-、-、-、-、-、-- Sa-ビットセットConf(Sa7)-------------- | | | | ------- データ要求(LnkCtrl: FE-IDAck)----->|、| <-- データ指示(LnkCtrl Ack: FE-IDAck)--- | | | | <、-、-、-- データ指示(LnkCtrl: FE-IDRel)----- | | ---- データ要求(LnkCtrl Ack: FE-IDRel)---->|、|、|、| ------------ Sa-ビットセットReq(Sa7、1)----->|、| <、-、-、-、-、-、-、-、-、-、-- Sa-ビットセットConf(Sa7)----------- | | |
7. Security Considerations
7. セキュリティ問題
The security considerations discussed for the 'Security Considerations for SIGTRAN Protocols' [5] document apply to this document.
'SIGTRANプロトコルのためのセキュリティConsiderations'という[5]ドキュメントのために議論したセキュリティ問題はこのドキュメントに適用されます。
8. IANA Considerations
8. IANA問題
8.1. SCTP Payload Protocol Identifiers
8.1. SCTP有効搭載量プロトコル識別子
IANA has assigned a V5UA value for the Payload Protocol Identifier in the SCTP DATA chunk. The following SCTP Payload Protocol identifier is registered:
IANAは有効搭載量プロトコルIdentifierのためにSCTP DATA塊でV5UA値を割り当てました。 以下のSCTP有効搭載量プロトコル識別子は登録されています:
V5UA "6"
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.
「6インチは含まれているコネがSCTPがV5UAプロトコルを運ぶのを示すそれぞれのSCTPデータ塊であるならそうするでしょうに」SCTP有効搭載量プロトコル識別子価値。 値「また、0インチ(不特定の)は許容されていますが、いかなる他の値も使用されているはずがありません」。 この有効搭載量プロトコルIdentifierはSCTPによって直接使用されませんが、あるネットワーク実体によって使用されて、Data塊で運ばれる情報の種類を特定するかもしれません。
Weilandt, et al. Standards Track [Page 21] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[21ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
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.
User Adaptation同輩はSCTPによってそれに提示されるデータに関する追加情報を決定する方法として有効搭載量プロトコルIdentifierを使用するかもしれません。
8.2. V5UA Port Number
8.2. V5UAポートナンバー
IANA has registered SCTP (and UDP/TCP) Port Number 5675 for V5UA.
IANAはV5UAのためにSCTP(そして、UDP/TCP)ポートNumber5675を登録しました。
9. Acknowledgements
9. 承認
The authors would like to thank Fahir Ergincan, Milos Pujic, Graeme Currie, Berthold Jaekle, Ken Morneault and Lyndon Ong for their valuable comments and suggestions.
作者は彼らの貴重なコメントと提案についてFahir Ergincan、ミロスPujic、グレーム・カリー、Berthold Jaekle、ケンMorneault、およびリンドン・オングに感謝したがっています。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN
Q.921-User Adaptation Layer", RFC 3057, February 2001.
[1]MorneaultとK.とRengasamiとS.とカッラとM.とG.Sidebottom、「ISDN Q.921-ユーザ適合層」、RFC3057、2001年2月。
[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.
[2] ETSIアン300 324-1(1999): VはデジタルLocal Exchange(LE)で連結します。 V5.1はAccess Network(AN)のサポートのために連結します。 第1部: V5.1は仕様を連結します。
[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.
[3] ETSIアン300 347-1(1999): VはデジタルLocal Exchange(LE)で連結します。 V5.2はAccess Network(AN)のサポートのために連結します。 第1部: V5.2は仕様を連結します。
[4] ETSI ETS 300 125 (1991) : DSS1 protocol; User-Network interface
data link layer specification; (Standard is based on : ITU
Q.920, Q.921).
[4] ETSIエッツ300 125(1991): DSS1は議定書を作ります。 ユーザネットワーク・インターフェースデータ・リンク層仕様。 (規格は: ITU Q.920、Q.921に基づいています。)
[5] Loughney, J., Tuexen, M., Ed. and J. Pastor-Balbas, "Security
Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
3788, May 2004.
[5]Loughney(J.、Tuexen、M.、エドJ.牧師-Balbas、「シグナリング輸送(SIGTRAN)プロトコルのためのセキュリティ問題」、RFC3788)は2004がそうするかもしれません。
Weilandt, et al. Standards Track [Page 22] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[22ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
10.2. Informative References
10.2. 有益な参照
[6] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[6] スチュワート、R.、シェ、Q.、Morneault、K.、鋭く、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、およびV.パクソンは「制御伝動プロトコルを流します」、RFC2960、2000年10月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
11. Authors' Addresses
11. 作者のアドレス
Dr. Eva Weilandt Conti Temic microelectronic GmbH An der B31 88090 Immenstaad Germany
エバWeilandtコンティTemicマイクロ電子工学博士のGmbH An der B31 88090 Immenstaadドイツ
Phone: +49 7545 8-2917 EMail: eva.weilandt@temic.com
以下に電話をしてください。 +49 7545年の8-2917メール: eva.weilandt@temic.com
Sanjay Rao Nortel Networks 35 Davis Drive Research Triangle Park, NC 27709 USA
Sanjayラオノーテルネットワーク35デイヴィスはリサーチトライアングル公園、NC27709米国を運転します。
Phone: +1-919-991-2251 EMail: rsanjay@nortelnetworks.com
以下に電話をしてください。 +1-919-991-2251 メールしてください: rsanjay@nortelnetworks.com
Neeraj Khanchandani Nortel Networks 35 Davis Drive Research Triangle Park, NC 27709 USA
Neeraj Khanchandaniノーテルネットワーク35デイヴィスはリサーチトライアングル公園、NC27709米国を運転します。
Phone: +1-919-991-2274 EMail: neerajk@nortelnetworks.com
以下に電話をしてください。 +1-919-991-2274 メールしてください: neerajk@nortelnetworks.com
Weilandt, et al. Standards Track [Page 23] RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
Weilandt、他 標準化過程[23ページ]RFC3807V5.2-ユーザ適合層(V5UA)の2004年6月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright(C)インターネット協会(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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Weilandt, et al. Standards Track [Page 24]
Weilandt、他 標準化過程[24ページ]
一覧
スポンサーリンク
