[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-nsis-ext

Internet Engineering Task Force                              J. Loughney
Internet-Draft                                                     Nokia
Expires: January 19, 2006                                  July 18, 2005


                        NSIS Extensibility Model
                     draft-loughney-nsis-ext-01.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 January 19, 2006.

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 January 19, 2006                [Page 1]


Internet-Draft          NSIS Extensibility Model               July 2005


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  NTLP Extensibility . . . . . . . . . . . . . . . . . . . . . .  3
     3.1   GIMPS Message Type . . . . . . . . . . . . . . . . . . . .  4
     3.2   NSLP Identifiers . . . . . . . . . . . . . . . . . . . . .  4
     3.3   Object Types . . . . . . . . . . . . . . . . . . . . . . .  4
     3.4   Extensibility Flags  . . . . . . . . . . . . . . . . . . .  4
     3.5   Message Routing Methods  . . . . . . . . . . . . . . . . .  4
     3.6   Protocol Indicators  . . . . . . . . . . . . . . . . . . .  5
     3.7   Error Classes  . . . . . . . . . . . . . . . . . . . . . .  5
     3.8   Error Codes  . . . . . . . . . . . . . . . . . . . . . . .  5
     3.9   Router Alert Values  . . . . . . . . . . . . . . . . . . .  5
   4.  NSLP Extensibility . . . . . . . . . . . . . . . . . . . . . .  7
     4.1   Common Functionality Among Signaling Applications  . . . .  7
       4.1.1   Common Error Codes . . . . . . . . . . . . . . . . . .  7
     4.2   NAT FW NSLP Extensibility  . . . . . . . . . . . . . . . .  7
     4.3   QoS NSLP Extensibility . . . . . . . . . . . . . . . . . .  7
   5.  QoS Model Extensibility  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     9.1   Normative References . . . . . . . . . . . . . . . . . . .  8
     9.2   Informative References . . . . . . . . . . . . . . . . . .  8
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  8
       Intellectual Property and Copyright Statements . . . . . . . .  9























Loughney                Expires January 19, 2006                [Page 2]


Internet-Draft          NSIS Extensibility Model               July 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 [1].

2.  Introduction

   The Next Steps in Signaling Framework NSIS Framework [2] 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 [3] and
   Nat/Firewall signaling [4].

   The NSIS Transport Layer Protocol (NTLP) NTLP [5] 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 [3], NAT/FW NSLP [4].  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

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



Loughney                Expires January 19, 2006                [Page 3]


Internet-Draft          NSIS Extensibility Model               July 2005


   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.

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



Loughney                Expires January 19, 2006                [Page 4]


Internet-Draft          NSIS Extensibility Model               July 2005


   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.

3.9  Router Alert Values

   Router Alert Option (RAO) values are allocated on the basis of IETF
   consensis.  However, new RAO values SHOULD NOT be allocated for each
   new NSLP.  Careful consideration needs to be exercised when choosing
   to allocate a new RAO value.  This section discusses some
   considerations on how to choose if an existing RAO option should be
   chosen or a new RAO should be allocated for an NSLP

   The RAO contains a 16 bit value field, 35 values which have currently
   been assigned by IANA.  The use of the RAO is the primary mechanism
   to indicate that an NTLP message should be intercepted by a
   particular node.  There are two basic reasons why a NTLP node might
   wish not to intercept a particular message.  The first reason would
   be because the message is for a signaling application that the node
   does not process.  The second reason would be because the node is
   processes signaling messages at the aggregate level, not for
   individual flow, even though the signaling application is present on
   the node.  However, these reasons do not preclude a node processing
   several RAO values, implying it supports several different signaling
   applications.

   Some of this information can be encoded in the RAO value field, which



Loughney                Expires January 19, 2006                [Page 5]


Internet-Draft          NSIS Extensibility Model               July 2005


   then allows messages to be filtered on the fast path.  There is a
   tradeoff between two approaches here, whose evaluation depends on
   whether the processing node is specialised or general purpose:

   Fine-Grained: The signaling application (including specific version)
   and aggregation level are directly identified in the RAO value.  A
   specialised node which handles only a single NSLP can efficiently
   ignore all other messages; a general purpose node may have to match
   the RAO value in a message against a long list of possible values.

   Coarse-Grained> RAO values are allocated are ased on common
   applications or sets of applications (such as 'All QoS Signaling
   Applications').  This speeds up the processing in a general purpose
   node, but a specialised node may have to carry out further processing
   on the NTLP common header to identify the precise messages it needs
   to consider.

   These considerations imply that the RAO value should not be tied
   directly to the NSLPID, but should be selected for the application on
   broader considerations of likely deployment scenarios.  Note that the
   exact NSLP is given in the GIMPS common header, and some
   implementations may still be able to process it on the fast path.
   The semantics of the node dropping out of the signaling path are the
   same however the filtering is done.

   There is a special consideration in the case of the aggregation
   level.  In this case, whether a message should be processed depends
   on the network region it is in (specifically, the link it is on).
   There are then two basic possibilities:

   All routers have essentially the same algorithm for which messages
   they process, i.e. all messages at aggregation level 0.  However,
   messages have their aggregation level incremented on entry to an
   aggregation region and decremented on exit.

   Router interfaces are configured to process messages only above a
   certain aggregation level and ignore all others.  The aggregation
   level of a message is never changed; signaling messages for end to
   end flows have level 0, but signaling messages for aggregates are
   generated with a higher level.

   The first technique requires aggregating/deaggregating routers to be
   configured with which of their interfaces lie at which aggregation
   level, and also requires consistent message rewriting at these
   boundaries.  The second technique eliminates the rewriting, but
   requires interior routers to be configured also.  It is not clear
   what the right trade-off between these options is.




Loughney                Expires January 19, 2006                [Page 6]


Internet-Draft          NSIS Extensibility Model               July 2005


4.  NSLP Extensibility

4.1  Common Functionality Among Signaling Applications

   While NSIS has adopted a two-layer signaling approach, in practice,
   there is much in common between different NSLPs.  This section covers
   the common values as well as specific NSLP registries.

4.1.1  Common Error Codes

   There is a common Error Code format across all NSLPs.  The Error Code
   contains an Error Type, Error Code, NSLPID and an optional additional
   error field.  This document will list the main Error Types and Error
   Codes.

   Allocation of new Error Types require IETF Action; allocation of new
   Error Codes is 'first come, first serve.'

4.2  NAT FW NSLP Extensibility

   TBA

4.3  QoS NSLP Extensibility

   TBA

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 [6].
   New QSpecs require IETF action, which defines the elements within the
   QSpec.

6.  IANA Considerations

   This document outlines the basic rules for extending NSIS protocols.
   This instructions IANA on allocation policies for NSIS protocols.

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.

8.  Acknowledgements

   This document borrows some ideas and some text from RFC3936 [7],



Loughney                Expires January 19, 2006                [Page 7]


Internet-Draft          NSIS Extensibility Model               July 2005


   Procedures for Modifying the Resource reSerVation Protocol (RSVP).

9.  References

9.1  Normative References

   [2]  Hancock, R., "Next Steps in Signaling: Framework",
        draft-ietf-nsis-fw-07 (work in progress), December 2004.

   [4]  Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
        (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress),
        May 2005.

   [5]  Schulzrinne, H. and R. Hancock, "GIMPS: General Internet
        Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work
        in progress), May 2005.

   [3]  Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality-
        of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in
        progress), February 2005.

   [6]  Ash, J., "QoS-NSLP QSPEC Template", draft-ietf-nsis-qspec-05
        (work in progress), July 2005.

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

9.2  Informative References

   [7]  Kompella, K. and J. Lang, "Procedures for Modifying the Resource
        reSerVation Protocol (RSVP)", BCP 96, RFC 3936, October 2004.


Author's Address

   John Loughney
   Nokia
   Itamerenkatu 11-13
   Helsinki  00180
   Finland

   Phone: +358504836242
   Email: john.loughney@nokia.com








Loughney                Expires January 19, 2006                [Page 8]


Internet-Draft          NSIS Extensibility Model               July 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 January 19, 2006                [Page 9]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/