<pre>Network Working Group                                    M. Brunner, Ed.
Request for Comments: 3726                                           NEC
Category: Informational                                       April 2004


                 <span class="h1">Requirements for Signaling Protocols</span>

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Abstract

   This document defines requirements for signaling across different
   network environments, such as across administrative and/or technology
   domains.  Signaling is mainly considered for Quality of Service (Qos)
   such as the Resource Reservation Protocol (RSVP).  However, in recent
   years, several other applications of signaling have been defined.
   For example, signaling for label distribution in Multiprotocol Label
   Switching (MPLS) or signaling to middleboxes.  To achieve wide
   applicability of the requirements, the starting point is a diverse
   set of scenarios/use cases concerning various types of networks and
   application interactions.  This document presents the assumptions
   before listing the requirements.  The requirements are grouped
   according to areas such as architecture and design goals, signaling
   flows, layering, performance, flexibility, security, and mobility.



















<span class="grey">Brunner                      Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


Table of Contents

   <a href="#section-1">1</a>.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
       <a href="#section-1.1">1.1</a>.  Keywords . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-2">2</a>.  Terminology. . . . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-5">5</a>
   <a href="#section-3">3</a>.  Problem Statement and Scope. . . . . . . . . . . . . . . . . .  <a href="#page-6">6</a>
   <a href="#section-4">4</a>.  Assumptions and Exclusions . . . . . . . . . . . . . . . . . .  <a href="#page-8">8</a>
       <a href="#section-4.1">4.1</a>.  Assumptions and Non-Assumptions. . . . . . . . . . . . .  <a href="#page-8">8</a>
       <a href="#section-4.2">4.2</a>.  Exclusions . . . . . . . . . . . . . . . . . . . . . . .  <a href="#page-9">9</a>
   <a href="#section-5">5</a>.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
       <a href="#section-5.1">5.1</a>.  Architecture and Design Goals. . . . . . . . . . . . . . <a href="#page-11">11</a>
             5.1.1.  NSIS SHOULD Provide Availability Information
                     on Request . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
             <a href="#section-5.1.2">5.1.2</a>.  NSIS MUST be Designed Modularly. . . . . . . . . <a href="#page-11">11</a>
             <a href="#section-5.1.3">5.1.3</a>.  NSIS MUST Decouple Protocol and Information. . . <a href="#page-12">12</a>
             5.1.4.  NSIS MUST Support Independence of Signaling and
                     Network Control Paradigm . . . . . . . . . . . . <a href="#page-12">12</a>
             <a href="#section-5.1.5">5.1.5</a>.  NSIS SHOULD be Able to Carry Opaque Objects. . . <a href="#page-12">12</a>
       <a href="#section-5.2">5.2</a>.  Signaling Flows. . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
             5.2.1.  The Placement of NSIS Initiator, Forwarder, and
                     Responder Anywhere in the Network MUST be
                     Allowed. . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
             5.2.2.  NSIS MUST Support Path-Coupled and MAY Support
                     Path-Decoupled Signaling . . . . . . . . . . . . <a href="#page-13">13</a>
             5.2.3.  Concealment of Topology and Technology
                     Information SHOULD be Possible . . . . . . . . . <a href="#page-13">13</a>
             5.2.4.  Transparent Signaling Through Networks SHOULD be
                     Possible . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
       <a href="#section-5.3">5.3</a>.  Messaging. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
             <a href="#section-5.3.1">5.3.1</a>.  Explicit Erasure of State MUST be Possible . . . <a href="#page-13">13</a>
             5.3.2.  Automatic Release of State After Failure MUST be
                     Possible . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
             5.3.3.  NSIS SHOULD Allow for Sending Notifications
                     Upstream . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
             5.3.4.  Establishment and Refusal to set up State MUST
                     be Notified. . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
             5.3.5.  NSIS MUST Allow for Local Information Exchange . 15
       <a href="#section-5.4">5.4</a>.  Control Information. . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
             5.4.1.  Mutability Information on Parameters SHOULD be
                     Possible . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
             5.4.2.  It SHOULD be Possible to Add and Remove Local
                     Domain Information . . . . . . . . . . . . . . . <a href="#page-16">16</a>
             5.4.3.  State MUST be Addressed Independent of Flow
                     Identification . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
             5.4.4.  Modification of Already Established State SHOULD
                     be Seamless. . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
             5.4.5.  Grouping of Signaling for Several Micro-Flows
                     MAY be Provided. . . . . . . . . . . . . . . . . <a href="#page-17">17</a>



<span class="grey">Brunner                      Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


       <a href="#section-5.5">5.5</a>.  Performance. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
             <a href="#section-5.5.1">5.5.1</a>.  Scalability. . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
             <a href="#section-5.5.2">5.5.2</a>.  NSIS SHOULD Allow for Low Latency in Setup . . . <a href="#page-18">18</a>
             5.5.3.  NSIS MUST Allow for Low Bandwidth Consumption
                     for the Signaling Protocol . . . . . . . . . . . <a href="#page-18">18</a>
             5.5.4.  NSIS SHOULD Allow to Constrain Load on Devices . 18
             5.5.5.  NSIS SHOULD Target the Highest Possible Network
                     Utilization. . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
       <a href="#section-5.6">5.6</a>.  Flexibility. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
             <a href="#section-5.6.1">5.6.1</a>.  Flow Aggregation . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
             5.6.2.  Flexibility in the Placement of the NSIS
                     Initiator/Responder. . . . . . . . . . . . . . . <a href="#page-19">19</a>
             <a href="#section-5.6.3">5.6.3</a>.  Flexibility in the Initiation of State Change. . <a href="#page-19">19</a>
             <a href="#section-5.6.4">5.6.4</a>.  SHOULD Support Network-Initiated State Change. . <a href="#page-19">19</a>
             <a href="#section-5.6.5">5.6.5</a>.  Uni / Bi-directional State Setup . . . . . . . . <a href="#page-20">20</a>
       <a href="#section-5.7">5.7</a>.  Security . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
             <a href="#section-5.7.1">5.7.1</a>.  Authentication of Signaling Requests . . . . . . <a href="#page-20">20</a>
             <a href="#section-5.7.2">5.7.2</a>.  Request Authorization. . . . . . . . . . . . . . <a href="#page-20">20</a>
             <a href="#section-5.7.3">5.7.3</a>.  Integrity Protection . . . . . . . . . . . . . . <a href="#page-20">20</a>
             <a href="#section-5.7.4">5.7.4</a>.  Replay Protection. . . . . . . . . . . . . . . . <a href="#page-21">21</a>
             <a href="#section-5.7.5">5.7.5</a>.  Hop-by-Hop Security. . . . . . . . . . . . . . . <a href="#page-21">21</a>
             5.7.6.  Identity Confidentiality and Network Topology
                     Hiding . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
             <a href="#section-5.7.7">5.7.7</a>.  Denial-of-Service Attacks. . . . . . . . . . . . <a href="#page-21">21</a>
             <a href="#section-5.7.8">5.7.8</a>.  Confidentiality of Signaling Messages. . . . . . <a href="#page-22">22</a>
             <a href="#section-5.7.9">5.7.9</a>.  Ownership of State . . . . . . . . . . . . . . . <a href="#page-22">22</a>
       <a href="#section-5.8">5.8</a>.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
             5.8.1.  Allow Efficient Service Re-Establishment After
                     Handover . . . . . . . . . . . . . . . . . . . . <a href="#page-22">22</a>
       <a href="#section-5.9">5.9</a>.  Interworking with Other Protocols and Techniques . . . . <a href="#page-22">22</a>
             <a href="#section-5.9.1">5.9.1</a>.  MUST Interwork with IP Tunneling . . . . . . . . <a href="#page-22">22</a>
             <a href="#section-5.9.2">5.9.2</a>.  MUST NOT Constrain Either to IPv4 or IPv6. . . . <a href="#page-23">23</a>
             <a href="#section-5.9.3">5.9.3</a>.  MUST be Independent from Charging Model. . . . . <a href="#page-23">23</a>
             <a href="#section-5.9.4">5.9.4</a>.  SHOULD Provide Hooks for AAA Protocols . . . . . <a href="#page-23">23</a>
             <a href="#section-5.9.5">5.9.5</a>.  SHOULD work with Seamless Handoff Protocols. . . <a href="#page-23">23</a>
             <a href="#section-5.9.6">5.9.6</a>.  MUST Work with Traditional Routing . . . . . . . <a href="#page-23">23</a>
       <a href="#section-5.10">5.10</a>. Operational. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
             5.10.1. Ability to Assign Transport Quality to Signaling
                     Messages . . . . . . . . . . . . . . . . . . . . <a href="#page-23">23</a>
             <a href="#section-5.10.2">5.10.2</a>. Graceful Fail Over . . . . . . . . . . . . . . . <a href="#page-24">24</a>
             <a href="#section-5.10.3">5.10.3</a>. Graceful Handling of NSIS Entity Problems. . . . <a href="#page-24">24</a>
   <a href="#section-6">6</a>.  Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
   <a href="#section-7">7</a>.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-24">24</a>
   <a href="#section-8">8</a>.  Appendix: Scenarios/Use Cases. . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
       <a href="#section-8.1">8.1</a>.  Terminal Mobility. . . . . . . . . . . . . . . . . . . . <a href="#page-26">26</a>
       <a href="#section-8.2">8.2</a>.  Wireless Networks. . . . . . . . . . . . . . . . . . . . <a href="#page-28">28</a>
       <a href="#section-8.3">8.3</a>.  An Example Scenario for 3G Wireless Networks . . . . . . <a href="#page-29">29</a>
       <a href="#section-8.4">8.4</a>.  Wired Part of Wireless Network . . . . . . . . . . . . . <a href="#page-31">31</a>



<span class="grey">Brunner                      Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


       <a href="#section-8.5">8.5</a>.  Session Mobility . . . . . . . . . . . . . . . . . . . . <a href="#page-33">33</a>
       8.6.  QoS Reservation/Negotiation from Access to Core Network. 34
       8.7.  QoS Reservation/Negotiation Over Administrative
             Boundaries . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
       8.8.  QoS Signaling Between PSTN Gateways and Backbone Routers 35
       <a href="#section-8.9">8.9</a>.  PSTN Trunking Gateway. . . . . . . . . . . . . . . . . . <a href="#page-36">36</a>
       8.10. An Application Requests End-to-End QoS Path from the
             Network. . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-38">38</a>
       <a href="#section-8.11">8.11</a>. QOS for Virtual Private Networks . . . . . . . . . . . . <a href="#page-39">39</a>
             <a href="#section-8.11.1">8.11.1</a>. Tunnel End Points at the Customer Premises . . . <a href="#page-39">39</a>
             <a href="#section-8.11.2">8.11.2</a>. Tunnel End Points at the Provider Premises . . . <a href="#page-39">39</a>
   <a href="#section-9">9</a>.  References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
       <a href="#section-9.1">9.1</a>.  Normative References . . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
       <a href="#section-9.2">9.2</a>.  Informative References . . . . . . . . . . . . . . . . . <a href="#page-40">40</a>
   <a href="#section-10">10</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-41">41</a>
   <a href="#section-11">11</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-42">42</a>



































<span class="grey">Brunner                      Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document is the product of the Next Steps in Signaling (NSIS)
   Working Group.  It defines requirements for signaling across
   different network environments.  It does not list any problems of
   existing signaling protocols such as [<a href="#ref-RSVP" title="&quot;Resource Protocol (RSVP) -- Version 1 Functional Specification&quot;">RSVP</a>].

   In order to derive requirements for signaling it is necessary to
   first have an idea of the scope within which they are applicable.
   Therefore, we list use cases and scenarios where an NSIS protocol
   could be applied.  The scenarios are used to help derive requirements
   and to test the requirements against use cases.

   The requirements listed are independent of any application.  However,
   resource reservation and QoS related issues are used as examples
   within the text.  However, QoS is not the only field where signaling
   is used in the Internet.  Signaling might also be used as a
   communication protocol to setup and maintain the state in middleboxes
   [<a href="./rfc3234" title="&quot;Middleboxes: Taxonomy and Issues&quot;">RFC3234</a>].

   This document does not cover requirements in relation to some
   networking areas, in particular, interaction with host and site
   multihoming.  We leave these for future analysis.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>.  Keywords</span>

   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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>
   [<a href="#ref-KEYWORDS" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">KEYWORDS</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   We list the most often used terms in the document.  However, they
   cannot be made precise without a more complete architectural model,
   and they are not meant to prescribe any solution in the document.
   Where applicable, they will be defined in protocol documents.

   NSIS Entity (NE): The function within a node, which implements an
   NSIS protocol.  In the case of path-coupled signaling, the NE will
   always be on the data path.

   NSIS Forwarder (NF): NSIS Entity between a NI and NR, which may
   interact with local state management functions in the network.  It
   also propagates NSIS signaling further through the network.

   NSIS Initiator (NI): NSIS Entity that starts NSIS signaling to set up
   or manipulate network state.



<span class="grey">Brunner                      Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   NSIS Responder (NR): NSIS Entity that terminates NSIS signaling and
   can optionally interact with applications as well.

   Flow: A traffic stream (sequence of IP packets between two end
   systems) for which a specific packet level treatment is provided.
   The flow can be unicast (uni- or bi-directional) or multicast.  For
   multicast, a flow can diverge into multiple flows as it propagates
   toward the receiver.  For multi-sender multicast, a flow can also
   diverge when viewed in the reverse direction (toward the senders).

   Data Path: The route across the networks taken by a flow or
   aggregate, i.e., which domains/subdomains it passes through and the
   egress/ingress points for each.

   Signaling Path: The route across the networks taken by a signaling
   flow or aggregate, i.e., which domains/subdomains it passes through
   and the egress/ingress points for each.

   Path-coupled signaling: A mode of signaling where the signaling
   messages follow a path that is tied to the data packets.  Signaling
   messages are routed only through nodes (NEs) that are in the data
   path.

   Path-decoupled signaling: Signaling with independent data and
   signaling paths.  Signaling messages are routed to nodes (NEs) which
   are not assumed to be on the data path, but which are (presumably)
   aware of it.  Signaling messages will always be directly addressed to
   the neighbor NE, and the NI/NR may have no relation at all with the
   ultimate data sender or receiver.

   Service: A generic something provided by one entity and consumed by
   another.  It can be constructed by allocating resources.  The network
   can provide it to users or a network node can provide it to packets.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Problem Statement and Scope</span>

   We provide in the following a preliminary architectural picture as a
   basis for discussion.  We will refer to it in the following
   requirement sections.

   Note that this model is intended not to constrain the technical
   approach taken subsequently, simply to allow concrete phrasing of
   requirements (e.g., requirements about placement of the NSIS
   Initiator.)







<span class="grey">Brunner                      Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   Roughly, the scope of NSIS is assumed to be the interaction between
   the NSIS Initiator, NSIS Forwarder(s), and NSIS Responder including a
   protocol to carry the information, and the syntax/semantics of the
   information that is exchanged.  Further statements on
   assumptions/exclusions are given in the next Section.

   The main elements are:

   1. Something that starts the request for state to be set up in the
      network, the NSIS Initiator.

      This might be in the end system or within some other part of the
      network.  The distinguishing feature of the NSIS Initiator is that
      it acts on triggers coming (directly or indirectly) from the
      higher layers in the end systems.  It needs to map the services
      requested by them, and also provides feedback information to the
      higher layers, which might be used by transport layer algorithms
      or adaptive applications.

   2. Something that assists in managing state further along the
      signaling path, the NSIS Forwarder.

      The NSIS Forwarder does not interact with higher layers, but
      interacts with the NSIS Initiator, NSIS Responder, and possibly
      one or more NSIS Forwarders on the signaling path, edge-to-edge or
      end-to-end.

   3. Something that terminates the signaling path, the NSIS Responder.

      The NSIS responder might be in an end-system or within other
      equipment.  The distinguishing feature of the NSIS Responder is
      that it responds to requests at the end of a signaling path.

   4. The signaling path traverses an underlying network covering one or
      more IP hops.  The underlying network might use locally different
      technology.  For instance, QoS technology has to be provisioned
      appropriately for the service requested.  In the QoS example, an
      NSIS Forwarder maps service-specific information to technology-
      related QoS parameters and receives indications about success or
      failure in response.

   5. We can see the network at the level of domains/subdomains rather
      than individual routers (except in the special case that the
      domain contains one link).  Domains are assumed to be
      administrative entities.  So security requirements might apply
      differently for the signaling between the domains and within a
      domain.  Both cases we deal with in this document.




<span class="grey">Brunner                      Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Assumptions and Exclusions</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Assumptions and Non-Assumptions</span>

   1. The NSIS signaling could run end-to-end, end-to-edge, or edge-to-
      edge, or network-to-network (between providers), depending on what
      point in the network acts as NSIS initiator, and how far towards
      the other end of the network the signaling propagates.  In
      general, we could expect NSIS Forwarders to become more 'dense'
      towards the edges of the network, but this is not a requirement.
      For example, in the case of QoS, an over-provisioned domain might
      contain no NSIS Forwarders at all (and be NSIS transparent); at
      the other extreme, NSIS Forwarders might be placed at every
      router.  In the latter case, QoS provisioning can be carried out
      in a local implementation-dependent way without further signaling,
      whereas in the case of remote NSIS Forwarders, a protocol might be
      needed to control the routers along the path.  This protocol is
      then independent of the end-to-end NSIS signaling.

   2. We do not consider 'pure' end-to-end signaling that is not
      interpreted anywhere within the network.  Such signaling is a
      higher-layer issue and IETF protocols such as SIP etc. can be
      used.

   3. Where the signaling does cover several domains, we do not exclude
      that different signaling protocols are used in each domain.  We
      only place requirements on the universality of the control
      information that is being transported.  (The goals here would be
      to allow the use of signaling protocols, which are matched to the
      characteristics of the portion of the network being traversed.)
      Note that the outcome of NSIS work might result in various flavors
      of the same protocol.

   4. We assume that the service definitions a NSIS Initiator can ask
      for are known in advance of the signaling protocol running.  For
      instance in the QoS example, the service definition includes QoS
      parameters, lifetime of QoS guarantee etc., or any other service-
      specific parameters.

      There are many ways service requesters get to know about available
      services.  There might be standardized services, the definition
      can be negotiated together with a contract, the service definition
      is published in some on-line directory (e.g., at a Web page), and
      so on.

   5. We assume that there are means for the discovery of NSIS entities
      in order to know the signaling peers (solutions include static
      configuration, automatically discovered, or implicitly runs over



<span class="grey">Brunner                      Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


      the right nodes along the data path, etc.).  The discovery of the
      NSIS entities has security implications that need to be addressed
      properly.  For some security mechanisms (i.e., Kerberos, pre-
      shared secret) it is required to know the identity of the other
      entity.  Hence the discovery mechanism may provide means to learn
      this identity, which is then later used to retrieve the required
      keys and parameters.

   6. NSIS assumes layer 3 routing and the determination of next data
      node selection is not done by NSIS.

<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Exclusions</span>

   1.  Development of specific mechanisms and algorithms for application
       and transport layer adaptation are not considered, nor are the
       protocols that would support it.

   2.  Specific mechanisms (APIs and so on) for interaction between
       transport/applications and the network layer are not considered,
       except to clarify the requirements on the negotiation
       capabilities and information semantics that would be needed of
       the signaling protocol.

   3.  Specific mechanisms and protocols for provisioning or other
       network control functions within a domain/subdomain are not
       considered.  The goal is to reuse existing functions and
       protocols unchanged.  However, NSIS itself can be used for
       signaling within a domain/subdomain.

       For instance in the QoS example, it means that the setting of QoS
       mechanisms in a domain is out of scope, but if we have a tunnel,
       NSIS could also be used for tunnel setup with QoS guarantees.  It
       should be possible to exploit these mechanisms optimally within
       the end-to-end context.  Consideration of how to do this might
       generate new requirements for NSIS however.  For example, the
       information needed by a NSIS Forwarder to manage a radio
       subnetwork needs to be provided by the NSIS solution.

   4.  Specific mechanisms (APIs and so on) for interaction between the
       network layer and underlying provisioning mechanisms are not
       considered.

   5.  Interaction with resource management or other internal state
       management capabilities is not considered.  Standard protocols
       might be used for this.  This may imply requirements for the sort
       of information that should be exchanged between the NSIS
       entities.




<span class="grey">Brunner                      Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   6.  Security implications related to multicasting are outside the
       scope of the signaling protocol.

   7.  Service definitions and in particular QoS services and classes
       are out of scope.  Together with the service definition any
       definition of service specific parameters are not considered in
       this document.  Only the base NSIS signaling protocol for
       transporting the service information are addressed.

   8.  Similarly, specific methods, protocols, and ways to express
       service information in the Application/Session level are not
       considered (e.g., SDP, SIP, RTSP, etc.).

   9.  The specification of any extensions needed to signal information
       via application level protocols (e.g., SDP), and the mapping to
       NSIS information are considered outside of the scope of NSIS
       working group, as this work is in the direct scope of other IETF
       working groups (e.g., MMUSIC).

   10. Handoff decision and trigger sources: An NSIS protocol is not
       used to trigger handoffs in mobile IP, nor is it used to decide
       whether to handoff or not.  As soon as or in some situations even
       before a handoff happened, an NSIS protocol might be used for
       signaling for the particular service again.  The basic underlying
       assumption is that the route comes first (defining the path) and
       the signaling comes after it (following the path).  This doesn't
       prevent a signaling application at some node interacting with
       something that modifies the path, but the requirement is then
       just for NSIS to live with that possibility.  However, NSIS must
       interwork with several protocols for mobility management.

   11. Service monitoring is out of scope.  It is heavily dependent on
       the type of the application and or transport service, and in what
       scenario it is used.

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Requirements</span>

   This section defines more detailed requirements for a signaling
   solution, respecting the problem statement, scoping assumptions, and
   terminology considered earlier.  The requirements are in subsections,
   grouped roughly according to general technical aspects: architecture
   and design goals, topology issues, parameters, performance, security,
   information, and flexibility.

   Two general (and potentially contradictory) goals for the solution
   are that it should be applicable in a very wide range of scenarios,
   and at the same time be lightweight in implementation complexity and
   resource consumption requirements in NSIS Entities.  We use the terms



<span class="grey">Brunner                      Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   'access' and 'core' informally in the discussion of some particular
   requirements to refer to deployment conditions where particular
   protocol attributes, especially performance characteristics, have
   special importance.  Specifically, 'access' refers to lower capacity
   networks with fewer users and sessions.  'Core' refers to high
   capacity networks with a large number of users and sessions.

   One approach to this is that the solution could deal with certain
   requirements via modular components or capabilities, which are
   optional to implement or use in individual nodes.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  Architecture and Design Goals</span>

   This section contains requirements related to desirable overall
   characteristics of a solution, e.g., enabling flexibility, or
   independence of parts of the framework.

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  NSIS SHOULD Provide Availability Information on Request</span>

   NSIS SHOULD provide a mechanism to check whether state to be setup is
   available without setting it up.  For the resource reservation
   example this translates into checking resource availability without
   performing resource reservation.  In some scenarios, e.g., the mobile
   terminal scenario, it is required to query, whether resources are
   available, without performing a reservation on the resource.

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  NSIS MUST be Designed Modularly</span>

   A modular design allows for more lightweight implementations, if
   fewer features are needed.  Mutually exclusive solutions are
   supported.  Examples for modularity:

   -  Work over any kind of network (narrowband versus broadband,
      error-prone versus reliable, ...).  This implies low bandwidth
      signaling, and elimination of redundant information MUST be
      supported if necessary.

   -  State setup for uni- and bi-directional flows is possible.

   -  Extensible in the future with different add-ons for certain
      environments or scenarios.

   -  Protocol layering, where appropriate.  This means NSIS MUST
      provide a base protocol, which can be adapted to different
      environments.






<span class="grey">Brunner                      Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  NSIS MUST Decouple Protocol and Information</span>

   The signaling protocol MUST be clearly separated from the control
   information being transported.  This provides for the independent
   development of these two aspects of the solution, and allows for this
   control information to be carried within other protocols, including
   application layer ones, existing ones or those being developed in the
   future.  The flexibility gained in the transport of information
   allows for the applicability of the same protocol in various
   scenarios.

   However, note that the information carried needs to be standardized;
   otherwise interoperability is difficult to achieve.

<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>.  NSIS MUST Support Independence of Signaling and Network Control</span>
<span class="h4">        Paradigm</span>

   The signaling MUST be independent of the paradigm and mechanism of
   network control.  E.g., in the case of signaling for QoS, the
   independence of the signaling protocol from the QoS provisioning
   allows for using the NSIS protocol together with various QoS
   technologies in various scenarios.

<span class="h4"><a class="selflink" id="section-5.1.5" href="#section-5.1.5">5.1.5</a>.  NSIS SHOULD be Able to Carry Opaque Objects</span>

   NSIS SHOULD be able to pass around opaque objects, which are
   interpreted only by some NSIS-capable nodes.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Signaling Flows</span>

   This section contains requirements related to the possible signaling
   flows that should be supported, e.g., over what parts of the flow
   path, between what entities (end-systems, routers, middleboxes,
   management systems), in which direction.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  The placement of NSIS Initiator, Forwarder, and Responder</span>
<span class="h4">        Anywhere in the Network MUST be Allowed</span>

   The protocol MUST work in various scenarios such as host-to-network-
   to-host, edge-to-edge, (e.g., just within one provider's domain),
   user-to-network (from end system into the network, ending, e.g., at
   the entry to the network and vice versa), and network-to-network
   (e.g., between providers).

   Placing the NSIS Forwarder and NSIS Initiator functions at different
   locations allows for various scenarios to work with the same
   protocol.




<span class="grey">Brunner                      Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  NSIS MUST Support Path-Coupled and MAY Support Path-Decoupled</span>
<span class="h4">        Signaling.</span>

   The path-coupled signaling mode MUST be supported.  NSIS signaling
   messages are routed only through nodes (NEs) that are in the data
   path.

   However, there is a set of scenarios, where signaling is not on the
   data path.  Therefore, NSIS MAY support the path-decoupled signaling
   mode, where signaling messages are routed to nodes (NEs), which are
   not assumed to be on the data path, but which are aware of it.

<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>.  Concealment of Topology and Technology Information SHOULD be</span>
<span class="h4">        Possible</span>

   The NSIS protocol SHOULD allow for hiding the internal structure of a
   NSIS domain from end-nodes and from other networks.  Hence an
   adversary should not be able to learn the internal structure of a
   network with the help of the signaling protocol.

   In various scenarios, topology information should be hidden for
   various reasons.  From a business point of view, some administrations
   don't want to reveal the topology and technology used.

<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>.  Transparent Signaling Through Networks SHOULD be Possible</span>

   It SHOULD be possible that the signaling for some flows traverses
   path segments transparently, i.e., without interpretation at NSIS
   Forwarders within the network.  An example would be a subdomain
   within a core network, which only interpreted signaling for
   aggregates established at the domain edge, with the signaling for
   individual flows passing transparently through it.

   In other words, NSIS SHOULD work in hierarchical scenarios, where big
   pipes/trunks are setup using NSIS signaling, but also flows which run
   within that big pipe/trunk are setup using NSIS.

<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Messaging</span>

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Explicit Erasure of State MUST be Possible</span>

   When state along a path is no longer necessary, e.g., because the
   application terminates, or because a mobile host experienced a hand-
   off, it MUST be possible to erase the state explicitly.







<span class="grey">Brunner                      Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  Automatic Release of State After Failure MUST be Possible</span>

   When the NSIS Initiator goes down, the state it requested in the
   network SHOULD be released, since it will most likely no longer be
   necessary.

   After detection of a failure in the network, any NSIS
   Forwarder/Initiator MUST be able to release state it is involved in.
   For example, this may require signaling of the "Release after
   Failure" message upstream as well as downstream, or soft state timing
   out.

   The goal is to prevent stale state within the network and add
   robustness to the operation of NSIS.  So in other words, an NSIS
   signaling protocol or mechanisms MUST provide means for an NSIS
   entity to discover and remove local stale state.

   Note that this might need to work together with a notification
   mechanism.  Note as well, that transient failures in NSIS processing
   shouldn't necessarily have to cause all state to be released
   immediately.

<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  NSIS SHOULD Allow for Sending Notifications Upstream</span>

   NSIS Forwarders SHOULD notify the NSIS Initiator or any other NSIS
   Forwarder upstream, if there is a state change inside the network.
   There are various types of network changes for instance among them:

   Recoverable errors: the network nodes can locally repair this type
   error.  The network nodes do not have to notify the users of the
   error immediately.  This is a condition when the danger of
   degradation (or actual short term degradation) of the provided
   service was overcome by the network (NSIS Forwarder) itself.

   Unrecoverable errors: the network nodes cannot handle this type of
   error, and have to notify the users as soon as possible.

   Service degradation: In case the service cannot be provided
   completely but only partially.

   Repair indication: If an error occurred and it has been fixed, this
   triggers the sending of a notification.

   Service upgrade available: If a previously requested better service
   becomes available.






<span class="grey">Brunner                      Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   The content of the notification is very service specific, but it is
   must at least carry type information.  Additionally, it may carry the
   location of the state change.

   The notifications may or may not be in response to a NSIS message.
   This means an NSIS entity has to be able to handle notifications at
   any time.

   Note however, that there are a number of security consideration needs
   to be solved with notification, even more important if the
   notification is sent without prior request (asynchronously).  The
   problem basically is, that everybody could send notifications to any
   NSIS entity and the NSIS entity most likely reacts on the
   notification.  For example, if it gets an error notification it might
   erase state, even if everything is ok.  So the notification might
   depend on security associations between the sender of the
   notification and its receiver.  If a hop-by-hop security mechanism is
   chosen, this implies also that notifications need to be sent on the
   reverse path.

<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  Establishment and Refusal to Set Up State MUST be Notified</span>

   A NR MUST acknowledge establishment of state on behalf of the NI
   requesting establishment of that state.  A refusal to set up state
   MUST be replied with a negative acknowledgement by the NE refusing to
   set up state.  It MUST be sent to the NI.  Depending on the signaling
   application the (positive or negative) notifications may have to pass
   through further NEs upstream.  Information on the reason of the
   refusal to set up state MAY be made available.  For example, in the
   resource reservation example, together with a negative answer, the
   amount of resources available might also be returned.

<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>.  NSIS MUST Allow for Local Information Exchange</span>

   The signaling protocol MUST be able to exchange local information
   between NSIS Forwarders located within one single administrative
   domain.  The local information exchange is performed by a number of
   separate messages not belonging to an end-to-end signaling process.
   Local information might, for example, be IP addresses, notification
   of successful or erroneous processing of signaling messages, or other
   conditions.

   In some cases, the NSIS signaling protocol MAY carry identification
   of the NSIS Forwarders located at the boundaries of a domain.
   However, the identification of edge should not be visible to the end
   host (NSIS Initiator) and only applies within one administrative
   domain.




<span class="grey">Brunner                      Informational                     [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Control Information</span>

   This section contains requirements related to the control information
   that needs to be exchanged.

<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  Mutability Information on Parameters SHOULD be Possible</span>

   It is possible that nodes modify parameters of a signaling message.
   However, it SHOULD be possible for the NSIS Initiator to control the
   mutability of the signaled information.  For example, the NSIS
   Initiator should be able to control what is requested end-to-end,
   without the request being gradually mutated as it passes through a
   sequence of nodes.

<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  It SHOULD be Possible to Add and Remove Local Domain Information</span>

   It SHOULD be possible to add and remove local scope elements.
   Compared to Requirement 5.3.5 this requirement does use the normal
   signaling process and message exchange for transporting local
   information.  For example, at the entrance to a domain, domain-
   specific information is added information is added, which is used in
   this domain only, and the information is removed again when a
   signaling message leaves the domain.  The motivation is in the
   economy of re-using the protocol for domain internal signaling of
   various information pieces.  Where additional information is needed
   within a particular domain, it should be possible to carry this at
   the same time as the end-to-end information.

<span class="h4"><a class="selflink" id="section-5.4.3" href="#section-5.4.3">5.4.3</a>.  State MUST be Addressed Independent of Flow Identification</span>

   Addressing or identifying state MUST be independent of the flow
   identifier (flow end-points, topological addresses).  Various
   scenarios in the mobility area require this independence because
   flows resulting from handoff might have changed end-points etc. but
   still have the same service requirement.  Also several proxy-based
   signaling methods profit from such independence, though these are not
   chartered work items for NSIS.

<span class="h4"><a class="selflink" id="section-5.4.4" href="#section-5.4.4">5.4.4</a>.  Modification of Already Established State SHOULD be Seamless</span>

   In many case, the established state needs to be updated (in QoS
   example upgrade or downgrade of resource usage).  This SHOULD happen
   seamlessly without service interruption.  At least the signaling
   protocol should allow for it, even if some data path elements might
   not be capable of doing so.






<span class="grey">Brunner                      Informational                     [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.4.5" href="#section-5.4.5">5.4.5</a>.  Grouping of Signaling for Several Micro-Flows MAY be Provided</span>

   NSIS MAY group signaling information for several micro-flows into one
   signaling message.  The goal of this is the optimization in terms of
   setup delay, which can happen in parallel.  This helps applications
   requesting several flows at once.  Also potential refreshes (in case
   of a soft state solution) might profit from grouping.

   However, the network need not know that a relationship between the
   grouped flows exists.  There MUST NOT be any transactional semantic
   associated with the grouping.  It is only meant for optimization
   purposes.

<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  Performance</span>

   This section discusses performance requirements and evaluation
   criteria and the way in which these could and should be traded off
   against each other in various parts of the solution.

   Scalability is always an important requirement for signaling
   protocols.  However, the type of scalability and its importance
   varies from one scenario to another.

   Note that many of the performance issues are heavily dependent on the
   scenario assumed and are normally a trade-off between speed,
   reliability, complexity, and scalability.  The trade-off varies in
   different parts of the network.  For example, in radio access
   networks low bandwidth consumption will outweigh the low latency
   requirement, while in core networks it may be reverse.

<span class="h4"><a class="selflink" id="section-5.5.1" href="#section-5.5.1">5.5.1</a>.  Scalability</span>

   NSIS MUST be scalable in the number of messages received by a
   signaling communication partner (NSIS Initiator, NSIS Forwarder, and
   NSIS Responder).  The major concern lies in the core of the network,
   where large numbers of messages arrive.

   It MUST be scalable in number of hand-offs in mobile environments.
   This mainly applies in access networks, because the core is
   transparent to mobility in most cases.

   It MUST be scalable in the number of interactions for setting up
   state.  This applies for end-systems setting up several states.  Some
   servers might be expected to setup a large number of states.

   Scalability in the amount of state per entity MUST be achieved for
   NSIS Forwarders in the core of the network.




<span class="grey">Brunner                      Informational                     [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   Scalability in CPU usage MUST be achieved on end terminals and
   intermediate nodes in case of many state setup processes at the same
   time.

   Specifically, NSIS MUST work in Internet scale deployments, where the
   use of signaling by hosts becomes universal.  Note that requirement
   5.2.4 requires the functionality of transparently signaling through
   networks without interpretation.  Additionally, requirement 5.6.1
   lists the capability to aggregate.  Furthermore, requirement 5.5.4
   states that NSIS should be able to constrain the load on devices.
   Basically, the performance of the signaling MUST degrade gracefully
   rather than catastrophically under overload conditions.

<span class="h4"><a class="selflink" id="section-5.5.2" href="#section-5.5.2">5.5.2</a>.  NSIS SHOULD Allow for Low Latency in Setup</span>

   NSIS SHOULD allow for low latency setup of states.  This is only
   needed in scenarios where state setups are required on a short time
   scale (e.g., handover in mobile environments), or where human
   interaction is immediately concerned (e.g., voice communication setup
   delay).

<span class="h4"><a class="selflink" id="section-5.5.3" href="#section-5.5.3">5.5.3</a>.  NSIS MUST Allow for Low Bandwidth Consumption for the Signaling</span>
<span class="h4">        Protocol</span>

   NSIS MUST allow for low bandwidth consumption in certain access
   networks.  Again only small sets of scenarios call for low bandwidth,
   mainly those where wireless links are involved.

<span class="h4"><a class="selflink" id="section-5.5.4" href="#section-5.5.4">5.5.4</a>.  NSIS SHOULD Allow to Constrain Load on Devices</span>

   The NSIS architecture SHOULD give the ability to constrain the load
   (CPU load, memory space, signaling bandwidth consumption and
   signaling intensity) on devices where it is needed.  One of the
   reasons is that the protocol handling should have a minimal impact on
   interior (core) nodes.

   This can be achieved by many different methods.  Examples include
   message aggregation, header compression, minimizing functionality, or
   ignoring signaling in core nodes.  NSIS may choose any method as long
   as the requirement is met.

<span class="h4"><a class="selflink" id="section-5.5.5" href="#section-5.5.5">5.5.5</a>.  NSIS SHOULD Target the Highest Possible Network Utilization</span>

   This requirement applies specifically to QoS signaling.







<span class="grey">Brunner                      Informational                     [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   There are networking environments that require high network
   utilization for various reasons, and the signaling protocol SHOULD to
   its best ability support high resource utilization while maintaining
   appropriate service quality.

   In networks where resources are very expensive (as is the case for
   many wireless networks), efficient network utilization for signaling
   traffic is of critical financial importance.  On the other hand there
   are other parts of the network where high utilization is not
   required.

<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>.  Flexibility</span>

   This section lists the various ways the protocol can flexibly be
   employed.

<span class="h4"><a class="selflink" id="section-5.6.1" href="#section-5.6.1">5.6.1</a>.  Flow Aggregation</span>

   NSIS MUST allow for flow aggregation, including the capability to
   select and change the level of aggregation.

<span class="h4"><a class="selflink" id="section-5.6.2" href="#section-5.6.2">5.6.2</a>.  Flexibility in the Placement of the NSIS Initiator/Responder</span>

   NSIS MUST be flexible in placing an NSIS Initiator and NSIS
   Responder.  The NSIS Initiator might be located at the sending or the
   receiving side of a data stream, and the NSIS Responder naturally on
   the other side.

   Also network-initiated signaling and termination MUST be allowed in
   various scenarios such as PSTN gateways, some VPNs, and mobility.
   This means the NSIS Initiator and NSIS Responder might not be at the
   end points of the data stream.

<span class="h4"><a class="selflink" id="section-5.6.3" href="#section-5.6.3">5.6.3</a>.  Flexibility in the Initiation of State Change</span>

   The NSIS Initiator or the NSIS Responder SHOULD be able to initiate a
   change of state.  In the example of resource reservation this is
   often referred to as resource re-negotiation.  It can happen due to
   various reasons, such as local resource shortage (CPU, memory on
   end-system) or a user changed application preference/profiles.

<span class="h4"><a class="selflink" id="section-5.6.4" href="#section-5.6.4">5.6.4</a>.  SHOULD Support Network-Initiated State Change</span>

   NSIS SHOULD support network-initiated state change.  In the QoS
   example, this is used in cases, where the network is not able to
   further guarantee resources and wants to e.g., downgrade a resource
   reservation.




<span class="grey">Brunner                      Informational                     [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.6.5" href="#section-5.6.5">5.6.5</a>.  Uni / Bi-Directional State Setup</span>

   Both unidirectional as well as bi-direction state setup SHOULD be
   possible.  With bi-directional state setup we mean that the state for
   bi-directional data flows is setup.  The bi-directional data flows
   have the same end-points, but the path in the two directions does not
   need to be the same.

   The goal of a bi-directional state setup is mainly an optimization in
   terms of setup delay.  There is no requirements on constrains such as
   use of the same data path etc.

<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>.  Security</span>

   This section discusses security-related requirements.  The NSIS
   protocol MUST provide means for security, but it MUST be allowed that
   nodes implementing NSIS signaling do not have to use the security
   means.

<span class="h4"><a class="selflink" id="section-5.7.1" href="#section-5.7.1">5.7.1</a>.  Authentication of Signaling Requests</span>

   A signaling protocol MUST make provision for enabling various
   entities to be authenticated against each other using strong
   authentication mechanisms.  The term strong authentication points to
   the fact that weak plain-text password mechanisms must not be used
   for authentication.

<span class="h4"><a class="selflink" id="section-5.7.2" href="#section-5.7.2">5.7.2</a>.  Request Authorization</span>

   The signaling protocol MUST provide means to authorize state setup
   requests.  This requirement demands a hook to interact with a policy
   entity to request authorization data.  This allows an authenticated
   entity to be associated with authorization data and to verify the
   request.  Authorization prevents state setup by unauthorized
   entities, setups violating policies, and theft of service.
   Additionally it limits denial of service attacks against parts of the
   network or the entire network caused by unrestricted state setups.
   Additionally it might be helpful to provide some means to inform
   other protocols of participating nodes within the same administrative
   domain about a previous successful authorization event.

<span class="h4"><a class="selflink" id="section-5.7.3" href="#section-5.7.3">5.7.3</a>.  Integrity Protection</span>

   The signaling protocol MUST provide means to protect the message
   payloads against modifications.  Integrity protection prevents an
   adversary from modifying parts of the signaling message and from
   mounting denial of service or theft of service type of attacks
   against network elements participating in the protocol execution.



<span class="grey">Brunner                      Informational                     [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.7.4" href="#section-5.7.4">5.7.4</a>.  Replay Protection</span>

   To prevent replay of previous signaling messages the signaling
   protocol MUST provide means to detect old i.e., already transmitted
   signaling messages.  A solution must cover issues of synchronization
   problems in the case of a restart or a crash of a participating
   network element.

<span class="h4"><a class="selflink" id="section-5.7.5" href="#section-5.7.5">5.7.5</a>.  Hop-by-Hop Security</span>

   Channel security between signaling entities MUST be implemented.  It
   is a well known and proven concept in Quality of Service and other
   signaling protocols to have intermediate nodes that actively
   participate in the protocol to modify the messages as it is required
   by processing rules.  Note that this requirement does not exclude
   end-to-end or network-to-network security of a signaling message.
   End-to-end security between the NSIS Initiator and the NSIS Responder
   may be used to provide protection of non-mutable data fields.
   Network-to-network security refers to the protection of messages over
   various hops but not in an end-to-end manner i.e., protected over a
   particular network.

<span class="h4"><a class="selflink" id="section-5.7.6" href="#section-5.7.6">5.7.6</a>.  Identity Confidentiality and Network Topology Hiding</span>

   Identity confidentiality SHOULD be supported.  It enables privacy and
   avoids profiling of entities by adversary eavesdropping the signaling
   traffic along the path.  The identity used in the process of
   authentication may also be hidden to a limited extent from a network
   to which the initiator is attached.  However the identity MUST
   provide enough information for the nodes in the access network to
   collect accounting data.

   Network topology hiding MAY be supported to prevent entities along
   the path to learn the topology of a network.  Supporting this
   property might conflict with a diagnostic capability.

<span class="h4"><a class="selflink" id="section-5.7.7" href="#section-5.7.7">5.7.7</a>.  Denial-of-Service Attacks</span>

   A signaling protocol SHOULD provide prevention of Denial-of-service
   attacks.  To effectively prevent denial-of-service attacks it is
   necessary that the used security and protocol mechanisms MUST have
   low computational complexity to verify a state setup request prior to
   authenticating the requesting entity.  Additionally the signaling
   protocol and the used security mechanisms SHOULD NOT require large
   resource consumption on NSIS Entities (for example main memory or
   other additional message exchanges) before a successful
   authentication is done.




<span class="grey">Brunner                      Informational                     [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.7.8" href="#section-5.7.8">5.7.8</a>.  Confidentiality of Signaling Messages</span>

   Based on the signaling information exchanged between nodes
   participating in the signaling protocol an adversary may learn both
   the identities and the content of the signaling messages.  Since the
   ability to listen to signaling channels is a major guide to what data
   channels are interesting ones.

   To prevent this from happening, confidentiality of the signaling
   message in a hop-by-hop manner SHOULD be provided.  Note that most
   messages must be protected on a hop-by-hop basis, since entities,
   which actively participate in the signaling protocol, must be able to
   read and eventually modify the signaling messages.

<span class="h4"><a class="selflink" id="section-5.7.9" href="#section-5.7.9">5.7.9</a>.  Ownership of State</span>

   When existing states have to be modified then there is a need to use
   a session identifier to uniquely identify the established state.  A
   signaling protocol MUST provide means of security protection to
   prevent adversaries from modifying state.

<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>.  Mobility</span>

<span class="h4"><a class="selflink" id="section-5.8.1" href="#section-5.8.1">5.8.1</a>.  Allow Efficient Service Re-Establishment After Handover</span>

   Handover is an essential function in wireless networks.  After
   handover, the states may need to be completely or partially re-
   established due to route changes.  The re-establishment may be
   requested by the mobile node itself or triggered by the access point
   that the mobile node is attached to.  In the first case, the
   signaling MUST allow efficient re-establishment after handover.  Re-
   establishment after handover MUST be as quick as possible so that the
   mobile node does not experience service interruption or service
   degradation.  The re-establishment SHOULD be localized, and not
   require end-to-end signaling.

<span class="h3"><a class="selflink" id="section-5.9" href="#section-5.9">5.9</a>.  Interworking with Other Protocols and Techniques</span>

   Hooks SHOULD be provided to enable efficient interworking between
   various protocols and techniques including the following listed.

<span class="h4"><a class="selflink" id="section-5.9.1" href="#section-5.9.1">5.9.1</a>.  MUST Interwork with IP Tunneling</span>

   IP tunneling for various applications MUST be supported.  More
   specifically IPSec tunnels are of importance.  This mainly impacts
   the identification of flows.  When using IPSec, parts of information
   commonly used for flow identification (e.g., transport protocol
   information and ports) may not be accessible due to encryption.



<span class="grey">Brunner                      Informational                     [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h4"><a class="selflink" id="section-5.9.2" href="#section-5.9.2">5.9.2</a>.  MUST NOT Constrain Either to IPv4 or IPv6</span>

<span class="h4"><a class="selflink" id="section-5.9.3" href="#section-5.9.3">5.9.3</a>.  MUST be Independent from Charging Model</span>

   Signaling MUST NOT be constrained by charging models or the charging
   infrastructure used.

<span class="h4"><a class="selflink" id="section-5.9.4" href="#section-5.9.4">5.9.4</a>.  SHOULD Provide Hooks for AAA Protocols</span>

   The NSIS protocol SHOULD be developed with respect to be able to
   collect usage records from one or more network elements.

<span class="h4"><a class="selflink" id="section-5.9.5" href="#section-5.9.5">5.9.5</a>.  SHOULD Work with Seamless Handoff Protocols</span>

   An NSIS protocol SHOULD work with seamless handoff protocols such as
   context transfer and candidate access router (CAR) discovery.

<span class="h4"><a class="selflink" id="section-5.9.6" href="#section-5.9.6">5.9.6</a>.  MUST Work with Traditional Routing</span>

   NSIS assumes traditional L3 routing, which is purely based on L3
   destination addresses.  NSIS MUST work with L3 routing, in particular
   it MUST work in case of route changes.  This means state on the old
   route MUST be released and state on the new route MUST be established
   by an NSIS protocol.

   Networks, which do non-traditional routing, should not break NSIS
   signaling.  NSIS MAY work for some of these situations.
   Particularly, combinations of NSIS unaware nodes and routing other
   then traditional one causes some problems.  Non-traditional routing
   includes, for example, routing decisions based on port numbers, other
   IP header fields than the destination address, or splitting traffic
   based on header hash values.  These routing environments result in
   the signaling path being potentially different than the data path.

<span class="h3"><a class="selflink" id="section-5.10" href="#section-5.10">5.10</a>.  Operational</span>

<span class="h4"><a class="selflink" id="section-5.10.1" href="#section-5.10.1">5.10.1</a>.  Ability to Assign Transport Quality to Signaling Messages</span>

   The NSIS architecture SHOULD allow the network operator to assign the
   NSIS protocol messages a certain transport quality.  As signaling
   opens up the possibility of denial-of-service attacks, this
   requirement gives the network operator a means, but also the
   obligation, to trade-off between signaling latency and the impact
   (from the signaling messages) on devices within the network.  From
   protocol design this requirement states that the protocol messages
   SHOULD be detectable, at least where the control and assignment of
   the messages priority is done.




<span class="grey">Brunner                      Informational                     [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   Furthermore, the protocol design must take into account reliability
   concerns.  Communication reliability is seen as part of the quality
   assigned to signaling messages.  So procedures MUST be defined for
   how an NSIS signaling system behaves if some kind of request it sent
   stays unanswered.  The basic transport protocol to be used between
   adjacent NSIS Entities MAY ensure message integrity and reliable
   transport.

<span class="h4"><a class="selflink" id="section-5.10.2" href="#section-5.10.2">5.10.2</a>.  Graceful Fail Over</span>

   Any unit participating in NSIS signaling MUST NOT cause further
   damage to other systems involved in NSIS signaling when it has to go
   out of service.

<span class="h4"><a class="selflink" id="section-5.10.3" href="#section-5.10.3">5.10.3</a>.  Graceful Handling of NSIS Entity Problems</span>

   NSIS entities SHOULD be able to detect a malfunctioning peer.  It may
   notify the NSIS Initiator or another NSIS entity involved in the
   signaling process.  The NSIS peer may handle the problem itself e.g.,
   switching to a backup NSIS entity.  In the latter case note that
   synchronization of state between the primary and the backup entity is
   needed.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Security Considerations</span>

   <a href="#section-5.7">Section 5.7</a> of this document provides security related requirements
   of a signaling protocol.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Acknowledgments</span>

   Quite a number of people have been involved in the discussion of the
   document, adding some ideas, requirements, etc.  We list them without
   a guarantee on completeness: Changpeng Fan (Siemens), Krishna Paul
   (NEC), Maurizio Molina (NEC), Mirko Schramm (Siemens), Andreas
   Schrader (NEC), Hannes Hartenstein (NEC), Ralf Schmitz (NEC), Juergen
   Quittek (NEC), Morihisa Momona (NEC), Holger Karl (Technical
   University Berlin), Xiaoming Fu (Technical University Berlin), Hans-
   Peter Schwefel (Siemens), Mathias Rautenberg (Siemens), Christoph
   Niedermeier (Siemens), Andreas Kassler (University of Ulm), Ilya
   Freytsis.

   Some text and/or ideas for text, requirements, scenarios have been
   taken from an Internet Draft written by the following authors: David
   Partain (Ericsson), Anders Bergsten (Telia Research), Marc Greis
   (Nokia), Georgios Karagiannis (Ericsson), Jukka Manner (University of
   Helsinki), Ping Pan (Juniper), Vlora Rexhepi (Ericsson), Lars
   Westberg (Ericsson), Haihong Zheng (Nokia).  Some of those have
   actively contributed new text to this document as well.



<span class="grey">Brunner                      Informational                     [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   Another Internet Draft impacting this document has been written by
   Sven Van den Bosch, Maarten Buchli, and Danny Goderis (all Alcatel).
   These people contributed also new text.

   Thanks also to Kwok Ho Chan (Nortel) for text changes.  And finally
   thanks Alison Mankin for the thorough AD review and thanks to Harald
   Tveit Alvestrand and Steve Bellovin for the IESG review comments.












































<span class="grey">Brunner                      Informational                     [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Appendix: Scenarios/Use Cases</span>

   In the following we describe scenarios, which are important to cover,
   and which allow us to discuss various requirements.  Some regard this
   as use cases to be covered defining the use of a signaling protocol.
   In general, these scenarios consider the specific case of signaling
   for QoS (resource reservation), although many of the issues carry
   over directly to other signaling types.

<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>.  Terminal Mobility</span>

   The scenario we are looking at is the case where a mobile terminal
   (MT) changes from one access point to another access point.  The
   access points are located in separate QoS domains.  We assume Mobile
   IP to handle mobility on the network layer in this scenario and
   consider the various extensions (i.e., IETF proposals) to Mobile IP,
   in order to provide 'fast handover' for roaming Mobile Terminals.
   The goal to be achieved lies in providing, keeping, and adapting the
   requested QoS for the ongoing IP sessions in case of handover.
   Furthermore, the negotiation of QoS parameters with the new domain
   via the old connection might be needed, in order to support the
   different 'fast handover' proposals within the IETF.

   The entities involved in this scenario include a mobile terminal,
   access points, an access network manager, and communication partners
   of the MT (the other end(s) of the communication association).  From
   a technical point of view, terminal mobility means changing the
   access point of a mobile terminal (MT).  However, technologies might
   change in various directions (access technology, QoS technology,
   administrative domain).  If the access points are within one specific
   QoS technology (independent of access technology) we call this
   intra-QoS technology handoff.  In the case of an inter-QoS technology
   handoff, one changes from e.g., a DiffServ to an IntServ domain,
   however still using the same access technology.  Finally, if the
   access points are using different access technologies we call it
   inter-technology hand-off.

   The following issues are of special importance in this scenario:

   1) Handoff decision

   -  The QoS management requests handoff.  The QoS management can
      decide to change the access point, since the traffic conditions of
      the new access point are better supporting the QoS requirements.
      The metric may be different (optimized towards a single or a
      group/class of users).  Note that the MT or the network (see
      below) might trigger the handoff.




<span class="grey">Brunner                      Informational                     [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   -  The mobility management forces handoff.  This can have several
      reasons.  The operator optimizes his network, admission is no
      longer granted (e.g., emptied prepaid condition).  Or another
      example is when the MT is reaching the focus of another base
      station.  However, this might be detected via measurements of QoS
      on the physical layer and is therefore out of scope of QoS
      signaling in IP.  Note again that the MT or the network (see
      below) might trigger the handoff.

   -  This scenario shows that local decisions might not be enough.  The
      rest of the path to the other end of the communication needs to be
      considered as well.  Hand-off decisions in a QoS domain do not
      only depend on the local resource availability, e.g., the wireless
      part, but involve the rest of the path as well.  Additionally,
      decomposition of an end-to-end signaling might be needed, in order
      to change only parts of it.

   2) Trigger sources

   -  Mobile terminal: If the end-system QoS management identifies
      another (better-suited) access point, it will request the handoff
      from the terminal itself.  This will be especially likely in the
      case that two different provider networks are involved.  Another
      important example is when the current access point bearer
      disappears (e.g., removing the Ethernet cable).  In this case, the
      NSIS Initiator is basically located on the mobile terminal.

   -  Network (access network manager): Sometimes, the handoff trigger
      will be issued from the network management to optimize the overall
      load situation.  Most likely this will result in changing the
      base-station of a single providers network.  Most likely the NSIS
      Initiator is located on a system within the network.

   3) Integration with other protocols

   -  Interworking with other protocol must be considered in one or the
      other form.  E.g., it might be worth combining QoS signaling
      between different QoS domains with mobility signaling at hand-
      over.

   4) Handover rates

   In mobile networks, the admission control process has to cope with
   far more admission requests than call setups alone would generate.
   For example, in the GSM (Global System for Mobile communications)
   case, mobility usually generates an average of one to two handovers





<span class="grey">Brunner                      Informational                     [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   per call.  For third generation networks (such as UMTS), where it is
   necessary to keep radio links to several cells simultaneously
   (macro-diversity), the handover rate is significantly higher.

   5) Fast state installation

   Handover can also cause packet losses.  This happens when the
   processing of an admission request causes a delayed handover to the
   new base station.  In this situation, some packets might be
   discarded, and the overall speech quality might be degraded
   significantly.  Moreover, a delay in handover may cause degradation
   for other users.  In the worst-case scenario, a delay in handover may
   cause the connection to be dropped if the handover occurred due to
   bad air link quality.  Therefore, it is critical that QoS signaling
   in connection with handover be carried out very quickly.

   6) Call blocking in case of overload

   Furthermore, when the network is overloaded, it is preferable to keep
   states for previously established flows while blocking new requests.
   Therefore, the resource reservation requests in connection with
   handover should be given higher priority than new requests for
   resource reservation.

<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>.  Wireless Networks</span>

   In this scenario, the user is using the packet services of a wireless
   system (such as the 3rd generation wireless system 3GPP/UMTS,
   3GPP2/cdma2000).  The region between the End Host and the Edge Node
   (Edge Router) connecting the wireless network to another QoS domain
   is considered to be a single QoS domain.

   The issues in such an environment regarding QoS include:

   1) The wireless networks provide their own QoS technology with
      specialized parameters to coordinate the QoS provided by both the
      radio access and wired access networks.  Provisioning of QoS
      technologies within a wireless network can be described mainly in
      terms of calling bearer classes, service options, and service
      instances.  These QoS technologies need to be invoked with
      suitable parameters when higher layers trigger a request for QoS.
      Therefore these involve mapping of the requested higher layer QoS
      parameters onto specific bearer classes or service instances.  The
      request for allocation of resources might be triggered by
      signaling at the IP level that passes across the wireless system,
      and possibly other QoS domains.  Typically, wireless network
      specific messages are invoked to setup the underlying bearer




<span class="grey">Brunner                      Informational                     [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


      classes or service instances in parallel with the IP layer QoS
      negotiation, to allocate resources within the radio access
      network.

   2) The IP signaling messages are initiated by the NSIS initiator and
      interpreted by the NSIS Forwarder.  The most efficient placement
      of the NSIS Initiator and NSIS Forwarder has not been determined
      in wireless networks, but a few potential scenarios can be
      envisioned. The NSIS Initiator could be located at the End Host
      (e.g., 3G User equipment (UE)), the Access Gateway or at a node
      that is not directly on the data path, such as a Policy Decision
      Function.  The Access Gateway could act as a proxy NSIS Initiator
      on behalf of the End Host.  The Policy Decision Function that
      controls per-flow/aggregate resources with respect to the session
      within its QoS domain (e.g., the 3G wireless network) may act as a
      proxy NSIS Initiator for the end host or the Access Gateway.
      Depending on the placement of the NSIS Initiator, the NSIS
      Forwarder may be located at an appropriate point in the wireless
      network.

   3) The need for re-negotiation of resources in a new wireless domain
      due to host mobility.  In this case the NSIS Initiator and the
      NSIS Forwarder should detect mobility events and autonomously
      trigger re-negotiation of resources.

<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>.  An Example Scenario for 3G Wireless Networks</span>

   The following example is a pure hypothetical scenario, where an NSIS
   signaling protocol might be used in a 3G environment.  We do not
   impose in any way, how a potential integration might be done.  Terms
   from the 3GPP architecture are used (P-CSCF, IMS, expanded below) in
   order to give specificity, but in a hypothetical design, one that
   reflects neither development nor review by 3GPP.  The example should
   help in the design of a NSIS signaling protocol such that it could be
   used in various environments.

   The 3G wireless access scenario is shown in Figure 1.  The Proxy-Call
   State Control Function (P-CSCF) is the outbound SIP proxy (only used
   in IP Multimedia Subsystems (IMS)).  The Access Gateway is the egress
   router of the 3G wireless domain and it connects the radio access
   network to the Edge Router (ER) of the backbone IP network.  The
   Policy Decision Function (PDF) is an entity responsible for
   controlling bearer level resource allocations/de-allocations in
   relation to session level services e.g., SIP.  The Policy Decision
   Function may also control the Access Gateway to open and close the
   gates and to configure per-flow policies, i.e., to authorize or
   forbid user traffic.  The P-CSCF (only used in IMS) and the Access
   Gateway communicate with the Policy Decision Function, for network



<span class="grey">Brunner                      Informational                     [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   resource allocation/de-allocation decisions.  The User Equipment (UE)
   or the Mobile Station (MS) consists of a Mobile Terminal (MT) and
   Terminal Equipment (TE), e.g., a laptop.

                     +--------+
          +---------&gt;| P-CSCF |---------&gt; SIP signaling
         /           +--------+
        / SIP            |
       |                 |
       |              +-----+            +----------------+
       |              | PDF |&lt;----------&gt;| NSIS Forwarder |&lt;---&gt;
       |              +-----+            +----------------+
       |                 |                  ^
       |                 |                  |
       |                 |                  |
       |                 |COPS              |
       |                 |                  |
   +------+          +---------+            |
   | UE/MS|----------| Access  |&lt;-----------+     +----+
   +------+          | Gateway |------------------| ER |
                     +---------+                  +----+

            Figure 1: 3G wireless access scenario

   The PDF has all the required QoS information for per-flow or
   aggregate admission control in 3G wireless networks.  It receives
   resource allocation/de-allocation requests from the P-CSCF and/or
   Access Gateway etc. and responds with policy decisions.  Hence the
   PDF may be a candidate entity to host the functionality of the NSIS
   Initiator, initiating the NSIS QoS signaling towards the backbone IP
   network.  On the other hand, the UE/MS may act as the NSIS Initiator
   or the Access Gateway may act as a Proxy NSIS Initiator on behalf of
   the UE/MS.  In the former case, the P-CSCF/PDF has to do the mapping
   from codec types and media descriptors (derived from SIP/SDP
   signaling) to IP traffic descriptor.  In the latter case, the UE/MS
   may use any appropriate QoS signaling mechanism as the NSIS
   Initiator.  If the Access Gateway is acting as the Proxy NSIS
   initiator on behalf of the UE/MS, then it may have to do the mapping
   of parameters from radio access specific QoS to IP QoS traffic
   parameters before forwarding the request to the NSIS Forwarder.

   The NSIS Forwarder is currently not part of the standard 3G wireless
   architecture.  However, to achieve end-to-end QoS a NSIS Forwarder is
   needed such that the NSIS Initiators can request a QoS connection to
   the IP network.  As in the previous example, the NSIS Forwarder could
   manage a set of pre-provisioned resources in the IP network, i.e.,
   bandwidth pipes, and the NSIS Forwarder perform per-flow admission
   control into these pipes.  In this way, a connection can be made



<span class="grey">Brunner                      Informational                     [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   between two 3G wireless access networks, and hence, end-to-end QoS
   can be achieved.  In this case the NSIS Initiator and NSIS Forwarder
   are clearly two separate logical entities.  The Access Gateway or/and
   the Edge Router in Fig.1 may contain the NSIS Forwarder
   functionality, depending upon the placement of the NSIS Initiator as
   discussed in scenario 2 in <a href="#section-8.2">section 8.2</a>.  This use case clearly
   illustrates the need for an NSIS QoS signaling protocol between NSIS
   Initiator and NSIS Forwarder.  An important application of such a
   protocol may be its use in the end-to-end establishment of a
   connection with specific QoS characteristics between a mobile host
   and another party (e.g., end host or content server).

<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>.  Wired Part of Wireless Network</span>

   A wireless network, seen from a QoS domain perspective, usually
   consists of three parts: a wireless interface part (the "radio
   interface"), a wired part of the wireless network (i.e., Radio Access
   Network) and the backbone of the wireless network, as shown in Figure
   2.  Note that this figure should not be seen as an architectural
   overview of wireless networks but rather as showing the conceptual
   QoS domains in a wireless network.

   In this scenario, a mobile host can roam and perform a handover
   procedure between base stations/access routers.  In this scenario the
   NSIS QoS protocol can be applied between a base station and the
   gateway (GW).  In this case a GW can also be considered as a local
   handover anchor point.  Furthermore, in this scenario the NSIS QoS
   protocol can also be applied either between two GWs, or between two
   edge routers (ER).






















<span class="grey">Brunner                      Informational                     [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


                          |--|
                          |GW|
   |--|                   |--|
   |MH|---                 .
   |--|  / |-------|       .
        /--|base   | |--|  .
           |station|-|ER|...
           |-------| |--|  . |--| back- |--|  |---|              |----|
                           ..|ER|.......|ER|..|BGW|.."Internet"..|host|
        -- |-------| |--|  . |--| bone  |--|  |---|              |----|
   |--| \  |base   |-|ER|...     .
   |MH|  \ |station| |--|        .
   |--|--- |-------|             .          MH  = mobile host
                              |--|          ER  = edge router
      &lt;----&gt;                  |GW|          GW  = gateway
     Wireless link            |--|          BGW = border gateway
                                            ... = interior nodes
            &lt;-------------------&gt;
       Wired part of wireless network

   &lt;----------------------------------------&gt;
                Wireless Network

      Figure 2. QoS architecture of wired part of wireless network

   Each of these parts of the wireless network impose different issues
   to be solved on the QoS signaling solution being used:

   1) Wireless interface: The solution for the air interface link has to
      ensure flexibility and spectrum efficient transmission of IP
      packets.  However, this link layer QoS can be solved in the same
      way as any other last hop problem by allowing a host to request
      the proper QoS profile.

   2) Wired part of the wireless network:  This is the part of the
      network that is closest to the base stations/access routers.  It
      is an IP network although some parts logically perform tunneling
      of the end user data.  In cellular networks, the wired part of the
      wireless network is denoted as a radio access network.

      This part of the wireless network has different requirements for
      signaling protocol characteristics when compared to traditional IP
      networks:

      -  The network must support mobility.  Many wireless networks are
         able to provide a combination of soft and hard handover
         procedures.  When handover occurs, reservations need to be
         established on new paths.  The establishment time has to be as



<span class="grey">Brunner                      Informational                     [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


         short as possible since long establishment times for s degrade
         the performance of the wireless network.  Moreover, for maximal
         utilization of the radio spectrum, frequent handover operations
         are required.

      -  These links are typically rather bandwidth-limited.

      -  The wired transmission in such a network contains a relatively
         high volume of expensive leased lines.  Overprovisioning might
         therefore be prohibitively expensive.

      -  The radio base stations are spread over a wide geographical
         area and are in general situated a large distance from the
         backbone.

   3) Backbone of the wireless network: the requirements imposed by this
      network are similar to the requirements imposed by other types of
      backbone networks.

   Due to these very different characteristics and requirements, often
   contradictory, different QoS signaling solutions might be needed in
   each of the three network parts.

<span class="h3"><a class="selflink" id="section-8.5" href="#section-8.5">8.5</a>.  Session Mobility</span>

   In this scenario, a session is moved from one end-system to another.
   Ongoing sessions are kept and QoS parameters need to be adapted,
   since it is very likely that the new device provides different
   capabilities.  Note that it is open which entity initiates the move,
   which implies that the NSIS Initiator might be triggered by different
   entities.

   User mobility (i.e., a user changing the device and therefore moving
   the sessions to the new device) is considered to be a special case
   within the session mobility scenario.

   Note that this scenario is different from terminal mobility.  The
   terminal (end-system) has not moved to a different access point.
   Both terminals are still connected to an IP network at their original
   points.

   The issues include:

   1) Keeping the QoS guarantees negotiated implies that the end-
      point(s) of communication are changed without changing the s.

   2) The trigger of the session move might be the user or any other
      party involved in the session.



<span class="grey">Brunner                      Informational                     [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h3"><a class="selflink" id="section-8.6" href="#section-8.6">8.6</a>.  QoS Reservation/Negotiation from Access to Core Network</span>

   The scenario includes the signaling between access networks and core
   networks in order to setup and change reservations together with
   potential negotiation.

   The issues to be solved in this scenario are different from previous
   ones.

   1) The entity of reservation is most likely an aggregate.

   2) The time scales of states might be different (long living states
      of aggregates, less often re-negotiation).

   3) The specification of the traffic (amount of traffic), a particular
      QoS is guaranteed for, needs to be changed.  E.g., in case
      additional flows are added to the aggregate, the traffic
      specification of the flow needs to be added if it is not already
      included in the aggregates specification.

   4) The flow specification is more complex including network addresses
      and sets of different address for the source as well as for the
      destination of the flow.

<span class="h3"><a class="selflink" id="section-8.7" href="#section-8.7">8.7</a>.  QoS Reservation/Negotiation Over Administrative Boundaries</span>

   Signaling between two or more core networks to provide QoS is handled
   in this scenario.  This might also include access to core signaling
   over administrative boundaries.  Compared to the previous one it adds
   the case, where the two networks are not in the same administrative
   domain.  Basically, it is the inter-domain/inter-provider signaling
   which is handled in here.

   The domain boundary is the critical issue to be resolved.  Which of
   various flavors of issues a QoS signaling protocol has to be
   concerned with.

   1) Competing administrations: Normally, only basic information should
      be exchanged, if the signaling is between competing
      administrations.  Specifically information about core network
      internals (e.g., topology, technology, etc.) should not be
      exchanged.  Some information exchange about the "access points" of
      the core networks (which is topology information as well) may be
      required, to be exchanged, because it is needed for proper
      signaling.

   2) Additionally, as in scenario 4, signaling most likely is based on
      aggregates, with all the issues raise there.



<span class="grey">Brunner                      Informational                     [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   3) Authorization: It is critical that the NSIS Initiator is
      authorized to perform a QoS path setup.

   4) Accountability: It is important to notice that signaling might be
      used as an entity to charge money for, therefore the
      interoperation with accounting needs to be available.

<span class="h3"><a class="selflink" id="section-8.8" href="#section-8.8">8.8</a>.  QoS Signaling Between PSTN Gateways and Backbone Routers</span>

   A PSTN gateway (i.e., host) requires information from the network
   regarding its ability to transport voice traffic across the network.
   The voice quality will suffer due to packet loss, latency and jitter.
   Signaling is used to identify and admit a flow for which these
   impairments are minimized.  In addition, the disposition of the
   signaling request is used to allow the PSTN GW to make a call routing
   decision before the call is actually accepted and delivered to the
   final destination.

   PSTN gateways may handle thousands of calls simultaneously and there
   may be hundreds of PSTN gateways in a single provider network.  These
   numbers are likely to increase as the size of the network increases.
   The point being that scalability is a major issue.

   There are several ways that a PSTN gateway can acquire assurances
   that a network can carry its traffic across the network.  These
   include:

   1. Over-provisioning a high availability network.

   2. Handling admission control through some policy server that has a
      global view of the network and its resources.

   3. Per PSTN GW pair admission control.

   4. Per call admission control (where a call is defined as the 5-tuple
      used to carry a single RTP flow).

   Item 1 requires no signaling at all and is therefore outside the
   scope of this working group.

   Item 2 is really a better informed version of 1, but it is also
   outside the scope of this working group as it relies on a particular
   telephony signaling protocol rather than a packet admission control
   protocol.

   Item 3 is initially attractive, as it appears to have reasonable
   scaling properties, however, its scaling properties only are
   effective in cases where there are relatively few PSTN GWs.  In the



<span class="grey">Brunner                      Informational                     [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   more general case where a PSTN GW reduces to a single IP phone
   sitting behind some access network, the opportunities for aggregation
   are reduced and the problem reduces to item 4.

   Item 4 is the most general case.  However, it has the most difficult
   scaling problems.  The objective here is to place the requirements on
   Item 4 such that a scalable per-flow admission control protocol or
   protocol suite may be developed.

   The case where per-flow signaling extends to individual IP end-points
   allows the inclusion of IP phones on cable, DSL, wireless or other
   access networks in this scenario.

   Call Scenario

   A PSTN GW signals end-to-end for some 5-tuple defined flow a
   bandwidth and QoS requirement.  Note that the 5-tuple might include
   masking/wildcarding.  The access network admits this flow according
   to its local policy and the specific details of the access
   technology.

   At the edge router (i.e., border node), the flow is admitted, again
   with an optional authentication process, possibly involving an
   external policy server.  Note that the relationship between the PSTN
   GW and the policy server and the routers and the policy server is
   outside the scope of NSIS.  The edge router then admits the flow into
   the core of the network, possibly using some aggregation technique.

   At the interior nodes, the NSIS host-to-host signaling should either
   be ignored or invisible as the Edge router performed the admission
   control decision to some aggregate.

   At the inter-provider router (i.e., border node), again the NSIS
   host-to-host signaling should either be ignored or invisible, as the
   Edge router has performed an admission control decision about an
   aggregate across a carrier network.

<span class="h3"><a class="selflink" id="section-8.9" href="#section-8.9">8.9</a>.  PSTN Trunking Gateway</span>

   One of the use cases for the NSIS signaling protocol is the scenario
   of interconnecting PSTN gateways with an IP network that supports
   QoS.









<span class="grey">Brunner                      Informational                     [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   Four different scenarios are considered here.

   1. In-band QoS signaling is used.  In this case the Media Gateway
      (MG) will be acting as the NSIS Initiator and the Edge Router (ER)
      will be the NSIS Forwarder.  Hence, the ER should do admission
      control (into pre-provisioned traffic trunks) for the individual
      traffic flows.  This scenario is not further considered here.

   2. Out-of-band signaling in a single domain, the NSIS forwarder is
      integrated in the Media Gateway Controller (MGC).  In this case no
      NSIS protocol is required.

   3. Out-of-band signaling in a single domain, the NSIS forwarder is a
      separate box.  In this case NSIS signaling is used between the MGC
      and the NSIS Forwarder.

   4. Out-of-band signaling between multiple domains, the NSIS Forwarder
      (which may be integrated in the MGC) triggers the NSIS Forwarder
      of the next domain.

   When the out-of-band QoS signaling is used the Media Gateway
   Controller (MGC) will be acting as the NSIS Initiator.

   In the second scenario the voice provider manages a set of traffic
   trunks that are leased from a network provider.  The MGC does the
   admission control in this case.  Since the NSIS Forwarder acts both
   as a NSIS Initiator and a NSIS Forwarder, no NSIS signaling is
   required.  This scenario is shown in Figure 3.

    +-------------+    ISUP/SIGTRAN     +-----+              +-----+
    | SS7 network |---------------------| MGC |--------------| SS7 |
    +-------------+             +-------+-----+---------+    +-----+
          :                    /           :             \
          :                   /            :              \
          :                  /    +--------:----------+    \
          :          MEGACO /    /         :           \    \
          :                /    /       +-----+         \    \
          :               /    /        | NMS |          \    \
          :              /     |        +-----+          |     \
          :              :     |                         |     :
   +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
   | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
   +--------------+  +----+     \                       /   +----+
                                 \     QoS network     /
                                  +-------------------+

                Figure 3: PSTN trunking gateway scenario




<span class="grey">Brunner                      Informational                     [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   In the third scenario, the voice provider does not lease traffic
   trunks in the network.  Another entity may lease traffic trunks and
   may use a NSIS Forwarder to do per-flow admission control.  In this
   case the NSIS signaling is used between the MGC and the NSIS
   Forwarder, which is a separate box here.  Hence, the MGC acts only as
   a NSIS Initiator.  This scenario is depicted in Figure 4.

    +-------------+    ISUP/SIGTRAN     +-----+              +-----+
    | SS7 network |---------------------| MGC |--------------| SS7 |
    +-------------+             +-------+-----+---------+    +-----+
          :                    /           :             \
          :                   /         +-----+           \
          :                  /          | NF  |            \
          :                 /           +-----+             \
          :                /               :                 \
          :               /       +--------:----------+       \
          :       MEGACO :       /         :           \       :
          :              :      /       +-----+         \      :
          :              :     /        | NMS |          \     :
          :              :     |        +-----+          |     :
          :              :     |                         |     :
   +--------------+  +----+    |   bandwidth pipe (SLS)  |  +----+
   | PSTN network |--| MG |--|ER|======================|ER|-| MG |--
   +--------------+  +----+     \                       /   +----+
                                 \     QoS network     /
                                  +-------------------+

               Figure 4: PSTN trunking gateway scenario

   In the fourth scenario multiple transport domains are involved.  In
   the originating network either the MGC may have an overview on the
   resources of the overlay network or a separate NSIS Forwarder will
   have the overview.  Hence, depending on this either the MGC or the
   NSIS Forwarder of the originating domain will contact the NSIS
   Forwarder of the next domain.  The MGC always acts as a NSIS
   Initiator and may also be acting as a NSIS Forwarder in the first
   domain.

<span class="h3"><a class="selflink" id="section-8.10" href="#section-8.10">8.10</a>.  An Application Requests End-to-End QoS Path from the Network</span>

   This is actually the conceptually simplest case.  A multimedia
   application requests a guaranteed service from an IP network.  We
   assume here that the application is somehow able to specify the
   network service.  The characteristics here are that many hosts might
   do it, but that the requested service is low capacity (bounded by the
   access line).  Note that there is an issue of scaling in the number
   of applications requesting this service in the core of the network.




<span class="grey">Brunner                      Informational                     [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h3"><a class="selflink" id="section-8.11" href="#section-8.11">8.11</a>.  QOS for Virtual Private Networks</span>

   In a Virtual Private Network (VPN), a variety of tunnels might be
   used between its edges.  These tunnels could be for example, IPSec,
   GRE, and IP-IP.  One of the most significant issues in VPNs is
   related to how a flow is identified and what quality a flow gets.  A
   flow identification might consist among others of the transport
   protocol port numbers.  In an IP-Sec tunnel this will be problematic
   since the transport protocol information is encrypted.

   There are two types of L3 VPNs, distinguished by where the endpoints
   of the tunnels exist.  The endpoints of the tunnels may either be on
   the customer (CPE) or the provider equipment or provider edge (PE).

   Virtual Private networks are also likely to request bandwidth or
   other type of service in addition to the premium services the PSTN GW
   are likely to use.

<span class="h4"><a class="selflink" id="section-8.11.1" href="#section-8.11.1">8.11.1</a>.  Tunnel End Points at the Customer Premises</span>

   When the endpoints are the CPE, the CPE may want to signal across the
   public IP network for a particular amount of bandwidth and QoS for
   the tunnel aggregate.  Such signaling may be useful when a customer
   wants to vary their network cost with demand, rather than paying a
   flat rate.  Such signaling exists between the two CPE routers.
   Intermediate access and edge routers perform the same exact call
   admission control, authentication and aggregation functions performed
   by the corresponding routers in the PSTN GW scenario with the
   exception that the endpoints are the CPE tunnel endpoints rather than
   PSTN GWs and the 5-tuple used to describe the RTP flow is replaced
   with the corresponding flow spec to uniquely identify the tunnels.
   Tunnels may be of any variety (e.g., IP-Sec, GRE, IP-IP).

   In such a scenario, NSIS would actually allow partly for customer
   managed VPNs, which means a customer can setup VPNs by subsequent
   NSIS signaling to various end-point.  Plus the tunnel end-points are
   not necessarily bound to an application.  The customer administrator
   might be the one triggering NSIS signaling.

<span class="h4"><a class="selflink" id="section-8.11.2" href="#section-8.11.2">8.11.2</a>.  Tunnel End Points at the Provider Premises</span>

   In the case were the tunnel end-points exist on the provider edge,
   requests for bandwidth may be signaled either per flow, where a flow
   is defined from a customers address space, or between customer sites.

   In the case of per flow signaling, the PE router must map the
   bandwidth request to the tunnel carrying traffic to the destination
   specified in the flow spec.  Such a tunnel is a member of an



<span class="grey">Brunner                      Informational                     [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


   aggregate to which the flow must be admitted.  In this case, the
   operation of admission control is very similar to the case of the
   PSTN GW with the additional level of indirection imposed by the VPN
   tunnel.  Therefore, authentication, accounting and policing may be
   required on the PE router.

   In the case of per site signaling, a site would need to be
   identified.  This may be accomplished by specifying the network
   serviced at that site through an IP prefix.  In this case, the
   admission control function is performed on the aggregate to the PE
   router connected to the site in question.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  References</span>

<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>.  Normative References</span>

   [<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>.  Informative References</span>

   [<a id="ref-RSVP">RSVP</a>]     Braden, R., Ed., Zhang, L., Berson, S., Herzog, S. and S.
              Jamin, "Resource Protocol (RSVP) -- Version 1 Functional
              Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.

   [<a id="ref-RFC3234">RFC3234</a>]  Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and
              Issues", <a href="./rfc3234">RFC 3234</a>, February 2002.
























<span class="grey">Brunner                      Informational                     [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Authors' Addresses</span>

   Marcus Brunner (Editor)
   NEC Europe Ltd.
   Network Laboratories
   Kurfuersten-Anlage 36
   D-69115 Heidelberg
   Germany

   EMail: brunner@netlab.nec.de


   Robert Hancock
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   EMail: robert.hancock@roke.co.uk


   Eleanor Hepworth
   Roke Manor Research Ltd
   Romsey, Hants, SO51 0ZN
   United Kingdom

   EMail: eleanor.hepworth@roke.co.uk


   Cornelia Kappler
   Siemens AG
   Berlin 13623
   Germany

   EMail: cornelia.kappler@siemens.com


   Hannes Tschofenig
   Siemens AG
   Otto-Hahn-Ring 6
   81739 Munchen
   Germany

   EMail: Hannes.Tschofenig@mchp.siemens.de








<span class="grey">Brunner                      Informational                     [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc3726">RFC 3726</a>          Requirements for Signaling Protocols        April 2004</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Full Copyright Statement</span>

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and
   except as set forth therein, the authors retain all their rights.

   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.

Intellectual Property

   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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.









Brunner                      Informational                     [Page 42]
</pre>