Internet Engineering Task Force J. Loughney
Internet-Draft Nokia
Expires: November 17, 2005 May 16, 2005
NSIS Extensibility Model
draft-loughney-nsis-ext-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 November 17, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document discusses the Next Steps in Signaling extensibility
model. This model is based upon a two-layer model, where there is a
transport layer and a signaling application model. This two-layer
provides the ability to develope new signaling applications, while
retaining the use of a common transport layer.
Loughney Expires November 17, 2005 [Page 1]
Internet-Draft NSIS Extensibility Model May 2005
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NTLP Extensibility . . . . . . . . . . . . . . . . . . . . . . 5
3.1 GIMPS Message Type . . . . . . . . . . . . . . . . . . . . 5
3.2 NSLP Identifiers . . . . . . . . . . . . . . . . . . . . . 5
3.3 Object Types . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Extensibility Flags . . . . . . . . . . . . . . . . . . . 6
3.5 Message Routing Methods . . . . . . . . . . . . . . . . . 6
3.6 Protocol Indicators . . . . . . . . . . . . . . . . . . . 6
3.7 Error Classes . . . . . . . . . . . . . . . . . . . . . . 6
3.8 Error Codes . . . . . . . . . . . . . . . . . . . . . . . 6
4. NSLP Extensibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1 NAT FW NSLP Extensibility . . . . . . . . . . . . . . . . 7
4.2 QoS NSLP Extensibility . . . . . . . . . . . . . . . . . . 7
5. QoS Model Extensibility . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1 Normative References . . . . . . . . . . . . . . . . . . . 12
9.2 Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 14
Loughney Expires November 17, 2005 [Page 2]
Internet-Draft NSIS Extensibility Model May 2005
1. Requirements notation
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 [RFC2119].
Loughney Expires November 17, 2005 [Page 3]
Internet-Draft NSIS Extensibility Model May 2005
2. Introduction
The Next Steps in Signaling Framework NSIS Framework
[I-D.ietf-nsis-fw] details a basic two-layer framework for signaling
on the Internet. The document decomposes signaling into a two-layer
model, into a generic transport layer and specific signaling layers.
This model allows for an extensible model for different signaling
needs on the the Internet. Currently, the NSIS working group is
working on two main signaling applications - QoS signaling [I-D.ietf-
nsis-qos-nslp] and Nat/Firewall signaling [I-D.ietf-nsis-nslp-natfw].
The NSIS Transport Layer Protocol (NTLP) NTLP [I-D.ietf-nsis-ntlp]
defines a basic protocol for routing and transport of per-flow
signaling along the path taken by that flow through the network;
managing the underlying transport and security protocols.
Above the NTLP are one or more NSIS Signaling Layer protocols, which
can signal for things such as QoS, firewall control and NAT signaling
QoS NSLP [I-D.ietf-nsis-qos-nslp], NAT/FW NSLP [I-D.ietf-nsis-nslp-
natfw]. These signaling applications manage their state by using the
services that the NTLP provides them for signaling.
This two layer approach allows for signaling applications to be
developed indepently of the transport. As it is likely that the
functionality entities for different signaling applications will be
distinct, the
Loughney Expires November 17, 2005 [Page 4]
Internet-Draft NSIS Extensibility Model May 2005
3. NTLP Extensibility
The NTLP name space, identified by IANA, is divided into ranges. The
extensibility rules for the ranges defined in the NTLP space are
based upon the procedures by which IANA assigns values: "Standards
Action" (as defined in [IANA]), "IETF Action", "Expert Review", and
"Organization/Vendor Private", defined below.
Extensions subject to "IETF Action" require either a Standards Track
RFC, Experimental RFC or an Information RFC.
Extensions subject to "Expert Review" refer to values that are to be
reviewed by an Expert designated by the IESG. The code points from
these ranges are typically used for experimental extensions; such
assignments MUST be requested by either Experimental or Information
RFCs that document their use and processing, and the actual
assignments made during the IANA actions for the document. Values
from "Expert Review" ranges MUST be registered with IANA.
"Organization/Vendor Private" ranges refer to values that are
enterprise-specific. In this way, different enterprises, vendors, or
Standards Development Organizations (SDOs) can use the same code
point without fear of collision.
NTLP specifies the following registries listed below.
3.1 GIMPS Message Type
The NTLP common header contains a one-byte message type field
(initially distinguishing Query, Response, Confirm and Data
messages). New message types require Standards Action.
3.2 NSLP Identifiers
Each signaling application requires one of more NSLPIDs (different
NSLPIDs may be used to distinguish different classes of signaling
node, for example to handle different aggregation levels or different
processing subsets). An NSLPID must be associated with a unique RAO
value. IETF Action is required to allocate a new NSLP Identifier.
3.3 Object Types
The generic object header as a field which distinguish differentes
ranges for different allocation styles (standards action, expert
review etc.) and different applicability scopes (experimental/
private, NSLP-specific); by default, object types are public and
shared between all NSLPs. When a new object type is defined, the
extensibility bits must also be defined.
Loughney Expires November 17, 2005 [Page 5]
Internet-Draft NSIS Extensibility Model May 2005
3.4 Extensibility Flags
The generic object header defined in NTLP contains reserved flag
bits. These are reserved for the definition of more complex
extensibility encoding schemes. Standards Action is required to
define new Extensibility Flags.
3.5 Message Routing Methods
NTLP allows the idea of multiple message routing methods. The
message routing method is indicated in the leading 2 bytes of the MRI
object. NTLP allocates 2 bits for experimental Routing Methods, for
use in closed networks for experimentation purposes. Standards
Action is required to allocate new Routing Methods.
3.6 Protocol Indicators
The GIMPS design allows the set of possible protocols to be used in a
messaging association to be extended. Every new mode of using a
protocol is given by a Protocol Indicator, which is used as a tag in
the Node Addressing and Stack Proposal objects. New protocol
indicators require IETF Action. Allocating a new protocol indicator
requires defining the higher layer addressing information in the Node
Addressing Object that is needed to define its configuration.
3.7 Error Classes
The Error Classes are primarily to aid human or management
interpretation of otherwise unknown error codes. These are allocated
on an Expert Review basis.
3.8 Error Codes
Error codes are shared across all NSLPs. When a new error code is
allocated, the Error Class and the format of any associated error-
specific information must also be defined. These are allocated on an
Expert Review basis.
Loughney Expires November 17, 2005 [Page 6]
Internet-Draft NSIS Extensibility Model May 2005
4. NSLP Extensibility
4.1 NAT FW NSLP Extensibility
TBA
4.2 QoS NSLP Extensibility
TBA
Loughney Expires November 17, 2005 [Page 7]
Internet-Draft NSIS Extensibility Model May 2005
5. QoS Model Extensibility
The QoS NSLP provides signaling for QoS reservations on the Internet.
The QoS NSLP decouples the resource reservation model or architecture
from the signaling. The QoS specification is defined in QSpec
[I-D.ietf-nsis-qspec]. New QSpecs require IETF action, which defines
the elements within the QSpec.
Loughney Expires November 17, 2005 [Page 8]
Internet-Draft NSIS Extensibility Model May 2005
6. IANA Considerations
This document outlines the basic rules for extending NSIS protocols.
This instructions IANA on allocation policies for NSIS protocols.
Loughney Expires November 17, 2005 [Page 9]
Internet-Draft NSIS Extensibility Model May 2005
7. Security Considerations
This document is an informational document, outlining the
extensibility model of the NSIS protocol suite. As such, this
document does not impact the security of the Internet directly.
Loughney Expires November 17, 2005 [Page 10]
Internet-Draft NSIS Extensibility Model May 2005
8. Acknowledgements
This document borrows some ideas and some text from RFC3936
[RFC3936], Procedures for Modifying the Resource reSerVation Protocol
(RSVP).
Loughney Expires November 17, 2005 [Page 11]
Internet-Draft NSIS Extensibility Model May 2005
9. References
9.1 Normative References
[I-D.ietf-nsis-fw]
Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-07 (work in progress), December 2004.
[I-D.ietf-nsis-nslp-natfw]
Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer
Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-05 (work in
progress), February 2005.
[I-D.ietf-nsis-ntlp]
Schulzrinne, H., "GIMPS: General Internet Messaging
Protocol for Signaling", draft-ietf-nsis-ntlp-05 (work in
progress), February 2005.
[I-D.ietf-nsis-qos-nslp]
Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-06
(work in progress), February 2005.
[I-D.ietf-nsis-qspec]
Ash, J., "QoS-NSLP QSpec Template",
draft-ietf-nsis-qspec-03 (work in progress),
February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2 Informative References
[RFC3936] Kompella, K. and J. Lang, "Procedures for Modifying the
Resource reSerVation Protocol (RSVP)", BCP 96, RFC 3936,
October 2004.
Loughney Expires November 17, 2005 [Page 12]
Internet-Draft NSIS Extensibility Model May 2005
Author's Address
John Loughney
Nokia
Itamerenkatu 11-13
Helsinki 00180
Finland
Phone: +358504836242
Email: john.loughney@nokia.com
Loughney Expires November 17, 2005 [Page 13]
Internet-Draft NSIS Extensibility Model May 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Loughney Expires November 17, 2005 [Page 14]