DPNSS/DASS 2 over IUA: Digital Private Network Signaling System (DPNSS)/Digital Access Signaling System 2 (DASS 2) Extensions to the IUA Protocol

Network Working Group                                        R. Mukundan
Request for Comments: 4129                            Wipro Technologies
Category: Standards Track                                   K. Morneault
                                                           Cisco Systems
                                                          N. Mangalpally
                                                         Nortel Networks
                                                             August 2005


           Digital Private Network Signaling System (DPNSS)/
               Digital Access Signaling System 2 (DASS 2)
                     Extensions to the IUA Protocol

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 (2005).

Abstract

   This document defines a mechanism for backhauling Digital Private
   Network Signaling System 1 (DPNSS 1) and Digital Access Signaling
   System 2 (DASS 2) messages over IP by extending the ISDN User
   Adaptation (IUA) Layer Protocol defined in RFC 3057.  DPNSS 1,
   specified in ND1301:2001/03 (formerly BTNR 188), is used to
   interconnect Private Branch Exchanges (PBX) in a private network.
   DASS 2, specified in BTNR 190, is used to connect PBXs to the PSTN.
   This document aims to become an Appendix to IUA and to be the base
   for a DPNSS 1/DASS 2 User Adaptation (DUA) implementation.

Table of Contents

   1.  Introduction .................................................  2
       1.1.  Scope ..................................................  2
       1.2.  Terminology ............................................  3
       1.3.  DPNSS Overview .........................................  4
       1.4.  Proposed DPNSS Backhaul Architecture ...................  5
   2.  Changes from IUA .............................................  5
       2.1.  New Message Class for DUA ..............................  5
       2.2.  Message Header .........................................  6
       2.3.  Unit Data Message ......................................  7
       2.4.  DLC Status Message .....................................  7
       2.5.  Management (MGMT) Messages .............................  9
   3.  IANA Considerations .......................................... 10
   4.  Use of SCTP Payload Protocol ID .............................. 10
   5.  Message Sequence in DUA ...................................... 11
       5.1.  Resetting of single DLC ................................ 11
       5.2.  Resetting all DLCs in a Link ........................... 11
       5.3.  Information Transfer on a DLC .......................... 12
       5.4.  Link Takedown (Single DLC) ............................. 12
       5.5.  Link Takedown (All DLCs) ............................... 12
       5.6.  Getting Link Status .................................... 12
       5.7.  Error Conditions ....................................... 12
   6.  Security Considerations ...................................... 13
   7.  References ................................................... 13
       7.1.  Normative References ................................... 13
   8.  Acknowledgements ............................................. 13

1.  Introduction

   This document describes a method of implementing Digital Private
   Network Signaling System 1 (DPNSS 1) [2] (henceforth referred to as
   just DPNSS) and Digital Access Signaling System 2 (DASS 2)[3]
   backhaul messaging over IP using a modified version of the ISDN User
   Adaptation Protocol (IUAP) [1].  The DPNSS/DASS 2 User Adaptation
   (DUA) builds on top of IUA by defining the necessary extensions to
   IUA for a DPNSS/DASS2 implementation.

1.1.  Scope

   There is a need for Switched Circuit Network (SCN) signaling protocol
   delivery from a DPNSS Signaling Gateway (SG) to a Media Gateway
   Controller (MGC).  The delivery mechanism should support the
   following protocols:

      -  DPNSS (Digital Private Network Signaling System) [2]
      -  DASS 2 (Digital Access Signaling System Number 2) [3]
   Unless specifically mentioned, the details in this document are
   applicable to both DPNSS and DASS 2.

1.2.  Terminology

   Data channel (D-channel) - A 64 kbit/s time slot that functions as a
   common signaling channel on a 2048 kbits/s interface or a 1544
   kbits/s interface that is provisioned to carry DPNSS signaling.

   DPNSS channel - Time slots 1 to 15 and 17 to 31 on a 2048 kbits/s
   interface or Time slots 1 to 23 on a 1544 kbits/s interface are
   termed as DPNSS channels.  These are the traffic channels that carry
   voice or data traffic.

      -  DPNSS supports 60 Channels (30 Real and 30 Virtual)
      -  DASS2 supports 30 Channels (All Real)

   Data Link Connection(DLC) - A DLC is the level 2 process that
   controls the transfer of level 3 messages on behalf of one DPNSS
   channel.  A DLC uniquely identifies one DPNSS channel.

      -  DPNSS supports 60 DLCs (30 Real and 30 Virtual)
      -  DASSII supports 30 DLCs (All Real)

   DPNSS Link -  A logical collection of the D-channel and the
   associated DPNSS channels in a 2048 kbits/s interface or a 1544
   kbits/s interface is called a "DPNSS Link".

   Real channel - A signalling channel with an associated traffic
   channel (TS).

   Virtual channel - A signalling channel with no associated traffic
   channel.

   NT1 - The DPNSS minimum retransmission period.

   NT2 - The DPNSS minimum post retransmission acknowledgement delay.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].

1.3.  DPNSS Overview

   DPNSS is an industry standard interface (ref. ND1301:2001/03) [2],
   which is defined between a PBX and an Access Network (AN).  DPNSS
   extends facilities that are normally only available between
   extensions on a single PBX to all extensions on PBXs that are
   connected in a private network.  DPNSS was originally derived from
   BT's Digital Access Signaling System I (DASS I), and was enhanced
   where necessary to meet the private network requirements.  Some of
   these enhancements were incorporated in DASS 2 [3].  DPNSS uses a
   2048 kbits/s or 1544 kbits/s Digital Transmission System Interface,
   as shown in Figure 1 below.

            ----------              ----------        o--o
            |        | 2048 kbits/s |        |-------  /\
            |        |--------------|        |         --
            |  PBX   | 1544 kbits/s |  AN    |
            |        |--------------|        |        o--o
            |        |              |        |-------  /\
            ----------              ----------         --

                            Figure 1

   Channel 16 is on a 2048 kbits/s (E1) interface and channel 24 is on a
   1544 kbits/s (T1) interface and is reserved for data communication
   between LE and AN.  The channels reserved for data are called "Data
   Channels" or "D-Channels."

   The D-Channels are the physical media used to exchange data between
   the DPNSS protocol peer entities.  A logical collection of the
   D-channel and the associated DPNSS channels is called a "DPNSS Link".

1.4.  Proposed DPNSS Backhaul Architecture

            ******   DPNSS       ******      IP      *******
            *PBX *---------------* SG *--------------* MGC *
            ******               ******              *******

            +-----+                                  +-----+
            |DPNSS|              (NIF)               |DPNSS|
            | L3  |                                  | L3  |
            +-----+           +----------+           +-----+
            |     |           |     | DUA|           | DUA |
            |DPNSS|           |DPNSS+----+           +-----+
            | L2  |           | L2  |SCTP|           |SCTP |
            |     |           |     +----+           +-----+
            |     |           |     | IP +           | IP  |
            +-----+           +-----+----+           +-----+

         NIF  - Nodal Interworking function
         SCTP - Stream Control Transmission Protocol
         DUA  - DPNSS User Adaptation Layer Protocol

2.  Changes from IUA

   This section outlines the differences between DUA and IUA.

2.1.  New Message Class for DUA

   The DPNSS/DASS2 Layer 2 to Layer 3 primitives [2] [3] need to be
   identifiable from IUA boundary primitive transport messages and the
   boundary primitive transport messages of other IUA extensions (i.e.,
   V5 or GR-303).  Therefore, it is necessary to use a different message
   class parameter for DUA messages.

   For all DPNSS/DASS2 interface boundary primitives, a new Message
   Class is introduced:

         13     DPNSS/DASS2 Boundary Primitives Transport Messages
                (DPTM)

   Similar to IUA, other valid message classes for DUA are:

          0       Management (MGMT) Message
          3       ASP State Maintenance (ASPSM) Messages
          4       ASP Traffic Maintenance (ASPTM) Messages

2.2.  Message Header

   The IUA Message Header [1] MUST be used with the DPTM messages, but
   the DLCI field in the DLCI parameter is formatted differently.
   Figure 2 below shows the IUA Message Header with integer-based
   Interface Identifier.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x1)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Interface Identifier (integer)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Tag (0x5)           |             Length=8          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            DLCI               |              Spare            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 2 IUA Message Header (integer-based Interface Identifier)

   In DUA, the DLCI field has a different format, in accordance with the
   ND1301:2001/03 (formerly BTNR 188) [2].

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |   Reserved  |V|0|Channel No.|1|
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Reserved:  7 bits

   Should be set to all '0's and ignored by the receiver.

   V-bit:  1 bit

      The V-bit is used to determine if the message is for a particular
      DLC or if it is applicable for all the DLCs in the carrier.  The
      possible values of the V-bit are listed below:

            Value          Description
              0            Action is to be performed on all DLCs;
                           Channel number parameter is ignored.
              1            Action is to be performed on a single
                           DLC specified by channel number.

      This V-bit value is used only by the Establish and Release
      messages.  Data messages should ignore this value.  This indicator
      is provided so that a single command can be issued to establish or
      release all the DLCs in one DPNSS Link.

   For Channel Number (Channel No.), the valid values are 0 to 63 for
   DPNSS and 0 to 31 for DASS 2.  This is because DASS 2 does not
   support virtual DLCs and, hence, has only 32 DLCs.

2.3.  Unit Data Message

   DPNSS layer 2 does not have a unit data primitive and, hence, the
   Unit Data Messages (Request, Indication) are invalid for a DUA
   application.  The Data Request and Indication messages (message types
   1 and 2, respectively) will be used with DUA.

2.4.  DLC Status Message

   For DUA, a new message is necessary to carry the status of the DLCs.
   This message will be a Management message (i.e., its message class
   will be a value of 0 for Management).  The following message types
   will be used for these messages:

        5        DLC Status Request
        6        DLC Status Confirm
        7        DLC Status Indication

   The DLC Status messages are exchanged between DUA layer peers to
   request, confirm, and indicate the status of the DLCs.  The DLC
   Status messages contain the common message header, followed by IUA
   message header, as described in section 2.2.

   In addition, the DLC Status Confirm and Indication messages will
   contain the new parameter, called the DLC Status parameter.  This
   parameter will have the following format for an E1 interface:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x12)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NA| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NA|D17|D18|D19|D20|D21|D22|D23|D24|D25|D26|D27|D28|D29|D30|D31|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46|D47|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NA|D49|D50|D51|D52|D53|D54|D55|D56|D57|D58|D59|D60|D61|D62|D63|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   NA stands for Not Applicable.  D0 and D16 are not applicable for an
   E1 interface because timeslot 0 is used for E1 framing and
   synchronization bits and timeslot 16 is used for signaling.  For
   DPNSS, there would be a total of max 60 DLCs (30 real + 30 virtual)
   and in case of DASS2 there would be a total of 30 DLCs (no virtuals).

   This parameter will have the following format for a T1 interface:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Tag (0x12)           |             Length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | D0| D1| D2| D3| D4| D5| D6| D7| D8| D9|D10|D11|D12|D13|D14|D15|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |D16|D17|D18|D19|D20|D21|D22| NA|D24|D25|D26|D27|D28|D29|D30|D31|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | NA|D33|D34|D35|D36|D37|D38|D39|D40|D41|D42|D43|D44|D45|D46| NA|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   D23 is not applicable for a T1 interface because timeslot 23 is used
   for signaling.  For DPNSS, there would be a total of max 46 DLCs (23
   real + 23 virtual) and in case of DASS2 there would be a total of 23
   DLCs (no virtuals).

   The parameter carries the status of DLCs using two bits for each DLC.
   The possible values for the two bits are shown below:

         Value          Description
           00        Out Of Service
           01        Reset Attempted
           10        Reset Completed
           11        Information Transfer

   For DASS 2, the value 00 (Out Of Service) is invalid because the DASS
   2 DLC does not have this state.  In addition, the Idle state is a
   transient state local to the DLC, therefore, a value is not allocated
   for it.

   For DASS 2, there are no virtual DLCs and, hence, information about
   only 32 DLCs need to be carried.  Therefore, the status message will
   have a length of 12 for a DASS 2 DLC Status message.

2.5.  Management (MGMT) Messages

   Only the Notify and Error messages are valid for DUA.  The TEI Status
   messages are not used.

2.5.1.  Error Message

   The ERR message is sent when an invalid value or unrecognized message
   is found in an incoming message.

   The Error Code parameter indicates the reason for the Error Message.
   These are the supported values in IUA.

     Invalid Version                               0x01
     Invalid Interface Identifier                  0x02
     Unsupported Message Class                     0x03
     Unsupported Message Type                      0x04
     Unsupported Traffic Handling Mode             0x05
     Unexpected Message                            0x06
     Protocol Error                                0x07
     Unsupported Interface Identifier Type         0x08
     Invalid Stream Identifier                     0x09
     Unassigned TEI                                0x0a
     Unrecognized SAPI                             0x0b
     Invalid TEI, SAPI combination                 0x0c
     Refused - Management Blocking                 0x0d
     ASP Identifier Required                       0x0e
     Invalid ASP Identifier                        0x0f
   In DUA, the error codes 0x0a, 0x0b, and 0x0c are invalid, as they are
   specific to ISDN.

   The following additional error codes are supported in DUA:

        Channel Number out of range                   0x1c
        Channel Number not configured                 0x1d

   The "Channel Number out of range" error is sent if a message is
   received with a channel number greater than 63 for DPNSS or 31 for
   DASS 2.

   The "Channel Number not configured" error is sent if a message is
   received with a channel number that is not configured.

3.  IANA Considerations

   IANA has assigned a DUA value for the SCTP Payload Protocol
   Identifier field that is used in SCTP Payload Data chunks.  The
   following value for the SCTP Payload Protocol Identifier field SHOULD
   be used for DUA:

         SCTP Payload Protocol ID = "10"

4.  Use of SCTP Payload Protocol ID

   As an option, the IUA value for SCTP Payload Protocol ID MAY also be
   used for DUA, for instance, if one wanted to backhaul ISDN and DPNSS
   over the same SCTP association.  However, use of separate SCTP
   Payload Protocol IDs (10 for DUA and 1 for IUA) is recommended as the
   primary option, even in scenarios where ISDN and DPNSS are backhauled
   over the same SCTP association.

   SCTP Payload Protocol ID of "10" SHOULD be used for DUA if only DPNSS
   is backhauled over an SCTP association (i.e., in scenarios where
   simultaneous backhauling of ISDN and DPNSS over the same association
   is NOT required).

   The SCTP Payload Protocol Identifier is included in each SCTP Data
   chunk, to indicate which protocol the SCTP is carrying.  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.

5.  Message Sequence in DUA

   An example of the message flows for establishing a data link on a
   signaling channel, passing PDUs and releasing a data link on a DPNSS
   channel is shown below.  An active association between MGC and SG is
   established prior to the following message flows.

5.1.  Resetting of single DLC

      i)  Successful

       PBX                     SG                        MGC
           <----------- SABMR          <----------- Est Req(Ind=1)
       UA   ----------->       Est Cfm -----------> (DLC in RC State)
                                Ind=1)

      ii) Unsuccessful(Link Failure)

         PBX                     SG                        MGC
           <----------- SABMR         <----------- Est Req(Ind=1)
           Retransmissions over
           NT1 and NT2 expired
                               Rel Ind -----------> (DLC in RA state)
                              (RELEASE_OTHER,Ind=1)

5.2.  Resetting all DLCs in a Link

         PBX                     SG                    MGC
              <----------- SABMR(1)    <----------- Est Req(Ind=0)
              <----------- SABMR(2)
              <----------- SABMR(3)
             .............
              <----------- SABMR(N)
              In each DLC either
              UA is received or
              NT1/NT2 is expired


                                 Est Cfm -----------> (Status of DLCs
                                 (Ind=0)               are not updated)
                                         <----------- Status Req
                               Status cfm ----------> (Mark DLC status
                                                       based on
                                                       status bits)

   If one of more DLCs remains out-of-service after this procedure
   (e.g., due to layer 2 management), the MGC can either retry this DLC
   with an Est Req(Ind=1) indicating the specific DLC or with an
   Est Req(Ind=0) and the SG will retry the appropriate DLC that is
   out-of-service.

5.3.  Information Transfer on a DLC

            PBX                     SG                        MGC
                 <----------- UI(C)            <----------- Data Req
            UI(R)----------->         Data Ind ----------->

5.4.  Link Takedown (Single DLC)

            PBX                     SG                        MGC
                (For DPNSS, mark DLC as OOS)   <----------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                            Ind=1)
                                      Rel Cfm  ---------->
                                      (Ind=1)

5.5.  Link Takedown (All DLCs)

            PBX                     SG                        MGC
                (For DPNSS, mark all DLCs as OOS) <-------- Rel Req
                (For DASSII, mark DLC as RA)              (RELEASE_MGMT,
                                                            Ind=0)
                                        Rel Cfm  ---------->
                                        (Ind=0)

5.6.  Getting Link Status

            PBX                     SG                        MGC
                                           <-----------  Stat Req
                                  Stat Cfm -----------> (Mark DLC status
                                                         based on
                                                         status bits)

5.7.  Error Conditions

            PBX                     SG                        MGC
                              Invalid Message <-----------Est/Rel/Data/-
                                                           Stat Req
                                 Error Ind    ----------->
                                (Error Code)

6.  Security Considerations

   The security considerations for the ISDN User Adaptation Protocol
   (IUAP) [1] (Section 6) and the security considerations for SIGTRAN
   Protocols document [4] apply to this document as well.

7.  References

7.1.  Normative References

   [1]  Morneault, K., Rengasami, S., Kalla, M., and G. Sidebottom,
        "ISDN Q.921-User Adaptation Layer", RFC 3057, February 2001.

   [2] Ofcom/NICC ND1301:2001/03, DPNSS [188], Digital Private
        Signalling System No 1 (DPNSS 1) (Formerly BTNR 188).

   [3]  BTNR (British Telecom Network Requirements) 190 Issue 2 Digital
        Access Signaling System No 2.

   [4]  Loughney, J., Tuexen, M., and J. Pastor-Balbas, "Security
        Considerations for Signaling Transport (SIGTRAN) Protocols", RFC
        3788, June 2004.

   [5]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

8.  Acknowledgements

   The authors would like to thank Shashi Kumar and Venkatesh Seshasayee
   of Wipro Technologies for their useful suggestions and comments.

Authors' Addresses

   All correspondence regarding this document should be sent to the
   following addresses:

   Ranjith Mukundan
   Wipro Technologies
   72, Electronics City
   Hosur Main Road
   Bangalore 560100
   India

   Phone: +91-80-51195893
   EMail: ranjith.mukundan@wipro.com


   Ken Morneault
   Cisco Systems Inc.
   13615 Dulles Technology Drive
   Herndon, VA. 20171
   USA

   Phone: +1-703-484-3323
   EMail: kmorneau@cisco.com


   Narsimuloo Mangalpally
   Nortel Networks
   250 Sidney Street
   Belleville, Ontario K8P 3Z3
   Canada

   Phone: +1-613-967-5034
   EMail: narsim@nortelnetworks.com

Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   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.