summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3807.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3807.txt')
-rw-r--r--doc/rfc/rfc3807.txt1347
1 files changed, 1347 insertions, 0 deletions
diff --git a/doc/rfc/rfc3807.txt b/doc/rfc/rfc3807.txt
new file mode 100644
index 0000000..e890f18
--- /dev/null
+++ b/doc/rfc/rfc3807.txt
@@ -0,0 +1,1347 @@
+
+
+
+
+
+
+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)
+
+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.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+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 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
+
+
+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
+
+ 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.
+
+
+
+
+
+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.
+
+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].
+
+ 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.
+
+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.
+
+ 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
+
+ - 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
+
+
+ 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:
+
+ 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
+ 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.
+
+
+
+
+
+
+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.
+
+ 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. In contrast, 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
+ "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".
+
+
+
+
+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:
+
+ - 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
+ 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 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:
+
+ Layer 2:
+ - LAPV5-EF
+ - LAPV5-DL
+
+ 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
+
+
+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.
+
+ 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.
+
+ Dynamic TEI Management for V5 BRI over V5UA SHALL be located on the
+ MGC.
+
+1.5. Client/Server Model
+
+ 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.
+
+1.6. Addition to 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.
+
+ 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
+
+
+ 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
+
+ The MDL-Establish primitives are used to request, indicate and
+ confirm the outcome of the procedures for establishing multiple frame
+ operation.
+
+ MDL-RELEASE
+
+ 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.
+
+ 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 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
+
+ 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
+
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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
+
+ 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
+
+ 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
+
+
+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.
+
+ In addition, one separate SCTP stream SHOULD be used for all MPH
+ (link related) messages.
+
+4. Proposed V5.2 Backhaul Architecture
+
+ ****** 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 10]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+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:
+
+ 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
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ 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
+
+
+ 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
+
+ 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.
+
+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 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.
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 12]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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.
+
+ 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.
+
+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
+ distinguish between these two message types by means of the Message
+ Class parameter.
+
+ For all V5 interface boundary primitives, a new Message Class is
+ introduced:
+
+ 14 V5 Boundary Primitives Transport
+ Messages (V5PTM)
+
+ Other valid message classes for V5UA, which are also used by IUA,
+ are:
+
+ 0 Management (MGMT) Message
+ 3 ASP State Maintenance (ASPSM) Messages
+ 4 ASP Traffic Maintenance (ASPTM) Messages
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 13]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ Q.921/Q.931 boundary primitive messages reused by V5.2 as V5PTM
+ messages 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 similarly to the QPTM messages.
+ In addition, 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, Indication)
+
+ 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.
+
+ 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
+ significance only, and is coordinated between the SG and MGC. It
+ MUST be unique for every V5 link on the SG.
+
+ 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.
+
+
+
+Weilandt, et al. Standards Track [Page 14]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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.
+
+ 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.
+
+ 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 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.
+
+ 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.
+
+ 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.
+
+ 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.
+
+ 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:
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 15]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The valid values for Link Status are shown in the following table:
+
+ Define Value Description
+
+ OPERATIONAL 0x0 Link operational
+ NON-OPERATIONAL 0x1 Link not operational
+
+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 for the Link Identification procedure as
+ described by the V5 standards [3].
+
+ 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.
+
+ The Link Identifier MUST be the same as used in the Interface
+ Identifier to identify on which link a C-channel is located.
+
+ The Sa-Bit Set Request message is used to set the value of the
+ 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.
+
+ The Sa-Bit Set Request message for the Sa7 bit with Bit Value ZERO
+ corresponds to the V5 defined primitive MPH-ID. The Sa-Bit Set
+ Request message for the Sa7 bit with Bit Value ONE corresponds to the
+ V5 defined primitive MPH-NOR.
+
+ The SG MUST answer a Sa-Bit Set Request message with a Sa-Bit Set
+ Confirm message when the setting of the bit is complete. This
+ message does not correspond to a V5 defined primitive.
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 16]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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.
+
+ L1 FSM answers the Sa-Bit Status request message by a Sa-Bit Status
+ Indication message in which the current setting of the bit will be
+ reported. The Sa-Bit Status Indication message for the Sa7 bit with
+ Bit Value ZERO corresponds to the V5 defined primitive MPH-IDI. The
+ Sa-Bit Status Indication message for the Sa7 bit with Bit Value ONE
+ corresponds to the V5 defined primitive MPH-Elg.
+
+ All Sa-Bit Messages contain the following additional parameter:
+
+ 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 |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The valid values for Bit Value are shown in the following table:
+
+ Define Value Description
+
+ ZERO 0x0 Bit value ZERO
+ ONE 0x1 Bit value ONE
+
+ The valid value for BIT ID is shown in the following table:
+
+ 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
+ SHALL be set to '0' by the sender and SHALL 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 at the SG.
+
+
+
+
+Weilandt, et al. Standards Track [Page 17]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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).
+
+ The Error Indication message SHALL contain the V5UA message header.
+
+ The Interface Identifier indicates the affected C-channel. SAPI, TEI
+ and EFA SHALL be set to '0' and SHALL be ignored by the receiver.
+
+ The Error Indication message contains the following additional
+ 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 (0x84) | 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.
+
+5. Procedures
+
+5.1. V5 Layer 1 failure
+
+ The normal way to handle a V5 Layer 1 failure is described in the V5
+ standards[2,3] as follows:
+
+ - 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.
+
+ - V5 System management notifies V5 Layer 2 of the V5 Layer 1
+ outage by sending a MPH-Layer_1 Failure Ind primitive.
+
+ 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
+
+
+
+Weilandt, et al. Standards Track [Page 18]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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.
+
+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 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.
+
+ An example for the message flow for re-establishment of the
+ connection is shown below for one active link on the 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.
+
+5.3. C-channel overload on SG
+
+ 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.
+
+ 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.
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 19]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+6. Examples
+
+6.1. Link Identification Procedure (successful)
+
+ The Link Identification Procedures themselves are described by the
+ V5.2 standard [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:
+
+ 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) -- |
+ | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 20]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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:
+
+ 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
+
+ The security considerations discussed for the 'Security
+ Considerations for SIGTRAN Protocols' [5] document apply to this
+ document.
+
+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.
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 21]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+ 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.
+
+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
+ valuable comments and suggestions.
+
+10. References
+
+10.1. Normative References
+
+ [1] Morneault, K., Rengasami, S., Kalla, M. and G. Sidebottom, "ISDN
+ Q.921-User Adaptation Layer", RFC 3057, 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] Loughney, J., Tuexen, M., Ed. and J. Pastor-Balbas, "Security
+ Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
+ 3788, May 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 22]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+10.2. Informative References
+
+ [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.
+
+ [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+11. Authors' Addresses
+
+ Dr. Eva Weilandt
+ Conti Temic microelectronic GmbH
+ An der B31
+ 88090 Immenstaad
+ Germany
+
+ Phone: +49 7545 8-2917
+ EMail: eva.weilandt@temic.com
+
+
+ Sanjay Rao
+ Nortel Networks
+ 35 Davis Drive
+ Research Triangle Park, NC 27709
+ USA
+
+ Phone: +1-919-991-2251
+ EMail: rsanjay@nortelnetworks.com
+
+
+ Neeraj Khanchandani
+ Nortel Networks
+ 35 Davis Drive
+ Research Triangle Park, NC 27709
+ USA
+
+ Phone: +1-919-991-2274
+ EMail: neerajk@nortelnetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 23]
+
+RFC 3807 V5.2-User Adaptation Layer (V5UA) June 2004
+
+
+12. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004). All Rights Reserved.
+
+ Copyright (C) The Internet Society (2004). This document is subject
+ to the rights, licenses and restrictions contained in BCP 78, and
+ except as set forth therein, the authors retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Weilandt, et al. Standards Track [Page 24]
+