IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol (BAP)
draft-arkko-pppext-bap-ianafix-02

Versions: 00 01 02                                                      
Network Working Group                                           J. Arkko
Internet-Draft                                                  Ericsson
Updates: 2125 (if approved)                                   J. Carlson
Intended status: BCP                                         Workingcode
Expires: March 11, 2010                                         A. Baber
                                                                   ICANN
                                                       September 7, 2009


  IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol
                                 (BAP)
                   draft-arkko-pppext-bap-ianafix-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 11, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Arkko, et al.            Expires March 11, 2010                 [Page 1]


Internet-Draft               BAP IANA Rules               September 2009


Abstract

   This document specifies the IANA guidelines for allocating new values
   in the PPP Bandwidth Allocation and Bandwidth Allocation Control
   Protocols.


1.  Introduction

   This document specifies the IANA guidelines [RFC5226] for allocating
   new values for various fields in the PPP Bandwidth Allocation
   Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP)
   [RFC2125].  BACP is the control protocol for BAP, and is used to
   manage the dynamic bandwidth allocation of implementations supporting
   the PPP multilink protocol [RFC1990].

   The IANA guidelines are given in Section 2.  Previously, no IANA
   guidance existed for such allocations either in [RFC2125] or
   [RFC3818].  The purpose of this document is to allow IANA to manage
   number assignments based on these guidelines in a consistent manner.
   This document also points to [RFC2153] which allows the construction
   of vendor-specific packets and options.  These mechanisms may also be
   used for temporary experimental extensions, alleviating the need to
   allocate specific experimental values in this document.


2.  IANA Considerations

   The IANA is instructed to create the following registries.  For all
   the registries, new values can be allocated through RFC Required
   [RFC5226].

   IANA is instructed to create a registry for the BACP option values.
   The initial contents of the registry should be as follows:

   Registry Name: PPP BACP Configuration Option Types
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Type     Configuration Option     Reference
   ----     --------------------     ---------
   0        Vendor-Specific          [RFC2153]
   1        Favored-Peer             [RFC2125]
   2-255    Unassigned

   IANA is also instructed to create a registry for the BAP Type field.
   The initial contents of the registry should be as follows:




Arkko, et al.            Expires March 11, 2010                 [Page 2]


Internet-Draft               BAP IANA Rules               September 2009


   Registry Name: PPP BAP Type
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Type     Datagram                 Reference
   ----     --------------------     ---------
   0        Vendor-Specific          [RFC 2153]
   1        Call-Request             [RFC 2125]
   2        Call-Response            [RFC 2125]
   3        Callback-Request         [RFC 2125]
   4        Callback-Response        [RFC 2125]
   5        Link-Drop-Query-Request  [RFC 2125]
   6        Link-Drop-Query-Response [RFC 2125]
   7        Call-Status-Indication   [RFC 2125]
   8        Call-Status-Response     [RFC 2125]
   9-255    Unassigned

   IANA is also instructed to create a registry for the BAP Response
   Code field.  The initial contents of the registry should be as
   follows:

   Registry Name: PPP BAP Response Code
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Value    Response Code            Reference
   ----     --------------------     ---------
   0        Request-Ack              [RFC 2125]
   1        Request-Nak              [RFC 2125]
   2        Request-Rej              [RFC 2125]
   3        Request-Full-Nak         [RFC 2125]
   4-255    Unassigned

   IANA is also instructed to create a registry for the BAP Datagram
   Option Type field.  The initial contents of the registry should be as
   follows:















Arkko, et al.            Expires March 11, 2010                 [Page 3]


Internet-Draft               BAP IANA Rules               September 2009


   Registry Name: PPP BAP Datagram Option Type
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Type     Datagram Option          Reference
   ----     --------------------     ---------
   0        Vendor-Specific          [RFC 2153]
   1        Link-Type                [RFC 2125]
   2        Phone-Delta              [RFC 2125]
   3        No-Phone-Number-Needed   [RFC 2125]
   4        Reason                   [RFC 2125]
   5        Link-Discriminator       [RFC 2125]
   6        Call-Status              [RFC 2125]
   7-255    Unassigned

   IANA is also instructed to create a registry for the BAP Link Type
   field.  The initial contents of the registry should be as follows:

   Registry Name: PPP BAP Link Type
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Bit      Link Type                   Reference
   ----     --------------------        ---------
   0        ISDN                        [RFC 2125]
   1        X.25                        [RFC 2125]
   2        analog                      [RFC 2125]
   3        switched digital (non-ISDN) [RFC 2125]
   4        ISDN data over voice        [RFC 2125]
   5-7      Unassigned

   Note the order of bits in this field as specified in Section 6.1 of
   [RFC2125]: bit 0 of the Link Type field corresponds to bit 39 of the
   Link-Type BAP Option.  Also note that bits 5-7 were originally marked
   reserved [RFC2125], but this RFC makes them in principle available
   for allocation.  New allocations are discouraged, however, as it
   would be difficult to assess the impacts new bits might have on
   interoperability with existing implementations.

   IANA is also instructed to create a registry for the BAP Phone-Delta
   Sub-Option Type field.  The initial contents of the registry should
   be as follows:









Arkko, et al.            Expires March 11, 2010                 [Page 4]


Internet-Draft               BAP IANA Rules               September 2009


   Registry Name: PPP BAP Phone-Delta Sub-Option Type
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Type     Sub-Option               Reference
   ----     --------------------     ---------
   0        Vendor-Specific          [RFC 2153]
   1        Unique-Digits            [RFC 2125]
   2        Subscriber-Number        [RFC 2125]
   3        Phone-Number-Sub-Address [RFC 2125]
   4-255    Unassigned

   IANA is also instructed to create a registry for the BAP Call Status
   field.  The initial contents of the registry should be as follows:

   Registry Name: PPP BAP Call Status
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Value    Call Status              Reference
   -----    --------------------     ---------
   0        Success                  [RFC 2125]
   1-254    Q.931 values             [RFC 2125] [ITU.Q931.1993]
   255      Non-specific failure     [RFC 2125]

   IANA is also instructed to create a registry for the BAP Call Action
   field.  The initial contents of the registry should be as follows:

   Registry Name: PPP BAP Call Action
   Reference: [RFC2125 and XXX THIS RFC]
   Registration Procedures: RFC Required

   Value    Action                   Reference
   -----    --------------------     ---------
   0        No retry                 [RFC 2125]
   1        Retry                    [RFC 2125]
   2-255    Unassigned


3.  Security Considerations

   This specification does not change the security properties of BAP or
   BACP.

   However, a few words are necessary about the use of vendor-specific
   extensions.  Obviously, the use of vendor-specific extensions affects
   interoperability.  General purpose extensions would be better defined
   as standard extensions.  Similarly, if vendor-specific extensions are



Arkko, et al.            Expires March 11, 2010                 [Page 5]


Internet-Draft               BAP IANA Rules               September 2009


   used to test temporary experimental designs, guidance given in
   [RFC3692] should be followed to avoid potentially harmful side-
   effects.


4.  Acknowledgments

   The lack of any registration procedures has come up in IANA's review
   of existing registries and RFCs.


5.  References

5.1.  Normative References

   [RFC2125]  Richards, C. and K. Smith, "The PPP Bandwidth Allocation
              Protocol (BAP) The PPP Bandwidth Allocation Control
              Protocol (BACP)", RFC 2125, March 1997.

   [RFC2153]  Simpson, W. and K. Fox, "PPP Vendor Extensions", RFC 2153,
              May 1997.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

5.2.  Informative References

   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              August 1996.

   [RFC3818]  Schryver, V., "IANA Considerations for the Point-to-Point
              Protocol (PPP)", BCP 88, RFC 3818, June 2004.

   [ITU.Q931.1993]
              International Telecommunications Union, "ISDN user-network
              interface layer 3 specification for basic call control",
              ITU-T Recommendation Q.931, May 1993.


Appendix A.  Changes from the Original RFCs

   This document specifies only the IANA rules associated with various
   fields in BAP and BACP, and does not change the operation of the



Arkko, et al.            Expires March 11, 2010                 [Page 6]


Internet-Draft               BAP IANA Rules               September 2009


   protocols themselves.


Appendix B.  Acknowledgments

   The authors would like to thank Carlos Pignataro, Eswaran Srinivasan,
   Ignacio Goyret, and Bill Simpson for feedback.


Authors' Addresses

   Jari Arkko
   Ericsson
   Jorvas  02420
   Finland

   Email: jari.arkko@piuha.net


   James D. Carlson
   Workingcode

   Email: carlsonj@workingcode.com


   Amanda Baber
   ICANN

   Email: amanda.baber@icann.org






















Arkko, et al.            Expires March 11, 2010                 [Page 7]