doc: Add RFC documents

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]
+