Network Working Group J. Arkko
Internet-Draft Ericsson
Updates: 2125 (if approved) J. Carlson
Intended status: BCP Workingcode
Expires: March 9, 2010 A. Baber
ICANN
September 5, 2009
IANA Allocation Guidelines for the PPP Bandwidth Allocation Protocol
(BAP)
draft-arkko-pppext-bap-ianafix-01
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 9, 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 9, 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.
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 9, 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 9, 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 9, 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.
4. Acknowledgments
The lack of any registration procedures has come up in IANA's review
Arkko, et al. Expires March 9, 2010 [Page 5]
Internet-Draft BAP IANA Rules September 2009
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.
[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
protocols themselves.
Appendix B. Acknowledgments
The authors would like to thank Carlos Pignataro, Eswaran Srinivasan,
Ignacio Goyret, and Bill Simpson for feedback.
Arkko, et al. Expires March 9, 2010 [Page 6]
Internet-Draft BAP IANA Rules September 2009
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 9, 2010 [Page 7]