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.

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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) for allocating new values for various fields in the PPP Bandwidth Allocation Protocol (BAP) and Bandwidth Allocation Control Protocol (BACP) [RFC2125] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.). BACP is the control protocol for BAP, and is used to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [RFC1990] (Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, “The PPP Multilink Protocol (MP),” August 1996.).

The IANA guidelines are given in Section 2 (IANA Considerations). Previously, no IANA guidance existed for such allocations either in [RFC2125] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.) or [RFC3818] (Schryver, V., “IANA Considerations for the Point-to-Point Protocol (PPP),” June 2004.). 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] (Simpson, W. and K. Fox, “PPP Vendor Extensions,” May 1997.) 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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.).

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:

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:

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] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.): 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] (Richards, C. and K. Smith, “The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP),” March 1997.), 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:

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 used to test temporary experimental designs, guidance given in [RFC3692] (Narten, T., “Assigning Experimental and Testing Numbers Considered Useful,” January 2004.) 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

5.2. Informative References

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 protocols themselves.

Appendix B.  Acknowledgments

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

Authors' Addresses