One document matched: draft-nsis-ext-00.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<!-- You want a table of contents -->
<!-- ?rfc symrefs="yes" ?-->
<!-- Uncomment this if you want symbolic labels for references -->
<?rfc sortrefs="yes"?>
<!-- This sorts the references -->
<?rfc iprnotified="no" ?>
<!-- Change to "yes" if someone has disclosed IPR for the draft -->
<?rfc compact="yes"?>
<rfc category="std" docName="draft-loughney-nsis-ext-03.txt" ipr="full3978">
  <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

  <?rfc toc="yes" ?>

  <?rfc symrefs="yes" ?>

  <?rfc sortrefs="yes"?>

  <?rfc iprnotified="no" ?>

  <?rfc strict="yes" ?>

  <front>
    <title>NSIS Extensibility Model</title>

    <author fullname="John Loughney" initials="J" surname="Loughney">
      <organization>Nokia</organization>

      <address>
        <postal>
          <street>955 Page Mill Road</street>

          <city>Palo Alto</city>

          <code>94303</code>

          <country>USA</country>
        </postal>

        <phone>+1 650 283 8068</phone>

        <email>john.loughney@nokia.com</email>
      </address>
    </author>

    <date year="2007" />

    <workgroup>Internet Engineering Task Force</workgroup>

    <abstract>
      <t>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. This document will
      serve as guidence on how the NSIS architecture can be extended.</t>
    </abstract>
  </front>

  <middle>
    <section title="Requirements notation">
      <t>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 <xref
      target="RFC2119"></xref>.</t>
    </section>

    <section title="Introduction">
      <t>The Next Steps in Signaling Framework <xref
      target="I-D.ietf-nsis-fw"> NSIS Framework</xref> 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.</t>

      <t>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 - <xref
      target="I-D.ietf-nsis-qos-nslp"> QoS signaling</xref> and <xref
      target="I-D.ietf-nsis-nslp-natfw"> NAT/Firewall signaling</xref>. It is expected
      that there will be more signaling applications.</t>

      <t>The NSIS Transport Layer Protocol, GIST (General Internet Signaling Transport) <xref
      target="I-D.ietf-nsis-ntlp"> GIST</xref> 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.</t>

      <t>Above GIST can one or more NSIS Signaling Layer protocols, which
      can signal for things such as QoS, firewall control and NAT
      signaling.<xref target="I-D.ietf-nsis-qos-nslp"> QoS NSLP </xref>, <xref
      target="I-D.ietf-nsis-nslp-natfw">NAT/FW NSLP</xref>. These signaling
      applications manage their state by using the services that the GIST
      provides them for signaling.</t>

      <t>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, not all path elements support NSIS signaling will require
      that a specific signaling application is present - only those nodes
      that will be maintaining some signaling application state need to 
      support the signaling application.</t>

      <section title="NSIS Extensibility Types">
        <t>Generally, NSIS protocols can be extended in multiple ways.  This secition is
        and overview of the mechansims used. The extensibility rules 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.</t>

        <t>Extensions subject to "IETF Action" require either a Standards Track
        RFC, Experimental RFC or an Information RFC.</t>

        <t>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.</t>

        <t>"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.</t>

        <t>In the NSIS protocols, experimental code points are allocated for 
        experimentation, usually within closed networks, as explained in RFC 
        3692.<xref target="RFC3692"/>.  If these experiments
        yield useful results, it is assumed that they will be formally allocated
        by one of the above mechanisms.</t>
      </section>
    </section>

    <section title="GIST Extensibility">
      <t>GIST is Major extensibility options for GIST are:</t>

      <section title="NSLP Identifiers">
        <t>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.</t>
      </section>

      <section title="Message Routing Methods">
        <t>GIST allows the idea of multiple Message Routing Methods (MRM). The
        message routing method is indicated in the leading 2 bytes of the MRI
        object. GIST allocates 2 bits for experimental Routing Methods, for
        use in closed networks for experimentation purposes. Standards Action
        is required to allocate new Routing Methods.</t>
        <t>Experimental NSLPs are required to be able to use experimental MRMs, and 
        the experimental NSLP is not supported, then the MRM is ignored.  The expectation
	  is that the experimental MRM is used within a closed network, for experimental
	  purposes, as explained in RFC 3692.<xref target="RFC3692"/> </t>
      </section>

      <section title="Protocol Indicators">
        <t>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.</t>
      </section>

      <section title="Router Alert Values">
        <t>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</t>

        <t>The use of the RAO is the primary
        mechanism to indicate that an GIST message should be intercepted by a
        particular node. There are two basic reasons why a GIST 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.</t>

        <t>Some of this information can be encoded in the RAO value field,
        which 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:</t>

        <t>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.</t>

        <t>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 GIST common header to identify the precise messages it needs to
        consider.</t>

        <t>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.  Which is to say that the RAO does not 
        have to have a one-to-one relation to a specific NSLPID, the RAO must 
        be uniquely derivable from the NSLPID.</t>

        <t>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:</t>

        <t>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.</t>

        <t>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.</t>

        <t>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.</t>
      </section>
    </section>

    <section title="NSLP Extensibility">
        <t>An NSLP roughly should correspond to a class of signaling application,
        which requires some state maintenance along a network path.  Signaling
        applications should be generic enough to allow for state manipulation
        for a common set of funtions.  This allows for an architecture which allows
        for flexible network deployment, without over-burdening nodes with extra
        signaling applications.</t>

        <t>New NSLPs should be created when there is a new signaling application.
        Creating new NSLPs which only slightly modify existing NSLPs is not 
        recommended as it will increase deployment complexity (common nodes 
        would need to support multiple NSLPs for similar functionality).</t>

      <section title="Common Functionality Among Signaling Applications">
        <t>While NSIS has adopted a two-layer signaling approach, in practice,
        there is much in common between different NSLPs. Efforts should be made
        to ensure some high-level of compatibililty among signaling applications,
        which could be reused by some implementations in order to combine multiple
        signaling applications into one implementation, but that is an implementation
        decision.</t>
      </section>

    </section>

    <section title="QoS Model Extensibility">
      <t>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 <xref
      target="I-D.ietf-nsis-qspec">QSpec</xref>. New QoS Models require IETF
      action, which defines the elements within the QSpec. See <xref
      target="I-D.ietf-nsis-qspec">QSpec</xref> for details.</t>

      <t>A key part of the QoS model is support a common language, which can be 
      shared among several QOSMs.  These QSPEC parameters ensure a certain level of
      interoperability of QOSMs.  Optional QSPEC parameters support the extensibility 
      of the QoS NSLP to other QOSMs in the future. The node initiating the NSIS signaling 
      adds an Initiator QSPEC that must not be removed, thereby ensuring the intention of 
      the NSIS initiator is preserved along the signaling path.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document outlines the basic rules for extending NSIS protocols.
      This instructions IANA on allocation policies for NSIS protocols.</t>
    </section>

    <section title="Security Considerations">
      <t>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.</t>
    </section>

    <section title="Acknowledgements">
      <t>This document borrows some ideas and some text from <xref
      target="RFC3936">RFC3936</xref>, Procedures for Modifying the Resource
      reSerVation Protocol (RSVP).</t>

      <t>Robert Hancock provided text for much of the GIST section. Claudia Keppler have 
      provided feedback on this draft.</t>

      <t>Allison Mankin and Bob Braden suggest that this draft be worked on.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119" ?>

      <?rfc include="reference.I-D.ietf-nsis-ntlp" ?>

      <?rfc include="reference.I-D.ietf-nsis-fw" ?>

      <?rfc include="reference.I-D.ietf-nsis-nslp-natfw" ?>

      <?rfc include="reference.I-D.ietf-nsis-qos-nslp" ?>

      <?rfc include="reference.I-D.ietf-nsis-qspec" ?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3936" ?>

      <?rfc include="reference.RFC.3692" ?>

    </references>
  </back>
</rfc>