doc: Add RFC documents

1 files changed, 2747 insertions, 0 deletions

diff --git a/doc/rfc/rfc4080.txt b/doc/rfc/rfc4080.txt
new file mode 100644
index 0000000..6d455ba
--- /dev/null
+++ b/doc/rfc/rfc4080.txt
@@ -0,0 +1,2747 @@
+
+
+
+
+
+
+Network Working Group                                         R. Hancock
+Request for Comments: 4080                                   Siemens/RMR
+Category: Informational                                   G. Karagiannis
+                                           University of Twente/Ericsson
+                                                             J. Loughney
+                                                                   Nokia
+                                                        S. Van den Bosch
+                                                                 Alcatel
+                                                               June 2005
+
+
+               Next Steps in Signaling (NSIS): Framework
+
+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 (2005).
+
+Abstract
+
+   The Next Steps in Signaling (NSIS) working group is considering
+   protocols for signaling information about a data flow along its path
+   in the network.  The NSIS suite of protocols is envisioned to support
+   various signaling applications that need to install and/or manipulate
+   such state in the network.  Based on existing work on signaling
+   requirements, this document proposes an architectural framework for
+   these signaling protocols.
+
+   This document provides a model for the network entities that take
+   part in such signaling, and for the relationship between signaling
+   and the rest of network operation.  We decompose the overall
+   signaling protocol suite into a generic (lower) layer, with separate
+   upper layers for each specific signaling application.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Definition of the Signaling Problem ........................3
+      1.2. Scope and Structure of the NSIS Framework ..................3
+   2. Terminology .....................................................4
+   3. Overview of Signaling Scenarios and Protocol Structure ..........6
+      3.1. Fundamental Signaling Concepts .............................6
+           3.1.1. Simple Network and Signaling Topology ...............6
+
+
+
+Hancock, et al.              Informational                      [Page 1]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+           3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
+           3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
+           3.1.4. Signaling Messages and Network Control State .......10
+           3.1.5. Data Flows and Sessions ............................10
+      3.2. Layer Model for the Protocol Suite ........................11
+           3.2.1. Layer Model Overview ...............................11
+           3.2.2. Layer Split Concept ................................12
+           3.2.3. Bypassing Intermediate Nodes .......................13
+           3.2.4. Core NSIS Transport Layer Functionality ............15
+           3.2.5. State Management Functionality .....................16
+           3.2.6. Path-Decoupled Operation ...........................17
+      3.3. Signaling Application Properties ..........................18
+           3.3.1. Sender/Receiver Orientation ........................18
+           3.3.2. Uni- and Bi-Directional Operation ..................19
+           3.3.3. Heterogeneous Operation ............................19
+           3.3.4. Aggregation ........................................20
+           3.3.5. Peer-Peer and End-End Relationships ................21
+           3.3.6. Acknowledgements and Notifications .................21
+           3.3.7. Security and Other AAA Issues ......................22
+   4. The NSIS Transport Layer Protocol ..............................23
+      4.1. Internal Protocol Components ..............................23
+      4.2. Addressing ................................................24
+      4.3. Classical Transport Functions .............................24
+      4.4. Lower Layer Interfaces ....................................26
+      4.5. Upper Layer Services ......................................27
+      4.6. Identity Elements .........................................28
+           4.6.1. Flow Identification ................................28
+           4.6.2. Session Identification .............................28
+           4.6.3. Signaling Application Identification ...............29
+      4.7. Security Properties .......................................30
+   5. Interactions with Other Protocols ..............................30
+      5.1. IP Routing Interactions ...................................30
+           5.1.1. Load Sharing and Policy-Based Forwarding ...........31
+           5.1.2. Route Changes ......................................31
+      5.2. Mobility and Multihoming Interactions .....................33
+      5.3. Interactions with NATs ....................................36
+      5.4. Interactions with IP Tunneling ............................36
+   6. Signaling Applications .........................................37
+      6.1. Signaling for Quality of Service ..........................37
+           6.1.1. Protocol Message Semantics .........................38
+           6.1.2. State Management ...................................39
+           6.1.3. Route Changes and QoS Reservations .................39
+           6.1.4. Resource Management Interactions ...................41
+      6.2. Other Signaling Applications ..............................42
+   7. Security Considerations ........................................42
+   8. References .....................................................43
+      8.1. Normative References ......................................43
+      8.2. Informative References ....................................44
+
+
+
+Hancock, et al.              Informational                      [Page 2]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+1.  Introduction
+
+1.1.  Definition of the Signaling Problem
+
+   The Next Steps in Signaling (NSIS) working group is considering
+   protocols for signaling information about a data flow along its path
+   in the network.
+
+   It is assumed that the path taken by the data flow is already
+   determined by network configuration and routing protocols,
+   independently of the signaling itself; that is, signaling to set up
+   the routes themselves is not considered.  Instead, the signaling
+   simply interacts with nodes along the data flow path.  Additional
+   simplifications are that the actual signaling messages pass directly
+   through these nodes themselves (i.e., the 'path-coupled' case; see
+   Section 3.1.2) and that only unicast data flows are considered.
+
+   The signaling problem in this sense is very similar to that addressed
+   by RSVP.  However, there are two generalizations.  First, the
+   intention is that components of the NSIS protocol suite will be
+   usable in different parts of the Internet, for different needs,
+   without requiring a complete end-to-end deployment (in particular,
+   the signaling protocol messages may not need to run all the way
+   between the data flow endpoints).
+
+   Second, the signaling is intended for more purposes than just QoS
+   (resource reservation).  The basic mechanism to achieve this
+   flexibility is to divide the signaling protocol stack into two
+   layers: a generic (lower) layer, and an upper layer specific to each
+   signaling application.  The scope of NSIS work is to define both the
+   generic protocol and, initially, upper layers suitable for QoS
+   signaling (similar to the corresponding functionality in RSVP) and
+   middlebox signaling.  Further applications may be considered later.
+
+1.2.  Scope and Structure of the NSIS Framework
+
+   The underlying requirements for signaling in the context of NSIS are
+   defined in [1] and a separate security threats document [2]; other
+   related requirements can be found in [3] and [4] for QoS/Mobility and
+   middlebox communication, respectively.  This framework does not
+   replace or update these requirements.  Discussions about lessons to
+   be learned from existing signaling and resource management protocols
+   are contained in separate analysis documents [5], [6].
+
+   The role of this framework is to explain how NSIS signaling should
+   work within the broader networking context, and to describe the
+   overall structure of the protocol suite itself.  Therefore, it
+
+
+
+
+Hancock, et al.              Informational                      [Page 3]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   discusses important protocol considerations such as routing,
+   mobility, security, and interactions with network 'resource'
+   management (in the broadest sense).
+
+   The basic context for NSIS protocols is given in Section 3.
+   Section 3.1 describes the fundamental elements of NSIS protocol
+   operation in comparison to RSVP [7]; in particular, Section 3.1.3
+   describes more general signaling scenarios, and Section 3.1.4 defines
+   a broader class of signaling applications for which the NSIS
+   protocols should be useful.  The two-layer protocol architecture that
+   supports this generality is described in Section 3.2, and Section 3.3
+   gives examples of the ways in which particular signaling application
+   properties can be accommodated within signaling layer protocol
+   behavior.
+
+   The overall functionality required from the lower (generic) protocol
+   layer is described in Section 4.  This is not intended to define the
+   detailed design of the protocol or even design options, although some
+   are described as examples.  It describes the interfaces between this
+   lower-layer protocol and the IP layer (below) and signaling
+   application protocols (above), including the identifier elements that
+   appear on these interfaces (Section 4.6).  Following this, Section 5
+   describes how signaling applications that use the NSIS protocols can
+   interact sensibly with network layer operations; specifically,
+   routing (and re-routing), IP mobility, and network address
+   translation (NAT).
+
+   Section 6 describes particular signaling applications.  The example
+   of signaling for QoS (comparable to core RSVP QoS signaling
+   functionality) is given in detail in Section 6.1, which describes
+   both the signaling application specific protocol and example modes of
+   interaction with network resource management and other deployment
+   aspects.  However, note that these examples are included only as
+   background and for explanation; we do not intend to define an
+   over-arching architecture for carrying out resource management in the
+   Internet.  Further possible signaling applications are outlined in
+   Section 6.2.
+
+2.  Terminology
+
+   Classifier: an entity that selects packets based on their contents
+      according to defined rules.
+
+   [Data] flow: a stream of packets from sender to receiver that is a
+      distinguishable subset of a packet stream.  Each flow is
+      distinguished by some flow identifier (see Section 4.6.1).
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 4]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   Edge node: an (NSIS-capable) node on the boundary of some
+      administrative domain.
+
+   Interior nodes: the set of (NSIS-capable) nodes that form an
+      administrative domain, excluding the edge nodes.
+
+   NSIS Entity (NE): the function within a node that implements an NSIS
+      protocol.  In the case of path-coupled signaling, the NE will
+      always be on the data path.
+
+   NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS
+      protocol component that supports a specific signaling application.
+      See also Section 3.2.1.
+
+   NSIS Transport Layer Protocol (NTLP): placeholder name for the NSIS
+      protocol component that will support lower-layer (signaling
+      application-independent) functions.  See also Section 3.2.1.
+
+   Path-coupled signaling: a mode of signaling in which the signaling
+      messages follow a path that is tied to the data messages.
+
+   Path-decoupled signaling: signaling for state manipulation related to
+      data flows, but only loosely coupled to the data path; e.g., at
+      the AS level.
+
+   Peer discovery: the act of locating and/or selecting which NSIS peer
+      to carry out signaling exchanges with for a specific data flow.
+
+   Peer relationship: signaling relationship between two adjacent NSIS
+      entities (i.e., NEs with no other NEs between them).
+
+   Receiver: the node in the network that is receiving the data packets
+      in a flow.
+
+   Sender: the node in the network that is sending the data packets in a
+      flow.
+
+   Session: application layer flow of information for which some network
+      control state information is to be manipulated or monitored (see
+      Section 3.1.5).
+
+   Signaling application: the purpose of the NSIS signaling.  A
+      signaling application could be QoS management, firewall control,
+      and so on.  Totally distinct from any specific user application.
+
+
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 5]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+3.  Overview of Signaling Scenarios and Protocol Structure
+
+3.1.  Fundamental Signaling Concepts
+
+3.1.1.  Simple Network and Signaling Topology
+
+   The NSIS suite of protocols is envisioned to support various
+   signaling applications that need to install and/or manipulate state
+   in the network.  This state is related to a data flow and is
+   installed and maintained on the NSIS Entities (NEs) along the data
+   flow path through the network; not every node has to contain an NE.
+   The basic protocol concepts do not depend on the signaling
+   application, but the details of operation and the information carried
+   do.  This section discusses the basic entities involved with
+   signaling as well as interfaces between them.
+
+   Two NSIS entities that communicate directly are said to be in a 'peer
+   relationship'.  This concept might loosely be described as an 'NSIS
+   hop'; however, there is no implication that it corresponds to a
+   single IP hop.  Either or both NEs might store some state information
+   about the other, but there is no assumption that they necessarily
+   establish a long-term signaling connection between themselves.
+
+   It is common to consider a network as composed of various domains
+   (e.g., for administrative or routing purposes), and the operation of
+   signaling protocols may be influenced by these domain boundaries.
+   However, it seems there is no reason to expect that an 'NSIS domain'
+   should exactly overlap with an IP domain (AS, area), but it is likely
+   that its boundaries would consist of boundaries (segments) of one or
+   several IP domains.
+
+   Figure 1 shows a diagram of nearly the simplest possible signaling
+   configuration.  A single data flow is running from an application in
+   the sender to the receiver via routers R1, R2, and R3.  Each host and
+   two of the routers contain NEs that exchange signaling messages --
+   possibly in both directions -- about the flow.  This scenario is
+   essentially the same as that considered by RSVP for QoS signaling;
+   the main difference is that here we make no assumptions about the
+   particular sequence of signaling messages that will be invoked.
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 6]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+       Sender                                               Receiver
+   +-----------+      +----+      +----+      +----+      +-----------+
+   |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
+   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    |
+   |   |NE|====|======||NE||======||NE||==================|===|NE|    |
+   |   +--+    |      |+--+|      |+--+|                  |   +--+    |
+   +-----------+      +----+      +----+                  +-----------+
+
+      +--+
+      |NE| = NSIS      ==== = Signaling    ---> = Data flow messages
+      +--+   Entity           Messages            (unidirectional)
+
+                 Figure 1: Simple Signaling and Data Flows
+
+3.1.2.  Path-Coupled and Path-Decoupled Signaling
+
+   We can consider two basic paradigms for resource reservation
+   signaling, which we refer to as "path-coupled" and "path-decoupled".
+
+   In the path-coupled case, signaling messages are routed only through
+   NEs that are on the data path.  They do not have to reach all the
+   nodes on the data path.  (For example, there could be intermediate
+   signaling-unaware nodes, or the presence of proxies such as those
+   shown in Figure 2 could prevent the signaling from reaching the path
+   end points.)  Between adjacent NEs, the route taken by signaling and
+   data might diverge.  The path-coupled case can be supported by
+   various addressing styles, with messages either explicitly addressed
+   to the neighbor on-path NE, or addressed identically to the data
+   packets, but also with the router alert option (see [8] and [9]), and
+   intercepted.  These cases are considered in Section 4.2.  In the
+   second case, some network configurations may split the signaling and
+   data paths (see Section 5.1.1); this is considered an error case for
+   path-coupled signaling.
+
+   In the path-decoupled case, signaling messages are routed to nodes
+   (NEs) that are not assumed to be on the data path, but that are
+   (presumably) aware of it.  Signaling messages will always be directly
+   addressed to the neighbor NE, and the signaling endpoints may have no
+   relation at all with the ultimate data sender or receiver.  The
+   implications of path-decoupled operation for the NSIS protocols are
+   considered briefly in Section 3.2.6; however, the initial goal of
+   NSIS and this framework is to concentrate mainly on the path-coupled
+   case.
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 7]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+3.1.3.  Signaling to Hosts, Networks, and Proxies
+
+   There are different possible triggers for the signaling protocols.
+   Among them are user applications (that are using NSIS signaling
+   services), other signaling applications, network management actions,
+   some network events, and so on.  The variety of possible triggers
+   requires that the signaling can be initiated and terminated in the
+   different parts of the network: hosts, domain boundary nodes (edge
+   nodes), or interior domain nodes.
+
+   The NSIS protocol suite extends the RSVP model to consider this wider
+   variety of possible signaling exchanges.  As well as the basic
+   end-to-end model already described, examples such as end-to-edge and
+   edge-to-edge can be considered.  The edge-to-edge case might involve
+   the edge nodes communicating directly, as well as via the interior
+   nodes.
+
+   Although the end-to-edge (host-to-network) scenario requires only
+   intra-domain signaling, the other cases might need inter-domain NSIS
+   signaling as well if the signaling endpoints (hosts or network edges)
+   are connected to different domains.  Depending on the trust relation
+   between concatenated NSIS domains, the edge-to-edge scenario might
+   cover a single domain or multiple concatenated NSIS domains.  The
+   latter case assumes the existence of trust relations between domains.
+
+   In some cases, it is desired to be able to initiate and/or terminate
+   NSIS signaling not from the end host that sends/receives the data
+   flow, but from some other entities in the network that can be called
+   signaling proxies.  There could be various reasons for this:
+   signaling on behalf of the end hosts that are not NSIS-aware,
+   consolidation of the customer accounting (authentication,
+   authorization) in respect to consumed application and transport
+   resources, security considerations, limitation of the physical
+   connection between host and network, and so on.  This configuration
+   can be considered a kind of "proxy on the data path"; see Figure 2.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 8]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+                 Proxy1                        Proxy2
+   +------+      +----+    +----+    +----+    +----+      +--------+
+   |Sender|-...->|Appl|--->| R  |--->| R  |--->|Appl|-...->|Receiver|
+   |      |      |+--+|    |+--+|    |+--+|    |+--+|      |        |
+   +------+      ||NE||====||NE||====||NE||====||NE||      +--------+
+                 |+--+|    |+--+|    |+--+|    |+--+|
+                 +----+    +----+    +----+    +----+
+
+      +--+
+      |NE| = NSIS      ==== = Signaling    ---> = Data flow messages
+      +--+   Entity           Messages            (unidirectional)
+
+      Appl = signaling application
+
+                      Figure 2: "On path" NSIS proxy
+
+   This configuration presents two specific challenges for the
+   signaling:
+
+   o  A proxy that terminates signaling on behalf of the NSIS-unaware
+      host (or part of the network) should be able to determine that it
+      is the last NSIS-aware node along the path.
+
+   o  Where a proxy initiates NSIS signaling on behalf of the NSIS-
+      unaware host, interworking with some other "local" technology
+      might be required (for example, to provide QoS reservation from
+      proxy to the end host in the case of a QoS signaling application).
+
+
+   +------+      +----+      +----+      +----+      +--------+
+   |Sender|----->| PA |----->| R2 |----->| R3 |----->|Receiver|
+   |      |      |+--+|      |+--+|      +----+      |  +--+  |
+   +------+      ||NE||======||NE||==================|==|NE|  |
+                 |+--+|      |+--+|                  |  +--+  |
+                 +-..-+      +----+                  +--------+
+                   ..
+                   ..
+                 +-..-+
+                 |Appl|
+                 +----+
+
+            Appl = signaling         PA = Proxy for signaling
+                   application            application
+
+                      Figure 3: "Off path" NSIS proxy
+
+
+
+
+
+
+Hancock, et al.              Informational                      [Page 9]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   Another possible configuration, shown in Figure 3, is where an NE can
+   send and receive signaling information to a remote processor.  The
+   NSIS protocols may or may not be suitable for this remote
+   interaction, but in any case it is not currently part of the NSIS
+   problem.  This configuration is supported by considering the NE a
+   proxy at the signaling application level.  This is a natural
+   implementation approach for some policy control and centralized
+   control architectures; see also Section 6.1.4.
+
+3.1.4.  Signaling Messages and Network Control State
+
+   The distinguishing features of the signaling supported by the NSIS
+   protocols are that it is related to specific flows (rather than to
+   network operation in general), and that it involves nodes in the
+   network (rather than running transparently between the end hosts).
+
+   Therefore, each signaling application (upper-layer) protocol must
+   carry per-flow information for the aspects of network-internal
+   operation that are of interest to that signaling application.  An
+   example for the case of an RSVP-like QoS signaling application would
+   be state data representing resource reservations.  However, more
+   generally, the per-flow information might be related to some other
+   control function in routers and middleboxes along the path.  Indeed,
+   the signaling might simply be used to gather per-flow information,
+   without modifying network operation at all.
+
+   We call this information 'network control state' generically.
+   Signaling messages may install, modify, refresh, or simply read this
+   state from network elements for particular data flows.  Usually a
+   network element will also manage this information at the per-flow
+   level, although coarser-grained ('per-class') state management is
+   also possible.
+
+3.1.5.  Data Flows and Sessions
+
+   Formally, a data flow is a (unidirectional) sequence of packets
+   between the same endpoints that all follow a unique path through the
+   network (determined by IP routing and other network configuration).
+   A flow is defined by a packet classifier (in the simplest cases, just
+   the destination address and topological origin are needed).  In
+   general we assume that when discussing only the data flow path, we
+   only need to consider 'simple' fixed classifiers (e.g., IPv4 5-tuple
+   or equivalent).
+
+   A session is an application layer concept for an exchange of packets
+   between two endpoints, for which some network state is to be
+   allocated or monitored.  In simple cases, a session may map to a
+   specific flow; however, signaling applications are allowed to create
+
+
+
+Hancock, et al.              Informational                     [Page 10]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   more flexible flow:session relationships.  (Note that this concept of
+   'session' is different from that of RSVP, which defines a session as
+   a flow with a specific destination address and transport protocol.
+   The NSIS usage is closer to the session concepts of higher-layer
+   protocols.)
+
+   The simplest service provided by NSIS signaling protocols is the
+   management of network control state at the level of a specific flow,
+   as described in the previous subsection.  In particular, it should be
+   possible to monitor routing updates as they change the path taken by
+   a flow and, for example, update network state appropriately.  This is
+   no different from the case for RSVP (local path repair).  Where there
+   is a 1:1 flow:session relationship, this is all that is required.
+
+   However, for some more complex scenarios (especially mobility and
+   multihoming related ones; see [1] and the mobility discussion of
+   [5]), it is desirable to update the flow:session mapping during the
+   session lifetime.  For example, a new flow can be added, and the old
+   one deleted (and maybe in that order, for a 'make-before-break'
+   handover), effectively transferring the network control state between
+   data flows to keep it associated with the same session.  Such updates
+   are best managed by the end systems (generally, systems that
+   understand the flow:session mapping and are aware of the packet
+   classifier change).  To enable this, it must be possible to relate
+   signaling messages to sessions as well as to data flows.  A session
+   identifier (Section 4.6.2) is one component of the solution.
+
+3.2.  Layer Model for the Protocol Suite
+
+3.2.1.  Layer Model Overview
+
+   In order to achieve a modular solution for the NSIS requirements, the
+   NSIS protocol suite will be structured in two layers:
+
+   o  a 'signaling transport' layer, responsible for moving signaling
+      messages around, which should be independent of any particular
+      signaling application; and
+
+   o  a 'signaling application' layer, which contains functionality such
+      as message formats and sequences, specific to a particular
+      signaling application.
+
+   For the purpose of this document, we use the term 'NSIS Transport
+   Layer Protocol' (NTLP) to refer to the component that will be used in
+   the transport layer.  We also use the term 'NSIS Signaling Layer
+   Protocol' (NSLP) to refer generically to any protocol within the
+   signaling application layer; in the end, there will be several NSLPs,
+   largely independent of each other.  These relationships are
+
+
+
+Hancock, et al.              Informational                     [Page 11]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   illustrated in Figure 4.  Note that the NTLP may or may not have an
+   interesting internal structure (e.g., including existing transport
+   protocols), but that is not relevant at this level of description.
+
+                 ^                     +-----------------+
+                 |                     | NSIS Signaling  |
+                 |                     | Layer Protocol  |
+         NSIS    |    +----------------| for middleboxes |
+       Signaling |    | NSIS Signaling |        +-----------------+
+         Layer   |    | Layer Protocol +--------| NSIS Signaling  |
+                 |    |     for QoS     |       | Layer Protocol  |
+                 |    +-----------------+       |    for ...      |
+                 V                              +-----------------+
+                      =============================================
+         NSIS    ^         +--------------------------------+
+       Transport |         | NSIS Transport Layer Protocol  |
+         Layer   V         +--------------------------------+
+                      =============================================
+                           +--------------------------------+
+                           .      IP and lower layers       .
+                           .                                .
+
+                    Figure 4: NSIS Protocol Components
+
+   Note that not every generic function has to be located in the NTLP.
+   Another option would be to have re-usable components within the
+   signaling application layer.  Functionality within the NTLP should be
+   restricted to what interacts strongly with other transport and
+   lower-layer operations.
+
+3.2.2.  Layer Split Concept
+
+   This section describes the basic concepts underlying the
+   functionality of the NTLP.  First, we make a working assumption that
+   the protocol mechanisms of the NTLP operate only between adjacent NEs
+   (informally, the NTLP is a 'hop-by-hop' protocol), whereas any
+   larger-scope issues (including e2e aspects) are left to the upper
+   layers.
+
+   The way in which the NTLP works can be described as follows: When a
+   signaling message is ready to be sent from one NE, it is given to the
+   NTLP along with information about what flow it is for; it is then up
+   to the NTLP to get it to the next NE along the path (upstream or
+   downstream), where it is received and the responsibility of the NTLP
+   ends.  Note that there is no assumption here about how the messages
+   are actually addressed (this is a protocol design issue, and the
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 12]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   options are outlined in Section 4.2).  The key point is that the NTLP
+   for a given NE does not use any knowledge about addresses,
+   capabilities, or status of any NEs other than its direct peers.
+
+   The NTLP in the receiving NE either forwards the message directly or,
+   if there is an appropriate signaling application locally, passes it
+   upwards for further processing; the signaling application can then
+   generate another message to be sent via the NTLP.  In this way,
+   larger-scope (including end-to-end) message delivery is achieved.
+
+   This definition relates to NTLP operation.  It does not restrict the
+   ability of an NSLP to send messages by other means.  For example, an
+   NE in the middle or end of the signaling path could send a message
+   directly to the other end as a notification or acknowledgement of
+   some signaling application event.  However, the issues in sending
+   such messages (endpoint discovery, security, NAT traversal, and so
+   on) are so different from the direct peer-peer case that there is no
+   benefit in extending the NTLP to include such non-local
+   functionality.  Instead, an NSLP that requires such messages and
+   wants to avoid traversing the path of NEs should use some other
+   existing transport protocol.  For example, UDP or DCCP would be a
+   good match for many of the scenarios that have been proposed.
+   Acknowledgements and notifications of this type are considered
+   further in Section 3.3.6.
+
+   One motivation for restricting the NTLP to peer-relationship scope is
+   that if there are any options or variants in design approach -- or,
+   worse, in basic functionality -- it is easier to manage the resulting
+   complexity if it only impacts direct peers rather than potentially
+   the whole Internet.
+
+3.2.3.  Bypassing Intermediate Nodes
+
+   Because the NSIS problem includes multiple signaling applications, it
+   is very likely that a particular NSLP will only be implemented on a
+   subset of the NSIS-aware nodes on a path, as shown in Figure 5.  In
+   addition, a node inside an aggregation region will still wish to
+   ignore signaling messages that are per-flow, even if they are for a
+   signaling application that the node is generally able to process.
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 13]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+               +------+    +------+    +------+    +------+
+               |  NE  |    |  NE  |    |  NE  |    |  NE  |
+               |+----+|    |      |    |+----+|    |+----+|
+               ||NSLP||    |      |    ||NSLP||    ||NSLP||
+               || 1  ||    |      |    || 2  ||    || 1  ||
+               |+----+|    |      |    |+----+|    |+----+|
+               |  ||  |    |      |    |      |    |  ||  |
+               |+----+|    |+----+|    |+----+|    |+----+|
+           ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
+               |+----+|    |+----+|    |+----+|    |+----+|
+               +------+    +------+    +------+    +------+
+
+               Figure 5: Signaling with Heterogeneous NSLPs
+
+   Where signaling messages traverse such NSIS-aware intermediate nodes,
+   it is desirable to process them at the lowest level possible (in
+   particular, on the fastest path).  In order to offer a non-trivial
+   message transfer service (in terms of security, reliability and so
+   on) to the peer NSLP nodes, it is important that the NTLP at
+   intermediate nodes is as transparent as possible; that is, it carries
+   out minimal processing.  In addition, if intermediate nodes have to
+   do slow-path processing of all NSIS messages, this eliminates many of
+   the scaling benefits of aggregation, unless tunneling is used.
+
+   Considering first the case of messages sent with the router alert
+   option, there are two complementary methods to achieve this bypassing
+   of intermediate NEs:
+
+   o  At the IP layer, a set of protocol numbers or a range of values in
+      the router alert option can be used.  In this way, messages can be
+      marked with an implied granularity, and routers can choose to
+      apply further slow-path processing only to configured subsets of
+      messages.  This is the method used in [10] to distinguish per-flow
+      and per-aggregate signaling.
+
+   o  The NTLP could process the message but determine that there was no
+      local signaling application it was relevant to.  At this stage,
+      the message can be returned unchanged to the IP layer for normal
+      forwarding; the intermediate NE has effectively chosen to be
+      transparent to the message in question.
+
+   In both cases, the existence of the intermediate NE is totally hidden
+   from the NSLP nodes.  If later stages of the signaling use directly
+   addressed messages (e.g., for reverse routing), they will not involve
+   the intermediate NE at all, except perhaps as a normal router.
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 14]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   There may be cases where the intermediate NE would like to do some
+   restricted protocol processing, such as the following:
+
+   o  Translating addresses in message payloads (compare Section 4.6.1);
+      note that this would have to be done to messages passing in both
+      directions through a node.
+
+   o  Updating signaling application payloads with local status
+      information (e.g., path property measurement inside a domain).
+
+   If this can be done without fully terminating the NSIS protocols, it
+   would allow a more lightweight implementation of the intermediate NE,
+   and a more direct 'end-to-end' NTLP association between the peer
+   NSLPs where the signaling application is fully processed.  On the
+   other hand, this is only possible with a limited class of possible
+   NTLP designs, and makes it harder for the NTLP to offer a security
+   service (since messages have to be partially protected).  The
+   feasibility of this approach will be evaluated during the NTLP
+   design.
+
+3.2.4.  Core NSIS Transport Layer Functionality
+
+   This section describes the basic functionality to be supported by the
+   NTLP.  Note that the overall signaling solution will always be the
+   result of joint operation of both the NTLP and the signaling layer
+   protocols (NSLPs); for example, we can always assume that an NSLP is
+   operating above the NTLP and taking care of end-to-end issues (e.g.,
+   recovery of messages after restarts).
+
+   Therefore, NTLP functionality is essentially just efficient upstream
+   and downstream peer-peer message delivery, in a wide variety of
+   network scenarios.  Message delivery includes the act of locating
+   and/or selecting which NTLP peer to carry out signaling exchanges
+   with for a specific data flow.  This discovery might be an active
+   process (using specific signaling packets) or a passive process (a
+   side effect of using a particular addressing mode).  In addition, it
+   appears that the NTLP can sensibly carry out many of the functions
+   that enable signaling messages to pass through middleboxes, since
+   this is closely related to the problem of routing the signaling
+   messages in the first place.  Further details about NTLP
+   functionality are contained in Sections 3.2.5 and 4.3.
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 15]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+3.2.5.  State Management Functionality
+
+   Internet signaling requires the existence and management of state
+   within the network for several reasons.  This section describes how
+   state management functionality is split across the NSIS layers.
+   (Note that how the NTLP internal state is managed is a matter for its
+   design and indeed implementation.)
+
+   1.  Conceptually, the NTLP provides a uniform message delivery
+       service.  It is unaware of the difference in state semantics
+       between different types of signaling application messages (e.g.,
+       whether a message changes, just refreshes signaling application
+       state, or even has nothing to with signaling application state at
+       all).
+
+   2.  An NTLP instance processes and, if necessary, forwards all
+       signaling application messages "immediately".  (It might offer
+       different service classes, but these would be distinguished by,
+       for example, reliability or priority, not by state aspects.)
+       This means that the NTLP does not know explicit timer or message
+       sequence information for the signaling application; and that
+       signaling application messages pass immediately through an
+       NSLP-unaware node.  (Their timing cannot be jittered there, nor
+       can messages be stored up to be re-sent on a new path in case of
+       a later re-routing event.)
+
+   3.  Within any node, it is an implementation decision whether to
+       generate/jitter/filter refreshes separately within each signaling
+       application that needs this functionality, or to integrate it
+       with the NTLP implementation as a generic "soft-state management
+       toolbox".  The choice doesn't affect the NTLP specification at
+       all.  Implementations might piggyback NTLP soft-state refresh
+       information (if the NTLP works this way) on signaling application
+       messages, or they might even combine soft-state management
+       between layers.  The state machines of the NTLP and NSLPs remain
+       logically independent, but an implementation is free to allow
+       them to interact to reduce the load on the network to the same
+       level that would be achieved by a monolithic model.
+
+   4.  It may be helpful for signaling applications to receive
+       state-management related 'triggers' from the NTLP indicating that
+       a peer has failed or become available ("down/up notifications").
+       These triggers would be about adjacent NTLP peers, rather than
+       signaling application peers.  We can consider this another case
+       of route change detection/notification (which the NTLP is also
+       allowed to do anyway).  However, apart from generating such
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 16]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+       triggers, the NTLP takes no action itself on such events, other
+       than to ensure that subsequent signaling messages are routed
+       correctly.
+
+   5.  The existence of these triggers doesn't replace NSLP refreshes as
+       the mechanism for maintaining liveness at the signaling
+       application level.  In this sense, up/down notifications are
+       advisories that allow faster reaction to events in the network,
+       but that shouldn't be built into NSLP semantics.  (This is
+       essentially the same distinction, with the same rationale, that
+       SNMP makes between notifications and normal message exchanges.)
+
+3.2.6.  Path-Decoupled Operation
+
+   Path-decoupled signaling is defined as signaling for state
+   installation along the data path, without the restriction of passing
+   only through nodes that are located on the data path.  Signaling
+   messages can be routed to nodes that are off the data path, but that
+   are (presumably) aware of it.  This allows a looser coupling between
+   signaling and data plane nodes (e.g., at the autonomous system
+   level).  Although support for path-decoupled operation is not one of
+   the initial goals of the NSIS work, this section is included for
+   completeness and to capture some initial considerations for future
+   reference.
+
+   The main advantages of path-decoupled signaling are ease of
+   deployment and support of additional functionality.  The ease of
+   deployment comes from a restriction of the number of impacted nodes
+   in case of deployment and/or upgrade of an NSLP.  Path-decoupled
+   signaling would allow, for instance, deploying a solution without
+   upgrading any of the routers in the data plane.  Additional
+   functionality that can be supported includes the use of off-path
+   proxies to support authorization or accounting architectures.
+
+   There are potentially significant differences in the way that the two
+   signaling paradigms should be analyzed.  Using a single centralized
+   off-path NE may increase the requirements in terms of message
+   handling; on the other hand, path-decoupled signaling is equally
+   applicable to distributed off-path entities.  Failure recovery
+   scenarios need to be analyzed differently because fate-sharing
+   between data and control planes can no longer be assumed.
+   Furthermore, the interpretation of sender/receiver orientation
+   becomes less natural.  With the local operation of the NTLP, the
+   impact of path-decoupled signaling on the routing of signaling
+   messages is presumably restricted to the problem of peer
+   determination.  The assumption that the off-path NSIS nodes are
+   loosely tied to the data path suggests, however, that peer
+   determination can still be based on L3 routing information.  This
+
+
+
+Hancock, et al.              Informational                     [Page 17]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   means that a path-decoupled signaling solution could be implemented
+   using a lower-layer protocol presenting the same service interface to
+   NSLPs as the path-coupled NTLP.  A new message transport protocol
+   (possibly derived from the path-coupled NTLP) would be needed, but
+   NSLP specifications and the inter-layer interaction would be
+   unchanged from the path-coupled case.
+
+3.3.  Signaling Application Properties
+
+   It is clear that many signaling applications will require specific
+   protocol behavior in their NSLP.  This section outlines some of the
+   options for NSLP behavior; further work on selecting from these
+   options would depend on detailed analysis of the signaling
+   application in question.
+
+3.3.1.  Sender/Receiver Orientation
+
+   In some signaling applications, a node at one end of the data flow
+   takes responsibility for requesting special treatment (such as a
+   resource reservation) from the network.  Which end may depend on the
+   signaling application, or on characteristics of the network
+   deployment.
+
+   In a sender-initiated approach, the sender of the data flow requests
+   and maintains the treatment for that flow.  In a receiver-initiated
+   approach, the receiver of the data flow requests and maintains the
+   treatment for that flow.  The NTLP itself has no freedom in this
+   area: Next NTLP peers have to be discovered in the sender-to-receiver
+   direction, but after that the default assumption is that signaling is
+   possible both upstream and downstream (unless a signaling application
+   specifically indicates that this is not required).  This implies that
+   backward routing state must be maintained by the NTLP or that
+   backward routing information must be available in the signaling
+   message.
+
+   The sender- and receiver-initiated approaches have several
+   differences in their operational characteristics.  The main ones are
+   as follows:
+
+   o  In a receiver-initiated approach, the signaling messages traveling
+      from the receiver to the sender must be backward routed such that
+      they follow exactly the same path as was followed by the signaling
+      messages belonging to the same flow traveling from the sender to
+      the receiver.  In a sender-initiated approach, provided that
+      acknowledgements and notifications can be delivered securely to
+      the sending node, backward routing is not necessary, and nodes do
+      not have to maintain backward routing state.
+
+
+
+
+Hancock, et al.              Informational                     [Page 18]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   o  In a sender-initiated approach, a mobile node can initiate a
+      reservation for its outgoing flows as soon as it has moved to
+      another roaming subnetwork.  In a receiver-initiated approach, a
+      mobile node has to inform the receiver about its handover, thus
+      allowing the receiver to initiate a reservation for these flows.
+      For incoming flows, the reverse argument applies.
+
+   o  In general, setup and modification will be fastest if the node
+      responsible for authorizing these actions can initiate them
+      directly within the NSLP.  A mismatch between authorizing and
+      initiating NEs will cause additional message exchanges, either in
+      the NSLP or in a protocol executed prior to NSIS invocation.
+      Depending on how the authorization for a particular signaling
+      application is done, this may favor either sender- or receiver-
+      initiated signaling.  Note that this may complicate modification
+      of network control state for existing flows.
+
+3.3.2.  Uni- and Bi-Directional Operation
+
+   For some signaling applications and scenarios, signaling may only be
+   considered for a unidirectional data flow.  However, in other cases,
+   there may be interesting relationships in the signaling between the
+   two flows of a bi-directional session; an example is QoS for a voice
+   call.  Note that the path in the two directions may differ due to
+   asymmetric routing.  In the basic case, bi-directional signaling can
+   simply use a separate instance of the same signaling mechanism in
+   each direction.
+
+   In constrained topologies where parts of the route are symmetric, it
+   may be possible to use a more unified approach to bi-directional
+   signaling; e.g., carrying the two signaling directions in common
+   messages.  This optimization might be used for example to make mobile
+   QoS signaling more efficient.
+
+   In either case, the correlation of the signaling for the two flow
+   directions is carried out in the NSLP.  The NTLP would simply be
+   enabled to bundle the messages together.
+
+3.3.3.  Heterogeneous Operation
+
+   It is likely that the appropriate way to describe the state for which
+   NSIS is signaling will vary from one part of the network to another
+   (depending on the signaling application).  For example, in the QoS
+   case, resource descriptions that are valid for inter-domain links
+   will probably be different from those useful for intra-domain
+   operation (and the latter will differ from one domain to another).
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 19]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   One way to address this issue is to consider the state description
+   used within the NSLP as carried in globally-understood objects and
+   locally-understood objects.  The local objects are only applicable
+   for intra-domain signaling, while the global objects are mainly used
+   in inter-domain signaling.  Note that the local objects are still
+   part of the protocol but are inserted, used, and removed by one
+   single domain.
+
+   The purpose of this division is to provide additional flexibility in
+   defining the objects carried by the NSLP such that only the objects
+   applicable in a particular setting are used.  One approach for
+   reflecting the distinction is that local objects could be put into
+   separate local messages that are initiated and terminated within one
+   single domain; an alternative is that they could be "stacked" within
+   the NSLP messages that are used anyway for inter-domain signaling.
+
+3.3.4.  Aggregation
+
+   It is a well-known problem that per-flow signaling in large-scale
+   networks presents scaling challenges because of the large number of
+   flows that may traverse individual nodes.
+
+   The possibilities for aggregation at the level of the NTLP are quite
+   limited; the primary scaling approach for path-coupled signaling is
+   for a signaling application to group flows together and to perform
+   signaling for the aggregate, rather than for the flows individually.
+   The aggregate may be created in a number of ways; for example, the
+   individual flows may be sent down a tunnel, or given a common
+   Differentiated Services Code Point (DSCP) marking.  The aggregation
+   and de-aggregation points perform per flow signaling, but nodes
+   within the aggregation region should only be forced to process
+   signaling messages for the aggregate.  This depends on the ability of
+   the interior nodes to ignore the per-flow signaling as discussed in
+   Section 3.2.3.
+
+   Individual NSLPs will need to specify what aggregation means in their
+   context, and how it should be performed.  For example, in the QoS
+   context it is possible to add together the resources specified in a
+   number of separate reservations.  In the case of other applications,
+   such as signaling to NATs and firewalls, the feasibility (and even
+   the meaning) of aggregation is less clear.
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 20]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+3.3.5.  Peer-Peer and End-End Relationships
+
+   The assumption in this framework is that the NTLP will operate
+   'locally'; that is, just over the scope of a single peer
+   relationship.  End-to-end operation is built up by concatenating
+   these relationships.  Non-local operation (if any) will take place in
+   NSLPs.
+
+   The peering relations may also have an impact on the required amount
+   of state at each NSIS entity.  When direct interaction with remote
+   peers is not allowed, it may be required to keep track of the path
+   that a message has followed through the network.  This could be
+   achieved by keeping per-flow state at the NSIS entities, as is done
+   in RSVP.  Another approach would be to maintain a record route object
+   in the messages; this object would be carried within the NSIS
+   protocols, rather than depend on the route-recording functionality
+   provided by the IP layer.
+
+3.3.6.  Acknowledgements and Notifications
+
+   We are assuming that the NTLP provides a simple message transfer
+   service, and that any acknowledgements or notifications it generates
+   are handled purely internally (and apply within the scope of a single
+   NTLP peer relationship).
+
+   However, we expect that some signaling applications will require
+   acknowledgements regarding the failure/success of state installation
+   along the data path, and this will be an NSLP function.
+
+   Acknowledgements can be sent along the sequence of NTLP peer
+   relationships towards the signaling initiator, which relieves the
+   requirements on the security associations that need to be maintained
+   by NEs and that can allow NAT traversal in both directions.  (If this
+   direction is towards the sender, it implies maintaining reverse
+   routing state in the NTLP.)  In certain circumstances (e.g., trusted
+   domains), an optimization could be to send acknowledgements directly
+   to the signaling initiator outside the NTLP (see Section 3.2.2),
+   although any such approach would have to take into account the
+   necessity of handling denial of service attacks launched from outside
+   the network.
+
+   The semantics of the acknowledgement messages are of particular
+   importance.  An NE sending a message could assume responsibility for
+   the entire downstream chain of NEs, indicating (for instance) the
+   availability of reserved resources for the entire downstream path.
+   Alternatively, the message could have a more local meaning,
+   indicating (for instance) that a certain failure or degradation
+   occurred at a particular point in the network.
+
+
+
+Hancock, et al.              Informational                     [Page 21]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   Notifications differ from acknowledgements because they are not
+   (necessarily) generated in response to other signaling messages.
+   This means that it may not be obvious how to determine where the
+   notification should be sent.  Other than that, the same
+   considerations apply as for acknowledgements.  One useful distinction
+   to make would be to differentiate between notifications that trigger
+   a signaling action and others that don't.  The security requirements
+   for the latter are less stringent, which means they could be sent
+   directly to the NE they are destined for (provided that this NE can
+   be determined).
+
+3.3.7.  Security and Other AAA Issues
+
+   In some cases, it will be possible to achieve the necessary level of
+   signaling security by using basic 'channel security' mechanisms [11]
+   at the level of the NTLP, and the possibilities are described in
+   Section 4.7.  In other cases, signaling applications may have
+   specific security requirements, in which case they are free to invoke
+   their own authentication and key exchange mechanisms and to apply
+   'object security' to specific fields within the NSLP messages.
+
+   In addition to authentication, the authorization (to manipulate
+   network control state) has to be considered as functionality above
+   the NTLP level, since it will be entirely application specific.
+   Indeed, authorization decisions may be handed off to a third party in
+   the protocol (e.g., for QoS, the resource management function as
+   described in Section 6.1.4).  Many different authorization models are
+   possible, and the variations impact:
+
+   o  what message flows take place -- for example, whether
+      authorization information is carried along with a control state
+      modification request or is sent in the reverse direction in
+      response to it;
+
+   o  what administrative relationships are required -- for example,
+      whether authorization takes place only between peer signaling
+      applications, or over longer distances.
+
+   Because the NTLP operates only between adjacent peers and places no
+   constraints on the direction or order in which signaling applications
+   can send messages, these authorization aspects are left open to be
+   defined by each NSLP.  Further background discussion of this issue is
+   contained in [12].
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 22]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+4.  The NSIS Transport Layer Protocol
+
+   This section describes the overall functionality required from the
+   NTLP.  It mentions possible protocol components within the NTLP layer
+   and the different possible addressing modes that can be utilized, as
+   well as the assumed transport and state management functionality.
+   The interfaces between NTLP and the layers above and below it are
+   identified, with a description of the identity elements that appear
+   on these interfaces.
+
+   This discussion is not intended to design the NTLP or even to
+   enumerate design options, although some are included as examples.
+   The goal is to provide a general discussion of required functionality
+   and to highlight some of the issues associated with this.
+
+4.1.  Internal Protocol Components
+
+   The NTLP includes all functionality below the signaling application
+   layer and above the IP layer.  The functionality that is required
+   within the NTLP is outlined in Section 3.2.4, with some more details
+   in Sections 3.2.5 and 4.3.
+
+   Some NTLP functionality could be provided via components operating as
+   sublayers within the NTLP design.  For example, if specific transport
+   capabilities are required (such as congestion avoidance,
+   retransmission, and security), then existing protocols (such as
+   TCP+TLS or DCCP+IPsec) could be incorporated into the NTLP.  This
+   possibility is not required or excluded by this framework.
+
+   If peer-peer addressing (Section 4.2) is used for some messages, then
+   active next-peer discovery functionality will be required within the
+   NTLP to support the explicit addressing of these messages.  This
+   could use message exchanges for dynamic peer discovery as a sublayer
+   within the NTLP; there could also be an interface to external
+   mechanisms to carry out this function.
+
+                ====================      ===========================
+             ^  +------------------+      +-------------------------+
+             |  |                  |      | NSIS Specific Functions |
+             |  |                  |      |            .............|
+      NSIS   |  |    Monolithic    |      |+----------+.   Peer    .|
+   Transport |  |     Protocol     |      || Existing |. Discovery .|
+     Layer   |  |                  |      || Protocol |.  Aspects  .|
+             |  |                  |      |+----------+.............|
+             V  +------------------+      +-------------------------+
+                ====================      ===========================
+
+                   Figure 6: Options for NTLP Structure
+
+
+
+Hancock, et al.              Informational                     [Page 23]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+4.2.  Addressing
+
+   There are two ways to address a signaling message being transmitted
+   between NTLP peers:
+
+   o  peer-peer, where the message is addressed to a neighboring NSIS
+      entity that is known to be closer to the destination NE.
+
+   o  end-to-end, where the message is addressed to the flow destination
+      directly and intercepted by an intervening NE.
+
+   With peer-peer addressing, an NE will determine the address of the
+   next NE based on the payload of the message (and potentially on the
+   previous NE).  This requires that the address of the destination NE
+   be derivable from the information present in the payload, either by
+   using some local routing table or through participation in active
+   peer discovery message exchanges.  Peer-peer addressing inherently
+   supports tunneling of messages between NEs, and is equally applicable
+   to the path-coupled and path-decoupled cases.
+
+   In the case of end-to-end addressing, the message is addressed to the
+   data flow receiver, and (some of) the NEs along the data path
+   intercept the messages.  The routing of the messages should follow
+   exactly the same path as the associated data flow (but see
+   Section 5.1.1 on this point).  Note that securing messages sent this
+   way raises some interesting security issues (these are discussed in
+   [2]).  In addition, it is a matter of the protocol design what should
+   be used as the source address of the message (the flow source or
+   signaling source).
+
+   It is not possible at this stage to mandate one addressing mode or
+   the other.  Indeed, each is necessary for some aspects of NTLP
+   operation: In particular, initial discovery of the next downstream
+   peer will usually require end-to-end addressing, whereas reverse
+   routing will always require peer-peer addressing.  For other message
+   types, the choice is a matter of protocol design.  The mode used is
+   not visible to the NSLP, and the information needed in each case is
+   available from the flow identifier (Section 4.6.1) or locally stored
+   NTLP state.
+
+4.3.  Classical Transport Functions
+
+   The NSIS signaling protocols are responsible for transporting
+   (signaling) data around the network; in general, this requires
+   functionality such as congestion management, reliability, and so on.
+   This section discusses how much of this functionality should be
+   provided within the NTLP.  It appears that this doesn't affect the
+   basic way in which the NSLP/NTLP layers relate to each other (e.g.,
+
+
+
+Hancock, et al.              Informational                     [Page 24]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   in terms of the semantics of the inter-layer interaction); it is much
+   more a question of the overall performance/complexity tradeoff
+   implied by placing certain functions within each layer.
+
+   Note that, per the discussion at the end of Section 3.2.3, there may
+   be cases where intermediate nodes wish to modify messages in transit
+   even though they do not perform full signaling application
+   processing.  In this case, not all the following functionality would
+   be invoked at every intermediate node.
+
+   The following functionality is assumed to lie within the NTLP:
+
+   1.  Bundling together of small messages (comparable to [13]) can be
+       provided locally by the NTLP as an option, if desired; it doesn't
+       affect the operation of the network elsewhere.  The NTLP should
+       always support unbundling, to avoid the cost of negotiating the
+       feature as an option.  (The related function of refresh
+       summarization -- where objects in a refresh message are replaced
+       with a reference to a previous message identifier -- is left to
+       NSLPs, which can then do this in a way tuned to the state
+       management requirements of the signaling application.  Additional
+       transparent compression functionality could be added to the NTLP
+       design later as a local option.)  Note that end-to-end addressed
+       messages for different flows cannot be bundled safely unless the
+       next node on the outgoing interface is known to be NSIS-aware.
+
+   2.  When needed, message fragmentation should be provided by the
+       NTLP.  The use of IP fragmentation for large messages may lead to
+       reduced reliability and may be incompatible with some addressing
+       schemes.  Therefore, this functionality should be provided within
+       the NTLP as a service for NSLPs that generate large messages.
+       How the NTLP determines and accommodates Maximum Transmission
+       Unit (MTU) constraints is left as a matter of protocol design.
+       To avoid imposing the cost of reassembly on intermediate nodes,
+       the fragmentation scheme used should allow for the independent
+       forwarding of individual fragments towards a node hosting an
+       interested NSLP.
+
+   3.  There can be significant benefits for signaling applications if
+       state-changing messages are delivered reliably (as introduced in
+       [13] for RSVP; see also the more general analysis of [14]).  This
+       does not change any assumption about the use of soft-state by
+       NSLPs to manage signaling application state, and it leaves the
+       responsibility for detecting and recovering from application
+       layer error conditions in the NSLP.  However, it means that such
+       functionality does not need to be tuned to handle fast recovery
+       from message loss due to congestion or corruption in the lower
+       layers, and it also means that the NTLP can prevent the
+
+
+
+Hancock, et al.              Informational                     [Page 25]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+       amplification of message loss rates caused by fragmentation.
+       Reliable delivery functionality is invoked by the NSLP on a
+       message-by-message basis and is always optional to use.
+
+   4.  The NTLP should not allow signaling messages to cause congestion
+       in the network (i.e., at the IP layer).  Congestion could be
+       caused by retransmission of lost signaling packets or by upper
+       layer actions (e.g., a flood of signaling updates to recover from
+       a route change).  In some cases, it may be possible to engineer
+       the network to ensure that signaling cannot overload it; in
+       others, the NTLP would have to detect congestion and to adapt the
+       rate at which it allows signaling messages to be transmitted.
+       Principles of congestion control in Internet protocols are given
+       in [15].  The NTLP may or may not be able to detect overload in
+       the control plane itself (e.g., an NSLP-aware node several
+       NTLP-hops away that cannot keep up with the incoming message
+       rate) and indicate this as a flow-control condition to local
+       signaling applications.  However, for both the congestion and
+       overload cases, it is up to the signaling applications themselves
+       to adapt their behavior accordingly.
+
+4.4.  Lower Layer Interfaces
+
+   The NTLP interacts with 'lower layers' of the protocol stack for the
+   purposes of sending and receiving signaling messages.  This framework
+   places the lower boundary of the NTLP at the IP layer.  The interface
+   to the lower layer is therefore very simple:
+
+   o  The NTLP sends raw IP packets
+
+   o  The NTLP receives raw IP packets.  In the case of peer-peer
+      addressing, they have been addressed directly to it.  In the case
+      of end-to-end addressing, this will be achieved by intercepting
+      packets that have been marked in some special way (by special
+      protocol number or by some option interpreted within the IP layer,
+      such as the router alert option).
+
+   o  The NTLP receives indications from the IP layer (including local
+      forwarding tables and routing protocol state) that provide some
+      information about route changes and similar events (see
+      Section 5.1).
+
+   For correct message routing, the NTLP needs to have some information
+   about link and IP layer configuration of the local networking stack.
+   In general, it needs to know how to select the outgoing interface for
+   a signaling message and where this must match the interface that will
+   be used by the corresponding flow.  This might be as simple as just
+   allowing the IP layer to handle the message using its own routing
+
+
+
+Hancock, et al.              Informational                     [Page 26]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   table.  There is no intention to do something different from IP
+   routing (for end-to-end addressed messages); however, some hosts
+   allow applications to bypass routing for their data flows, and the
+   NTLP processing must account for this.  Further network layer
+   information would be needed to handle scoped addresses (if such
+   things ever exist).
+
+   Configuration of lower-layer operation to handle flows in particular
+   ways is handled by the signaling application.
+
+4.5.  Upper Layer Services
+
+   The NTLP offers transport-layer services to higher-layer signaling
+   applications for two purposes: sending and receiving signaling
+   messages, and exchanging control and feedback information.
+
+   For sending and receiving messages, two basic control primitives are
+   required:
+
+   o  Send Message, to allow the signaling application to pass data to
+      the NTLP for transport.
+
+   o  Receive Message, to allow the NTLP to pass received data to the
+      signaling application.
+
+   The NTLP and signaling application may also want to exchange other
+   control information, such as the following:
+
+   o  Signaling application registration/de-registration, so that
+      particular signaling application instances can register their
+      presence with the transport layer.  This may also require some
+      identifier to be agreed upon between the NTLP and signaling
+      application to support the exchange of further control information
+      and to allow the de-multiplexing of incoming data.
+
+   o  NTLP configuration, allowing signaling applications to indicate
+      what optional NTLP features they want to use, and to configure
+      NTLP operation, such as controlling what transport layer state
+      should be maintained.
+
+   o  Error messages, to allow the NTLP to indicate error conditions to
+      the signaling application, and vice versa.
+
+   o  Feedback information, such as route change indications so that the
+      signaling application can decide what action to take.
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 27]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+4.6.  Identity Elements
+
+4.6.1.  Flow Identification
+
+   The flow identification is a method of identifying a flow in a unique
+   way.  All packets associated with the same flow will be identified by
+   the same flow identifier.  The key aspect of the flow identifier is
+   to provide enough information such that the signaling flow receives
+   the same treatment along the data path as the actual data itself;
+   i.e., consistent behavior is applied to the signaling and data flows
+   by a NAT or policy-based forwarding engine.
+
+   Information that could be used in flow identification may include:
+
+   o  source IP address;
+
+   o  destination IP address;
+
+   o  protocol identifier and higher layer (port) addressing;
+
+   o  flow label (typical for IPv6);
+
+   o  SPI field for IPsec encapsulated data; and
+
+   o  DSCP/TOS field.
+
+   It is assumed that at most limited wildcarding on these identifiers
+   is needed.
+
+   We assume here that the flow identification is not hidden within the
+   NSLP, but is explicitly part of the NTLP.  The justification for this
+   is that being able to do NSIS processing, even at a node which was
+   unaware of the specific signaling application (see Section 3.2.3)
+   might be valuable.  An example scenario would be messages passing
+   through an addressing boundary where the flow identification had to
+   be re-written.
+
+4.6.2.  Session Identification
+
+   There are circumstances in which being able to refer to signaling
+   application state independently of the underlying flow is important.
+   For example, if the address of one of the flow endpoints changes due
+   to a mobility event, it is desirable to be able to change the flow
+   identifier without having to install a completely new reservation.
+   The session identifier provides a method to correlate the signaling
+   about the different flows with the same network control state.
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 28]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   The session identifier is essentially a signaling application
+   concept, since it is only used in non-trivial state management
+   actions that are application specific.  However, we assume here that
+   it should be visible within the NTLP.  This enables it to be used to
+   control NTLP behavior; for example, by controlling how the transport
+   layer should forward packets belonging to this session (as opposed to
+   this signaling application).  In addition, the session identifier can
+   be used by the NTLP to demultiplex received signaling messages
+   between multiple instances of the same signaling application, if such
+   an operational scenario is supported (see Section 4.6.3 for more
+   information on signaling application identification).
+
+   To be useful for mobility support, the session identifier should be
+   globally unique, and it should not be modified end-to-end.  It is
+   well known that it is practically impossible to generate identifiers
+   in a way that guarantees this property; however, using a large random
+   number makes it highly likely.  In any case, the NTLP ascribes no
+   valuable semantics to the identifier (such as 'session ownership');
+   this problem is left to the signaling application, which may be able
+   to secure it to be used for this purpose.
+
+4.6.3.  Signaling Application Identification
+
+   Because the NTLP can be used to support several NSLP types, there is
+   a need to identify which type a particular signaling message exchange
+   is being used for.  This is to support:
+
+   o  processing of incoming messages -- the NTLP should be able to
+      demultiplex these towards the appropriate signaling applications;
+      and
+
+   o  processing of general messages at an NSIS-aware intermediate node
+      -- if the node does not handle the specific signaling application,
+      it should be able to make a forwarding decision without having to
+      parse upper-layer information.
+
+   No position is taken on the form of the signaling application
+   identifier, or even the structure of the signaling application
+   'space': free-standing applications, potentially overlapping groups
+   of capabilities, etc.  These details should not influence the rest of
+   the NTLP design.
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 29]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+4.7.  Security Properties
+
+   It is assumed that the only security service required within the NTLP
+   is channel security.  Channel security requires a security
+   association to be established between the signaling endpoints, which
+   is carried out via some authentication and key management exchange.
+   This functionality could be provided by reusing a standard protocol.
+
+   In order to protect a particular signaling exchange, the NSIS entity
+   needs to select the security association that it has in place with
+   the next NSIS entity that will be receiving the signaling message.
+   The ease of doing this depends on the addressing model in use by the
+   NTLP (see Section 4.2).
+
+   Channel security can provide many different types of protection to
+   signaling exchanges, including integrity and replay protection and
+   encryption.  It is not clear which of these is required at the NTLP
+   layer, although most channel security mechanisms support them all.
+   It is also not clear how tightly an NSLP can 'bind' to the channel
+   security service provided by the NTLP.
+
+   Channel security can also be applied to the signaling messages with
+   differing granularity; i.e., all or parts of the signaling message
+   may be protected.  For example, if the flow is traversing a NAT, only
+   the parts of the message that do not need to be processed by the NAT
+   should be protected.  (Alternatively, if the NAT takes part in NTLP
+   security procedures, it only needs to be given access to the message
+   fields containing addresses, often just the flow id.)  Which parts of
+   the NTLP messages need protecting is an open question, as is what
+   type of protection should be applied to each.
+
+5.  Interactions with Other Protocols
+
+5.1.  IP Routing Interactions
+
+   The NTLP is responsible for determining the next node to be visited
+   by the signaling protocol.  For path-coupled signaling, this next
+   node should be one that will be visited by the data flow.  In
+   practice, this peer discovery will be approximate, as any node could
+   use any feature of the peer discovery packet to route it differently
+   from the corresponding data flow packets.  Divergence between the
+   data and signaling paths can occur due to load sharing or load
+   balancing (Section 5.1.1).  An example specific to the case of QoS is
+   given in Section 6.1.1.  Route changes cause a temporary divergence
+   between the data path and the path on which signaling state has been
+   installed.  The occurrence, detection, and impact of route changes is
+   described in Section 5.1.2.  A description of this issue in the
+   context of QoS is given in Section 6.1.2.
+
+
+
+Hancock, et al.              Informational                     [Page 30]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+5.1.1.  Load Sharing and Policy-Based Forwarding
+
+   Load sharing or load balancing is a network optimization technique
+   that exploits the existence of multiple paths to the same destination
+   in order to obtain benefits in terms of protection, resource
+   efficiency, or network stability.  It has been proposed for a number
+   of routing protocols, such as OSPF [16] and others.  In general, load
+   sharing means that packet forwarding will take into account header
+   fields in addition to the destination address; a general discussion
+   of such techniques and the problems they cause is provided in [17].
+
+   The significance of load sharing in the context of NSIS is that
+   routing of signaling messages using end-to-end addressing does not
+   guarantee that these messages will follow the data path.  Policy-
+   based forwarding for data packets -- where the outgoing link is
+   selected based on policy information about fields additional to the
+   packet destination address -- has the same impact.  Signaling and
+   data packets may diverge because of both of these techniques.
+
+   If signaling packets are given source and destination addresses
+   identical to data packets, signaling and data may still diverge
+   because of layer-4 load balancing (based on protocol or port).  Such
+   techniques would also cause ICMP errors to be misdirected to the
+   source of the data because of source address spoofing.  If signaling
+   packets are made identical in the complete 5-tuple, divergence may
+   still occur because of the presence of router alert options.  The
+   same ICMP misdirection applies, and it becomes difficult for the end
+   systems to distinguish between data and signaling packets.  Finally,
+   QoS routing techniques may base the routing decision on any field in
+   the packet header (e.g., DSCP).
+
+5.1.2.  Route Changes
+
+   In a connectionless network, each packet is independently routed
+   based on its header information.  Whenever a better route towards the
+   destination becomes available, this route is installed in the
+   forwarding table and will be used for all subsequent (data and
+   signaling) packets.  This can cause a divergence between the path
+   along which state has been installed and the path along which
+   forwarding will actually take place.  The problem of route changes is
+   reduced if route pinning is performed.  Route pinning refers to the
+   independence of the path taken by certain data packets from
+   reachability changes caused by routing updates from an Interior
+   Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).
+   Nothing about NSIS signaling prevents route pinning from being used
+   as a network engineering technique, provided that it is done in a way
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 31]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   that preserves the common routing of signaling and data.  However,
+   even if route pinning is used, it cannot be depended on to prevent
+   all route changes (for example, in the case of link failures).
+
+   Handling route changes requires the presence of three processes in
+   the signaling protocol:
+
+   1.  route change detection
+
+   2.  installation of state on the new path
+
+   3.  removal of state on the old path
+
+   Many route change detection methods can be used, some needing
+   explicit protocol support, and some of which are implementation-
+   internal.  They differ in their speed of reaction and in the types of
+   change they can detect.  In rough order of increasing applicability,
+   they can be summarized as follows:
+
+   1.  monitoring changes in local forwarding table state
+
+   2.  monitoring topology changes in a link-state routing protocol
+
+   3.  inference from changes in data packet TTL
+
+   4.  inference from loss of packet stream in a flow-aware router
+
+   5.  inference from changes in signaling packet TTL
+
+   6.  changed route of an end-to-end addressed signaling packet
+
+   7.  changed route of a specific end-to-end addressed probe packet
+
+   These methods can be categorized as being based on network monitoring
+   (methods 1-2), on data packet monitoring (methods 3-4) and on
+   monitoring signaling protocol messages (methods 5-7); method 6 is the
+   baseline method of RSVP.  The network monitoring methods can only
+   detect local changes; in particular, method 1 can only detect an
+   event that changes the immediate next downstream hop, and method 2
+   can only detect changes within the scope of the link-state protocol.
+   Methods 5-7, which are contingent on monitoring signaling messages,
+   become less effective as soft-state refresh rates are reduced.
+
+   When a route change has been detected, it is important that state is
+   installed as quickly as possible along the new path.  It is not
+   guaranteed that the new path will be able to provide the same
+   characteristics that were available on the old path.  To avoid
+   duplicate state installation or, worse, rejection of the signaling
+
+
+
+Hancock, et al.              Informational                     [Page 32]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   message because of previously installed state, it is important to be
+   able to recognize the new signaling message as belonging to an
+   existing session.  In this respect, we distinguish between route
+   changes with associated change of the flow identification (e.g., in
+   case of a mobility event when the IP source might change) and route
+   changes without change of the flow identification (e.g., in case of a
+   link failure along the path).  The former case requires an identifier
+   independent from the flow identification; i.e., the session
+   identifier (Section 4.6.2).  Mobility issues are discussed in more
+   detail in Section 5.2.
+
+   When state has been installed along the new path, the existing state
+   on the old path needs to be removed.  With the soft-state principle,
+   this will happen automatically because of the lack of refresh
+   messages.  Depending on the refresh timer, however, it may be
+   required to tear down this state much faster (e.g., because it is
+   tied to an accounting record).  In that case, the teardown message
+   needs to be able to distinguish between the new path and the old
+   path.
+
+   In some environments, it is desirable to provide connectivity and
+   per-flow or per-class state management with high-availability
+   characteristics; i.e., with rapid transparent recovery, even in the
+   presence of route changes.  This may require interactions with
+   protocols that are used to manage the routing in this case, such as
+   Virtual Router Redundancy Protocol (VRRP) [18].
+
+   Our basic assumption about such interactions is that the NTLP would
+   be responsible for detecting the route change and ensuring that
+   signaling messages were re-routed consistently (in the same way as
+   the data traffic).  However, further state re-synchronization
+   (including failover between 'main' and 'standby' nodes in the high
+   availability case) would be the responsibility of the signaling
+   application and its NSLP, and would possibly be triggered by the
+   NTLP.
+
+5.2.  Mobility and Multihoming Interactions
+
+   The issues associated with mobility and multihoming are a
+   generalization of the basic route change case of the previous
+   section.  As well as the fact that packets for a given session are no
+   longer traveling over a single topological path, the following extra
+   considerations arise:
+
+   1.  The use of IP-layer mobility and multihoming means that more than
+       one IP source or destination address will be associated with a
+       single session.  The same applies if application-layer solutions
+       (e.g., SIP-based approaches) are used.
+
+
+
+Hancock, et al.              Informational                     [Page 33]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   2.  Mobile IP and associated protocols use some special
+       encapsulations for some segments of the data path.
+
+   3.  The double route may persist for some time in the network (e.g.,
+       in the case of a 'make-before-break' handover being done by a
+       multihomed host).
+
+   4.  Conversely, the re-routing may be rapid and routine (unlike
+       network-internal route changes), increasing the importance of
+       rapid state release on old paths.
+
+   The interactions between mobility and signaling have been extensively
+   analyzed in recent years, primarily in the context of RSVP and Mobile
+   IP interaction (e.g., the mobility discussion of [5]), but also in
+   that of other types of network (e.g., [19]).  A general review of the
+   fundamental interactions is given in [20], which provides further
+   details on many of the subjects considered in this section.
+
+   We assume that the signaling will refer to 'outer' IP headers when
+   defining the flows it is controlling.  There are two main reasons for
+   this.  The first is that the data plane will usually be unable to
+   work in terms of anything else when implementing per-flow treatment
+   (e.g., we cannot expect that a router will analyze inner headers to
+   decide how to schedule packets).  The second reason is that we are
+   implicitly relying on the security provided by the network
+   infrastructure to ensure that the correct packets are given the
+   special treatment being signaled for, and this is built on the
+   relationship between packet source and destination addresses and
+   network topology.  (This is essentially the same approach that is
+   used as the basis of route optimization security in Mobile IPv6
+   [21].)  The consequence of this assumption is that we see the packet
+   streams to (or from) different addresses as different flows.  Where a
+   flow is carried inside a tunnel, it is seen as a different flow
+   again.  The encapsulation issues (point (2) above) are therefore to
+   be handled the same way as other tunneling cases (Section 5.4).
+
+   Therefore, the most critical aspect is that multiple flows are being
+   used, and the signaling for them needs to be correlated.  This is the
+   intended role of the session identifier (see Section 4.6.2, which
+   also describes some of the security requirements for such an
+   identifier).  Although the session identifier is visible at the NTLP,
+   the signaling application is responsible for performing the
+   correlation (and for doing so securely).  The NTLP responsibility is
+   limited to delivering the signaling messages for each flow between
+   the correct signaling application peers.  The locations at which the
+   correlation takes place are the end system and the signaling-
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 34]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   application-aware node in the network where the flows meet.  (This
+   node is generally referred to as the "crossover router"; it can be
+   anywhere in the network.)
+
+   Although much work has been done in the past on finding the crossover
+   router directly from information held in particular mobility
+   signaling protocols, the initial focus of NSIS work should be a
+   solution that is not tightly bound to any single mobility approach.
+   In other words, it should be possible to determine the crossover
+   router based on NSIS signaling.  (This doesn't rule out the
+   possibility that some implementations may be able to do this
+   discovery faster; e.g., by being tightly integrated with local
+   mobility management protocols.  This is directly comparable to
+   spotting route changes in fixed networks by being routing aware.)
+
+   Note that the crossover router discovery may involve end-to-end
+   signaling exchanges (especially for flows towards the mobile or
+   multihomed node), which raises a latency concern.  On the other hand,
+   end-to-end signaling will have been necessary in any case, at the
+   application level not only to communicate changed addresses, but also
+   to update packet classifiers along the path.  It is a matter for
+   further analysis to decide how these exchanges could be combined or
+   carried out in parallel.
+
+   On the shared part of the path, signaling is needed at least to
+   update the packet classifiers to include the new flow, although if
+   correlation with the existing flow is possible it should be possible
+   to bypass any policy or admission control processing.  State
+   installation on the new path (and possibly release on the old one)
+   are also required.  Which entity (one of the end hosts or the
+   crossover router) controls all these procedures depends on which
+   entities are authorized to carry out network state manipulations, so
+   this is therefore a matter of signaling application and NSLP design.
+   The approach may depend on the sender/receiver orientation of the
+   original signaling (see Section 3.3.1).  In addition, in the mobility
+   case, the old path may no longer be directly accessible to the mobile
+   node; inter-access-router communication may be required to release
+   state in these circumstances.
+
+   The frequency of handovers in some network types makes fast handover
+   support protocols desirable, for selecting the optimal access router
+   for handover (for example, [22]), and for transferring state
+   information to avoid having to regenerate it in the new access router
+   after handover (for example, [23]).  Both of these procedures could
+   have strong interactions with signaling protocols.  The access router
+   selection might depend on the network control state that could be
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 35]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   supported on the path through the new access router.  Transfer of
+   signaling application state or NTLP/NSLP protocol state may be a
+   candidate for context transfer.
+
+5.3.  Interactions with NATs
+
+   Because at least some messages will almost inevitably contain
+   addresses and possibly higher-layer information as payload, we must
+   consider the interaction with address translation devices (NATs).
+   These considerations apply both to 'traditional' NATs of various
+   types (as defined in [24]) as well as some IPv4/v6 transition
+   mechanisms, such as Stateless IP/ICMP Translation (SIIT) [25].
+
+   In the simplest case of an NSIS-unaware NAT in the path, payloads
+   will be uncorrected, and signaling will refer to the flow
+   incorrectly.  Applications could attempt to use STUN [26] or similar
+   techniques to detect and recover from the presence of the NAT.  Even
+   then, NSIS protocols would have to use a well-known encapsulation
+   (TCP/UDP/ICMP) to avoid being dropped by more cautious low-end NAT
+   devices.
+
+   A simple 'NSIS-aware' NAT would require flow identification
+   information to be in the clear and not to be integrity protected.  An
+   alternative conceptual approach is to consider the NAT functionality
+   part of message processing itself, in which case the translating node
+   can take part natively in any NSIS protocol security mechanisms.
+   Depending on NSIS protocol layering, it would be possible for this
+   processing to be done in an NSIS entity that was otherwise ignorant
+   of any particular signaling applications.  This is the motivation for
+   including basic flow identification information in the NTLP
+   (Section 4.6.1).
+
+   Note that all of this discussion is independent of the use of a
+   specific NSLP for general control of NATs (and firewalls).  That case
+   is considered in Section 6.2.
+
+5.4.  Interactions with IP Tunneling
+
+   Tunneling is used in the Internet for a number of reasons, such as
+   flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
+   private networking, and so on.  An NSIS solution must continue to
+   work in the presence of these techniques.  The presence of the tunnel
+   should not cause problems for end-to-end signaling, and it should
+   also be possible to use NSIS signaling to control the treatment of
+   the packets carrying the tunneled data.
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 36]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   It is assumed that the NSIS approach will be similar to that of [27],
+   where the signaling for the end-to-end data flow is tunneled along
+   with that data flow and is invisible to nodes along the path of the
+   tunnel (other than the endpoints).  This provides backwards
+   compatibility with networks where the tunnel endpoints do not support
+   the NSIS protocols.  We assume that NEs will not unwrap tunnel
+   encapsulations to find and process tunneled signaling messages.
+
+   To signal for the packets carrying the tunneled data, the tunnel is
+   considered a new data flow in its own right, and NSIS signaling is
+   applied to it recursively.  This requires signaling support in at
+   least one tunnel endpoint.  In some cases (where the signaling
+   initiator is at the opposite end of the data flow from the tunnel
+   initiator; i.e., in the case of receiver initiated signaling), the
+   ability to provide a binding between the original flow identification
+   and that for the tunneled flow is needed.  It is left open here
+   whether this should be an NTLP or an NSLP function.
+
+6.  Signaling Applications
+
+   This section gives an overview of NSLPs for particular signaling
+   applications.  The assumption is that the NSLP uses the generic
+   functionality of the NTLP given earlier; this section describes
+   specific aspects of NSLP operation.  It includes simple examples that
+   are intended to clarify how NSLPs fit into the framework.  It does
+   not replace or even form part of the formal NSLP protocol
+   specifications; in particular, initial designs are being developed
+   for NSLPs for resource reservation [28] and middlebox communication
+   [29].
+
+6.1.  Signaling for Quality of Service
+
+   In the case of signaling for QoS, all the basic NSIS concepts of
+   Section 3.1 apply.  In addition, there is an assumed directionality
+   of the signaling process, in that one end of the signaling flow takes
+   responsibility for actually requesting the resource.  This leads to
+   the following definitions:
+
+   o  QoS NSIS Initiator (QNI): the signaling entity that makes the
+      resource request, usually as a result of user application request.
+
+   o  QoS NSIS Responder (QNR): the signaling entity that acts as the
+      endpoint for the signaling and that can optionally interact with
+      applications as well.
+
+   o  QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR
+      that propagates NSIS signaling further through the network.
+
+
+
+
+Hancock, et al.              Informational                     [Page 37]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   Each of these entities will interact with a resource management
+   function (RMF) that actually allocates network resources (router
+   buffers, interface bandwidth, and so on).
+
+   Note that there is no constraint on which end of the signaling flow
+   should take the QNI role: With respect to the data flow direction, it
+   could be at the sending or receiving end.
+
+6.1.1.  Protocol Message Semantics
+
+   The QoS NSLP will include a set of messages to carry out resource
+   reservations along the signaling path.  A possible set of message
+   semantics for the QoS NSLP is shown below.  Note that the 'direction'
+   column in the table below only indicates the 'orientation' of the
+   message.  Messages can be originated and absorbed at QNF nodes as
+   well as the QNI or QNR; an example might be QNFs at the edge of a
+   domain exchanging messages to set up resources for a flow across a
+   it.  Note that it is left open if the responder can release or modify
+   a reservation, during or after setup.  This seems mainly a matter of
+   assumptions about authorization, and the possibilities might depend
+   on resource type specifics.
+
+   The table also explicitly includes a refresh operation.  This does
+   nothing to a reservation except extend its lifetime, and it is one
+   possible state management mechanism (see next section).
+
+   +-----------+-----------+-------------------------------------------+
+   | Operation | Direction |                 Operation                 |
+   +-----------+-----------+-------------------------------------------+
+   |  Request  |   I-->R   |    Create a new reservation for a flow    |
+   |           |           |                                           |
+   |   Modify  |   I-->R   |       Modify an existing reservation      |
+   |           | (&R-->I?) |                                           |
+   |           |           |                                           |
+   |  Release  |   I-->R   |       Delete (tear down) an existing      |
+   |           | (&R-->I?) |                reservation                |
+   |           |           |                                           |
+   |  Accept/  |   R-->I   |  Confirm (possibly modified?) or reject a |
+   |   Reject  |           |            reservation request            |
+   |           |           |                                           |
+   |   Notify  |  I-->R &  |    Report an event detected within the    |
+   |           |   R-->I   |                  network                  |
+   |           |           |                                           |
+   |  Refresh  |   I-->R   |    State management (see Section 6.1.2)   |
+   +-----------+-----------+-------------------------------------------+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 38]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+6.1.2.  State Management
+
+   The primary purpose of NSIS is to manage state information along the
+   path taken by a data flow.  The issues regarding state management
+   within the NTLP (state related to message transport) are described in
+   Section 4.  The QoS NSLP will typically have to handle additional
+   state related to the desired resource reservation to be made.
+
+   There two critical issues to be considered in building a robust NSLP
+   to handle this problem:
+
+   o  The protocol must be scalable.  It should allow minimization of
+      the resource reservation state-storage demands that it implies for
+      intermediate nodes; in particular, storage of state per 'micro'
+      flow is likely to be impossible except at the very edge of the
+      network.  A QoS signaling application might require per-flow or
+      lower granularity state; examples of each for the case of QoS
+      would be IntServ [30] or RMD [31] (per 'class' state),
+      respectively.
+
+   o  The protocol must be robust against failure and other conditions
+      that imply that the stored resource reservation state has to be
+      moved or removed.
+
+   For resource reservations, soft-state management is typically used as
+   a general robustness mechanism.  According to the discussion of
+   Section 3.2.5, the soft-state protocol mechanisms are built into the
+   NSLP for the specific signaling application that needs them; the NTLP
+   sees this simply as a sequence of (presumably identical) messages.
+
+6.1.3.  Route Changes and QoS Reservations
+
+   In this section, we will explore the expected interaction between
+   resource signaling and routing updates (the precise source of routing
+   updates does not matter).  The normal operation of the NSIS protocol
+   will lead to the situation depicted in Figure 7, where the reserved
+   resources match the data path.
+
+                   reserved +-----+  reserved  +-----+
+                  =========>| QNF |===========>| QNF |
+                            +-----+            +-----+
+                 --------------------------------------->
+                                 data path
+
+                 Figure 7: Normal NSIS Protocol Operation
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 39]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   A route change can occur while such a reservation is in place.  The
+   route change will be installed immediately, and any data will be
+   forwarded on the new path.  This situation is depicted Figure 8.
+
+   Resource reservation on the new path will only be started once the
+   next control message is routed along the new path.  This means that
+   there is a certain time interval during which resources are not
+   reserved on (part of) the data path, and certain delay or
+   drop-sensitive applications will require that this time interval be
+   minimized.  Several techniques to achieve this could be considered.
+   As an example, RSVP [7] has the concept of local repair, whereby the
+   router may be triggered by a route change.  In that case, the RSVP
+   node can start sending PATH messages directly after the route has
+   been changed.  Note that this option may not be available if no
+   per-flow state is kept in the QNF.  Another approach would be to
+   pre-install backup state, and it would be the responsibility of the
+   QoS-NSLP to do this.  However, mechanisms for identifying backup
+   paths and routing the necessary signaling messages along them are not
+   currently considered in the NSIS requirements and framework.
+
+                              Route update
+                                   |
+                                   v
+                       reserved +-----+  reserved  +-----+
+                      =========>| QNF |===========>| QNF |
+                                +-----+            +-----+
+                       --------   ||
+                               \  ||           +-----+
+                                |  ===========>| QNF |
+                                |              +-----+
+                                +--------------------------->
+                                  data path
+
+                          Figure 8: Route Change
+
+   The new path might not be able to provide the same guarantees that
+   were available on the old path.  Therefore, it might be desirable for
+   the QNF to wait until resources have been reserved on the new path
+   before allowing the route change to be installed (unless, of course,
+   the old path no longer exists).  However, delaying the route change
+   installation while waiting for reservation setup needs careful
+   analysis of the interaction with the routing protocol being used, in
+   order to avoid routing loops.
+
+   Another example related to route changes is denoted as severe
+   congestion and is explained in [31].  This solution adapts to a route
+   change when a route change creates congestion on the new routed path.
+
+
+
+
+Hancock, et al.              Informational                     [Page 40]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+6.1.4.  Resource Management Interactions
+
+   The QoS NSLP itself is not involved in any specific resource
+   allocation or management techniques.  The definition of an NSLP for
+   resource reservation with Quality of Service, however, implies the
+   notion of admission control.  For a QoS NSLP, the measure of
+   signaling success will be the ability to reserve resources from the
+   total resource pool that is provisioned in the network.  We define
+   the function responsible for allocating this resource pool as the
+   Resource Management Function (RMF).  The RMF is responsible for all
+   resource provisioning, monitoring, and assurance functions in the
+   network.
+
+   A QoS NSLP will rely on the RMF to do resource management and to
+   provide inputs for admission control.  In this model, the RMF acts as
+   a server towards client NSLP(s).  Note, however, that the RMF may in
+   turn use another NSLP instance to do the actual resource provisioning
+   in the network.  In this case, the RMF acts as the initiator (client)
+   of an NSLP.
+
+   This essentially corresponds to a multi-level signaling paradigm,
+   with an 'upper' level handling internetworking QoS signaling
+   (possibly running end-to-end), and a 'lower' level handling the more
+   specialized intra-domain QoS signaling (running between just the
+   edges of the network).  (See [10], [32], and [33] for a discussion of
+   similar architectures.)  Given that NSIS signaling is already
+   supposed to be able to support multiple instances of NSLPs for a
+   given flow and limited scope (e.g., edge-to-edge) operation, it is
+   not currently clear that supporting the multi-level model leads to
+   any new protocol requirements for the QoS NSLP.
+
+   The RMF may or may not be co-located with a QNF (note that
+   co-location with a QNI/QNR can be handled logically as a combination
+   between QNF and QNI/QNR).  To cater for both cases, we define a
+   (possibly logical) QNF-RMF interface.  Over this interface,
+   information may be provided from the RMF about monitoring, resource
+   availability, topology, and configuration.  In the other direction,
+   the interface may be used to trigger requests for resource
+   provisioning.  One way to formalize the interface between the QNF and
+   the RMF is via a Service Level Agreement (SLA).  The SLA may be
+   static or it may be dynamically updated by means of a negotiation
+   protocol.  Such a protocol is outside the scope of NSIS.
+
+   There is no assumed restriction on the placement of the RMF.  It may
+   be a centralized RMF per domain, several off-path distributed RMFs,
+   or an on-path RMF per router.  The advantages and disadvantages of
+   both approaches are well-known.  Centralization typically allows
+   decisions to be taken using more global information, with more
+
+
+
+Hancock, et al.              Informational                     [Page 41]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   efficient resource utilization as a result.  It also facilitates
+   deployment or upgrade of policies.  Distribution allows local
+   decision processes and rapid response to data path changes.
+
+6.2.  Other Signaling Applications
+
+   As well as the use for 'traditional' QoS signaling, it should be
+   possible to develop NSLPs for other signaling applications that
+   operate on different types of network control state.  One specific
+   case is setting up flow-related state in middleboxes (firewalls,
+   NATs, and so on).  Requirements for such communication are given in
+   [4].  Other examples include network monitoring and testing, and
+   tunnel endpoint discovery.
+
+7.  Security Considerations
+
+   This document describes a framework for signaling protocols that
+   assumes a two-layer decomposition, with a common lower layer (NTLP)
+   supporting a family of signaling-application-specific upper-layer
+   protocols (NSLPs).  The overall security considerations for the
+   signaling therefore depend on the joint security properties assumed
+   or demanded for each layer.
+
+   Security for the NTLP is discussed in Section 4.7.  We have assumed
+   that, apart from being resistant to denial of service attacks against
+   itself, the main role of the NTLP will be to provide message
+   protection over the scope of a single peer relationship, between
+   adjacent signaling application entities.  (See Section 3.2.3 for a
+   discussion of the case where these entities are separated by more
+   than one NTLP hop.)  These functions can ideally be provided by an
+   existing channel security mechanism, preferably using an external key
+   management mechanism based on mutual authentication.  Examples of
+   possible mechanisms are TLS, IPsec and SSH.  However, there are
+   interactions between the actual choice of security protocol and the
+   rest of the NTLP design.  Primarily, most existing channel security
+   mechanisms require explicit identification of the peers involved at
+   the network and/or transport level.  This conflicts with those
+   aspects of path-coupled signaling operation (e.g., discovery) where
+   this information is not even implicitly available because peer
+   identities are unknown; the impact of this 'next-hop problem' on RSVP
+   design is discussed in the security properties document [6] and also
+   influences many parts of the threat analysis [2].  Therefore, this
+   framework does not mandate the use of any specific channel security
+   protocol; instead, this has to be integrated with the design of the
+   NTLP as a whole.
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 42]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   Security for the NSLPs is entirely dependent on signaling application
+   requirements.  In some cases, no additional protection may be
+   required compared to what is provided by the NTLP.  In other cases,
+   more sophisticated object-level protection and the use of public-
+   key-based solutions may be required.  In addition, the NSLP needs to
+   consider the authorization requirements of the signaling application.
+   Authorization is a complex topic, for which a very brief overview is
+   provided in Section 3.3.7.
+
+   Another factor is that NTLP security mechanisms operate only locally,
+   whereas NSLP mechanisms may also need to operate over larger regions
+   (not just between adjacent peers), especially for authorization
+   aspects.  This complicates the analysis of basing signaling
+   application security on NTLP protection.
+
+   An additional concern for signaling applications is the session
+   identifier security issue (Sections 4.6.2 and 5.2).  The purpose of
+   this identifier is to decouple session identification (as a handle
+   for network control state) from session "location" (i.e., the data
+   flow endpoints).  The identifier/locator distinction has been
+   extensively discussed in the user plane for end-to-end data flows,
+   and is known to lead to non-trivial security issues in binding the
+   two together again.  Our problem is the analogue in the control
+   plane, and is at least similarly complex, because of the need to
+   involve nodes in the interior of the network as well.
+
+   Further work on this and other security design will depend on a
+   refinement of the NSIS threats work begun in [2].
+
+8.  References
+
+8.1.  Normative References
+
+   [1]   Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
+         April 2004.
+
+   [2]   Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
+         Steps in Signaling (NSIS)", RFC 4081, June 2005.
+
+   [3]   Chaskar, H., "Requirements of a Quality of Service (QoS)
+         Solution for Mobile IP", RFC 3583, September 2003.
+
+   [4]   Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
+         "Middlebox Communications (midcom) Protocol Requirements",
+         RFC 3304, August 2002.
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 43]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+8.2.  Informative References
+
+   [5]   Manner, J. and X. Fu, "Analysis of Existing Quality of Service
+         Signaling Protocols", Work in Progress, December 2004.
+
+   [6]   Tschofenig, H., "RSVP Security Properties", Work in Progress,
+         February 2005.
+
+   [7]   Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
+         "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
+         Specification", RFC 2205, September 1997.
+
+   [8]   Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
+
+   [9]   Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
+         RFC 2711, October 1999.
+
+   [10]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
+         "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
+         September 2001.
+
+   [11]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
+         Security Considerations", BCP 72, RFC 3552, July 2003.
+
+   [12]  Tschofenig, H., "NSIS Authentication, Authorization and
+         Accounting Issues", Work in Progress, March 2003.
+
+   [13]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
+         Molendini, "RSVP Refresh Overhead Reduction Extensions",
+         RFC 2961, April 2001.
+
+   [14]  Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of
+         Hard-State and Soft-State Signaling Protocols", Computer
+         Communication Review, Volume 33, Number 4, October 2003.
+
+   [15]  Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
+         September 2000.
+
+   [16]  Apostolopoulos, G., Kamat, S., Williams, D., Guerin, R., Orda,
+         A., and T. Przygienda, "QoS Routing Mechanisms and OSPF
+         Extensions", RFC 2676, August 1999.
+
+   [17]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
+         Multicast Next-Hop Selection", RFC 2991, November 2000.
+
+   [18]  Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
+         3768, April 2004.
+
+
+
+
+Hancock, et al.              Informational                     [Page 44]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   [19]  Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg,
+         "DiffServ Resource Management in IP-based Radio Access
+         Networks", Proceedings of 4th International Symposium on
+         Wireless Personal Multimedia Communications WPMC'01, September
+         9 - 12 2001.
+
+   [20]  Manner, J., Lopez, A., Mihailovic, A., Velayos, H., Hepworth,
+         E., and Y. Khouaja, "Evaluation of Mobility and QoS
+         Interaction", Computer Networks Volume 38, Issue 2, p. 137-163,
+         5 February 2002.
+
+   [21]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
+         IPv6", RFC 3775, June 2004.
+
+   [22]  Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and
+         E. Shim, "Candidate Access Router Discovery (CARD)", Work in
+         Progress, May 2005.
+
+   [23]  Kempf, J., "Problem Description: Reasons For Performing Context
+         Transfers Between Nodes in an IP Access Network", RFC 3374,
+         September 2002.
+
+   [24]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
+         (NAT) Terminology and Considerations", RFC 2663, August 1999.
+
+   [25]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
+         RFC 2765, February 2000.
+
+   [26]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
+         - Simple Traversal of User Datagram Protocol (UDP) Through
+         Network Address Translators (NATs)", RFC 3489, March 2003.
+
+   [27]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
+         Operation Over IP Tunnels", RFC 2746, January 2000.
+
+   [28]  Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
+         Quality-of-Service signaling", Work in Progress, February 2005.
+
+   [29]  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
+         (NSLP)", Work in Progress, February 2005.
+
+   [30]  Braden, R., Clark, D., and S. Shenker, "Integrated Services in
+         the Internet Architecture: an Overview", RFC 1633, June 1994.
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 45]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+   [31]  Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
+         Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs,
+         "Resource Management in Diffserv (RMD): A Functionality and
+         Performance Behavior Overview", Seventh International Workshop
+         on Protocols for High-Speed networks PfHSN 2002, 22 - 24
+         April 2002.
+
+   [32]  Ferrari, D., Banerjea, A., and H. Zhang, "Network Support for
+         Multimedia - A Discussion of the Tenet Approach",
+         Berkeley TR-92-072, November 1992.
+
+   [33]  Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
+         Differentiated Services Architecture for the Internet",
+         RFC 2638, July 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 46]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+Appendix A.  Contributors
+
+   Several parts of the introductory sections of this document (in
+   particular, in Sections 3.1 and 3.3) are based on contributions from
+   Ilya Freytsis, then of Cetacean Networks, Inc.
+
+   Bob Braden originally proposed "A Two-Level Architecture for Internet
+   Signalling" as an Internet-Draft in November 2001.  This document
+   served as an important starting point for the framework discussed
+   herein, and the authors owe a debt of gratitude to Bob for this
+   proposal.
+
+Appendix B.  Acknowledgements
+
+   The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
+   Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for
+   significant contributions in particular areas of this document.  In
+   addition, the authors would like to acknowledge Cedric Aoun, Attila
+   Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
+   Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler,
+   Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De
+   Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne,
+   Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars
+   Westberg, and Lixia Zhang for insights and inputs during this and
+   previous framework activities.  Dave Oran, Michael Richardson, and
+   Alex Zinin provided valuable comments during the final review stages.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 47]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+Authors' Addresses
+
+   Robert Hancock
+   Siemens/Roke Manor Research
+   Old Salisbury Lane
+   Romsey, Hampshire  SO51 0ZN
+   UK
+
+   EMail: robert.hancock@roke.co.uk
+
+
+   Georgios Karagiannis
+   University of Twente
+   P.O. BOX 217
+   7500 AE Enschede
+   The Netherlands
+
+   EMail: g.karagiannis@ewi.utwente.nl
+
+
+   John Loughney
+   Nokia Research Center
+   11-13 Itamerenkatu
+   Helsinki  00180
+   Finland
+
+   EMail: john.loughney@nokia.com
+
+
+   Sven Van den Bosch
+   Alcatel
+   Francis Wellesplein 1
+   B-2018 Antwerpen
+   Belgium
+
+   EMail: sven.van_den_bosch@alcatel.be
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 48]
+
+RFC 4080                     NSIS Framework                    June 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   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 BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hancock, et al.              Informational                     [Page 49]
+