NSIS Working Group
   Internet Draft                               Robert Hancock (editor)
                                            Siemens/Roke Manor Research
                                                          Ilya Freytsis
                                                      Cetacean Networks
                                                   Georgios Karagiannis
                                                               Ericsson
                                                          John Loughney
                                                                  Nokia
                                                     Sven Van den Bosch
                                                                Alcatel
   Document: draft-ietf-nsis-fw-01.txt draft-ietf-nsis-fw-02.txt
   Expires: May September 2003                                   March 2003                                      November 2002

                    Next Steps in Signaling: Framework

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

Abstract

   The NSIS Next Steps in Signaling working group is considering protocols
   for signaling for
   resources for information about a traffic data flow along its path in the
   network. The
   requirements for such Based on existing work on signaling are being developed in [2]; requirements, this
   Internet Draft will propose a
   document proposes an architectural framework for such signaling. signaling
   protocols.

   This initial version document provides a model of for the network entities that take
   part in such signaling, and the signaling. It discusses the considerations that must be taken
   into account in developing relationship between signaling and
   the framework, particularly rest of network operation. We decompose the options overall signaling
   protocol suite into a generic (lower) layer, with a separate upper
   layers for each specific signaling application. An initial proposal
   for the structure split between these layers is given, describing the overall
   functionality of such a protocol, the lower layer, and discussing the ways that upper
   layer behavior can be adapted to specific signaling application
   requirements.

   This framework also considers the general interactions between
   NSIS
   signaling and other protocols and network layer functions, including security issues.

   Finally, it includes background material on how NSIS could support
   particular signaling applications.

   It is expected that future versions of this document will distill
   these structural options into a concrete technical framework, specifically routing and
   material on particular signaling applications
   mobility. The different routing and deployment
   scenarios will mobility events that impact
   signaling operation are described, along with how their handling
   should be moved into separate NSIS applicability statements. divided between the generic and application-specific
   layers. Finally, an example signaling application (for Quality of
   Service) is described in more detail.

Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [3]. [2].
   [Editor's note: if - as is likely - we don't end up using these words
   in the framework, this paragraph will disappear.]

Table of Contents

   1. Introduction...................................................3
     1.1 Definition of the NSIS Signaling Problem ...................3
     1.2 Scope and Structure of the NSIS Framework ................................4 ..................4
   2. Terminology....................................................5
   3. Overall Framework Structure....................................6
     3.1 Basic Overview of Signaling Entities Scenarios and Interfaces ....................6 Protocol Structure.........6
     3.1 Fundamental Signaling Concepts .............................6
     3.1.1   NSIS Entities ..........................................6   Simple Network and Signaling Topology ..................6
     3.1.2   Placement of NSIS Entities .............................8
     3.1.3   NSIS Protocol Components ...............................9   Signaling to Hosts, Networks and Proxies ...............7
     3.1.3   Signaling Messages and Network Control State ...........9
     3.1.4   Data Flows and Sessions ...............................10
     3.2 Options Layer Model for Modes of NSIS Operation .......................10 the Protocol Suite ........................11
     3.2.1   Path-Coupled and Path-Decoupled Signaling .............10   Layer Model Overview ..................................11
     3.2.2   Inter-domain and Intra-domain Signaling ...............11   Layer Split Concept ...................................12
     3.2.3   End-to-End, Edge-to-Edge, and End-to-Edge .............12   Core NTLP Functionality ...............................13
     3.2.4   Global and Local   Path De-Coupled Operation ............................12
     3.2.5   Multicast versus Unicast ..............................13
     3.2.6   Sender versus Receiver Initiated Signaling ............13
     3.2.7   Uni-Directional and Bi-Directional Reservations .......14 .............................14
     3.3 Basic Assumptions and Conceptual Issues ...................15 Signaling Application Properties ..........................14
     3.3.1   Basic Assumptions .....................................15   Sender/Receiver Orientation ...........................15
     3.3.2   NI, NF, NR functionality ..............................15   Uni- and Bi-Directional Operation .....................16
     3.3.3   NI, NF, NR relationship   Heterogeneous Operation ...............................16
     3.3.4   NSIS Addressing .......................................16   Peer-Peer and End-End Relationships ...................17
     3.3.5   NSIS Layer Boundaries .................................17   Acknowledgements and Notifications ....................17
     3.3.6   NSIS Acknowledgement   Security and Notification Semantics .......17 other AAA Issues .........................18
     3.4 Open Layer Model Issues ...................................19
     3.4.1   Classical Transport Functionality .....................19
     3.4.2   State Management ......................................20
   4. Protocol Components...........................................18 The NSIS Transport Layer Protocol.............................21
     4.1 Internal Protocol Components ..............................21
     4.2 Addressing ................................................22
     4.3 Lower Layer Interfaces ....................................18
     4.2 ....................................22
     4.4 Upper Layer Services ......................................18
     4.3 Protocol Structure ........................................20
     4.3.1   Internal Layering .....................................20
     4.3.2   Protocol Messages .....................................21
     4.4 State Management ..........................................22 ......................................23
     4.5 Identity Elements .........................................24
     4.5.1   Flow Identification ...................................24
     4.5.2   Reservation   Session Identification ............................24 ................................24
     4.5.3   NSLP   Signaling Application Identification ...................................25 ..................25
     4.6 Security Properties .......................................25
   5. NSIS Protocol Interactions....................................25
     5.1 Resource Management Interactions ..........................25
     5.2 with Other Protocols.............................26
     5.1 IP Routing Interactions ...................................27
     5.2.1 ...................................26
     5.1.1   Load Sharing ..........................................27
     5.2.2   QoS Routing ...........................................28
     5.2.3   Route pinning .........................................28
     5.2.4 and Policy-Based Forwarding ..............26
     5.1.2   Route Changes .........................................28
     5.2.5
     5.1.3   Router Redundancy .....................................30
     5.3 .....................................29
     5.2 Mobility Interactions .....................................30
     5.3.1 .....................................29
     5.2.1   Addressing and Encapsulation ..........................30
     5.3.2
     5.2.2   Localized Path Repair .................................31
     5.3.3   Reservation .................................30
     5.2.3   Update on the Unchanged Path ..............32
     5.3.4 ..........................31
     5.2.4   Interaction with Mobility Signaling ...................32
     5.3.5 ...................31
     5.2.5   Interaction with Fast Handoff Support Protocols .......34
     5.4 NSIS Interacting Context Transfer .....................33
     5.3 Interactions with NATs ................................35 ....................................33
   6. Security and AAA Considerations...............................36 Signaling Applications........................................34
     6.1 Authentication ............................................36
     6.2 Authorization .............................................37
     6.3 Accounting ................................................38
     6.4 End-to-End vs. Peer Relationship Protection ...............39
   7. NSIS Application Scenarios....................................40
     7.1 NSIS and Existing Resource Signaling Protocols ............40
     7.2 NSIS Supporting Centralized QoS Resource for Quality of Service ..........................34
     6.1.1   Protocol Messages .....................................34
     6.1.2   State Management .......41
     7.3 NSIS Supporting Distributed ......................................35
     6.1.3   QoS Forwarding ........................................36
     6.1.4   Route Changes and QoS Reservations ....................36
     6.1.5   Resource Management ...........43
     7.4 NSIS for Middlebox Signaling ..............................43
     7.5 Multi-Level NSIS Interactions ......................38
     6.2 Other Signaling ................................44 Applications ..............................39
   7. Security Considerations.......................................39
   8. Open Issues...................................................45
   9. Change History................................................47
     9.1 Changes from draft-ietf-nsis-fw-00.txt ....................47
     9.2 History................................................40
     8.1 Changes from draft-hancock-nsis-fw-00.txt .................47
   Acknowledgments..................................................51
   Author's Addresses...............................................51 draft-ietf-nsis-fw-01.txt ....................40
   References.......................................................41
   Acknowledgments..................................................44
   Authors' Addresses...............................................44
   Intellectual Property Considerations.............................45
   Full Copyright Statement.........................................52 Statement.........................................46

1. Introduction

1.1 Definition of the NSIS will work on Signaling Problem

   The NSIS working group is considering protocols for signaling from an end point that follows
   information about a data flow along its path
   through in the net network.

   It is assumed that the path taken by the data flow is already
   determined by layer 3 routing network configuration and is used to
   convey information to routing protocols,
   independent of the devices signaling itself; that is, signaling to set up the signals pass through -
   routes themselves is not considered. Instead, the signaling can, for example, install soft state in the devices it
   passes through. A signaling end point could be a device simply
   interacts with nodes along the
   path, which signals for a data flow path. Additional
   simplifications are that passes the actual signaling messages pass directly
   through it. these nodes themselves; this is 'path-coupled' signaling in
   the sense described in [3], and that only unicast data flows are
   considered.

   The intention signaling problem in this sense is very similar to allow for that addressed
   by RSVP [4]. However, there are two generalizations. Firstly, the
   intention is that NSIS protocol to designs protocols that can be deployed used in
   different parts of the Internet, for different needs, without
   requiring a complete end-to-end deployment.

   There is no requirement that deployment (in particular, the per-flow information be QoS related.
   NSIS should only worry about how
   signaling protocol messages may not need to do run all the way between
   the data flow endpoints).

   Secondly, the signaling - what is intended for more purposes than just QoS
   (resource reservation). The basic mechanism to achieve this
   flexibility is to divide the signaling conveys should be opaque protocol stack into two
   layers: a generic (lower) layer, and an upper layer specific to NSIS. This document discusses
   'where' each
   signaling application. The scope of NSIS is to define both the
   generic protocol, and initially an upper layer suitable for QoS
   signaling takes place, with some discussion on 'how' similar to the corresponding functionality in RSVP. Further
   signaling can applications may be done.

1.1 considered later.

1.2 Scope and Structure of the NSIS Framework

   The scope of this document will be to provide a framework underlying requirements for where a signaling in the context of NSIS protocol are
   defined in [3]; other related requirements can be used found in [5] and deployed. It is
   [6]. This framework does not intended that NSIS
   will define an over-arching architecture for carrying out resource
   management in the Internet, nor is this intended replace or update these requirements.
   Discussions about lessons to be used as learned from existing signaling and
   resource protocols are contained in a
   detailed protocol design document. separate analysis document [7].

   The role of this framework is not about what to explain how NSIS signaling should do but
   work within the broader networking context, and how it the signaling
   protocols should do
   it. It is not intended that this places requirements on a future NSIS
   protocol, since requirements are already defined in [2]. The document be structured at the overall level. Therefore, it
   discusses important protocol considerations, such as routing,
   mobility, security, and interworking interactions with resource network 'resource'
   management (in a broad the broadest sense). Discussions about lessons

   The basic framework for NSIS is given in section 3. Section 3.1
   describes the fundamental elements of NSIS operation in comparison to be learned from existing
   RSVP; in particular, section 3.1.2 describes more general signaling
   scenarios, and resource protocols are contained in a separate analysis
   document [4].

   This initial version provides 3.1.3 defines a model broader class of signaling
   applications for which the entities NSIS protocols should be useful. The two-
   layer protocol architecture that take part supports this generality is
   described in section 3.2, and section 3.3 gives examples of the signaling. It discusses the considerations that must be taken
   into account ways
   in developing the framework, particularly which particular signaling application properties can be
   accommodated within signaling layer protocol behavior.

   The overall functionality required from the options
   for lower (generic) protocol
   layer is described in section 4. This is not intended to define the structure of such a protocol, and
   protocol detailed design or even design options, although some are
   described as examples. The emphasis is on defining the interactions interfaces
   between
   NSIS this lower layer protocol and other protocols the IP layer and functions, signaling
   application protocols, including security issues.
   Finally, it includes background material the identity elements that appear on
   these interfaces. Following this, section 5 describes how NSIS could support
   particular signaling applications.

   It is expected
   applications that future versions of this document will distill
   these structural options into a concrete technical framework, use the NSIS protocols can interact sensibly with
   network layer operations, specifically routing (and re-routing), IP
   mobility, and
   material on network address translation.

   Section 6 describes particular signaling applications and deployment
   scenarios will be moved into separate NSIS applicability statements. applications. The purpose example of this document is
   signaling for QoS (comparable to develop core RSVP QoS signaling
   functionality) is described in detail in section 6.1, which describes
   both the realms, domains signaling application specific protocol and example modes of operation where an NSIS protocol can be used; identify the
   relationship of an NSIS protocol to
   interaction with network resource management and other protocols; deployment
   aspects. However, note that these examples are included only as
   background and identify
   areas for future work. explanation; it is not intended 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

   [Editor's note: it is a matter of taste where we put this.]

   Classifier - an entity which selects packets based on their contents
   according to defined rules.

   Interdomain traffic

   [Data] flow - Traffic that passes a stream of packets from one NSIS domain sender to
   another.

   NSIS Domain (ND) receiver which is a
   distinguishable subset of a packet stream. Each flow is distinguished
   by some flow identifier (see section 4.5.1).

   Edge node - Administrative domain where an NSIS protocol
   signals for a resource or (NSIS-capable) node on the boundary of some
   administrative domain.

   Interior nodes - the set of resources. (NSIS-capable) nodes which form an
   administrative domain, excluding the edge nodes.

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

   NSIS Forwarder (NF) - NSIS Entity between a NI and NR which may
   interact with local resource management function (RMF). It also
   propagates NSIS signaling further through the network.

   NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
   network resource.

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

   NSIS Signaling Layer Protocol (NSLP) - generic term for an NSIS
   protocol component that supports a specific signaling application.
   See also section 3.1.3. 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.1.3. 3.2.1.

   Path-coupled signaling - a mode of signaling where the signaling
   messages follow a path that is tied to the data messages. See also
   section 3.2.1.

   Path-decoupled signaling - signaling with independent data and -  signaling paths. for state
   manipulation related to data flows, but only loosely coupled to the
   data path, e.g. at the AS level.

   Peer determination 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 which is receiving the data
   packets in a flow.

   Resource - something of value in a network infrastructure to which
   rules or policy criteria are first applied before access is granted.
   Examples of resources include the buffers in a router and bandwidth
   on an interface.

   Resource Management Function (RMF) - an abstract concept,
   representing the management of resources in a domain or a node.

   Sender - the node in the network which is sending the data packets in
   a flow.

   Service Level Agreement (SLA)

   Session - a service contract between a customer
   and a service provider that specifies the forwarding service a
   customer should receive.

   [NSIS] application layer flow of information for which some
   network control state information is to be manipulated or monitored
   (see section 4.5.2).

   Signaling application - the purpose of the NSIS signaling: a service
   could be QoS management, firewall control, and so on. Totally
   distinct from any specific user application.

   Traffic characteristic - a description of the temporal behavior or a
   description of the attributes of a given traffic flow or traffic
   aggregate.

   Traffic flow - a stream of packets between two end-points that can be
   characterized in a certain way.

3. Overall Framework Overview of Signaling Scenarios and Protocol Structure

3.1 Basic Fundamental Signaling Entities and Interfaces Concepts

3.1.1  NSIS Entities  Simple Network and Signaling Topology

   The NSIS protocol suite of protocols is intended envisioned to be used as a support various
   signaling control plane
   for applications that need to install and/or manipulate state
   in the variety of network resources required for network. This state is related to a data traffic across flow and is installed
   and maintained on the Internet. The most common NSIS signaling applications are QoS
   resources, firewalls and NATs resources, etc. Entities (NEs) along the data flow path
   through the network; not every node has to contain an NE. The NSIS signaling
   itself does basic
   protocol concepts do not depend on the signaling application it is used for application, but the
   details of operation and the information it carries does. carried do. This section
   discusses the basic
   signaling entities of the protocol involved with signaling as well as
   interfaces between them.

   We can identify three different roles in the NSIS signaling for
   resources: initiator, forwarder and responder.

   The NSIS Initiator (NI) is an entity that initiates NSIS signaling
   (request) for the network resource. The NSIS initiator can be
   triggered by the different "sources" - user applications, an instance
   of NSIS Forwarder, other protocols, network management etc. - that
   need network resources for a data flow. For the purpose of the

   Two NSIS
   discussion all these sources can be called "applications" (note entities that
   this is entirely distinct from the specific term "signaling
   application"). The NSIS initiator can provide feedback information communicate directly are said to
   the triggering application be in respect to the requested network
   resources. The NSIS initiator uses NSIS signaling to interact with
   other NSIS entities (NFs and NRs).

   The NSIS Forwarder (NF) is an entity that services NSIS resource
   requests from NSIS initiators and other NSIS forwarders. It may
   interact with local resource management function (RMF). How and if
   this interaction takes place depends on the deployed resource
   management mechanism and the specific role of the NF. The NSIS
   forwarder propagates NSIS signaling further through the network.

   The NSIS Responder (NR) is an entity that terminates NSIS signaling
   and can optionally interact with local applications as well e.g. for
   the purpose of notification when network resources get allocated etc.

   The signaling relationship between two NSIS entities (with no other
   NSIS entities between them) is called simply 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 session connection between themselves.

   Figure 1 depicts simplified interactions/interfaces between NI, NFs
   and NR as well as local applications and RMFs. Note that the NI and
   NR could also interact with an RMF; additionally, this could be
   modeled

   It is common to consider a network as co-location composed of NI&NF various domains,
   e.g. for administrative or routing purposes, and NR&NF. This distinction should
   have no impact on the operation of the protocol. Also,
   signaling protocols may be influenced by these domain boundaries.
   However, it seems there is no
   bar on placing reason to expect that an NI '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 NR in the interior
   several IP domains.

   Figure 1 shows a diagram of nearly the network, to
   initiate and terminate NSIS simplest possible signaling independently of the ultimate
   endpoints of
   configuration. A single data flow is running from an application in
   the end sender to end flow, the receiver via routers R1, R2 and NI R3. Each host and NR do not have to talk
   via intervening NFs. An example
   two of NSIS being used the routers contain NEs which exchange signaling messages -
   possibly in this way both directions - about the flow. This scenario is
   given in section 7.5.

   +-----------+                                        +-----------+
   |Application|                                        |Application|
   essentially the same as that considered by RSVP for QoS signaling;
   the main difference is that we make no assumptions here about the
   particular sequence of signaling messages that will be invoked.

       Sender                                               Receiver
   +-----------+      +----+      +----+      +----+      +-----------+
        ^                                                      ^
        |                                                      |
   |Application|----->| R1 |----->| R2 |----->| R3 |  |____________|                      |____________|  |
        V ---->|Application|
   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    |  V
       +----+          +----+              +----+          +----+
   | NI |==========| NF |=====....=====| NF |==========| NR   |NE|====|======||NE||======||NE||==================|===|NE|    |
       +----+          +----+              +----+          +----+
                         ^                    ^
   |   +--+    |
                         V                    V
                       +----+              +----+
                       |RMF      |+--+|      |+--+|                  |   +--+    | RMF|
   +-----------+      +----+      +----+

                   ===========                  +-----------+

      +--+
      |NE| = NSIS signaling messages

                   |_________|      ==== = Scope of single NSIS
                   |         |    "peer relationship" Signaling    ---> = Data flow messages
      +--+   Entity           Messages            (unidirectional)

                 Figure 1: Basic NI/NF/NR Relationships Simple Signaling and Data Flows

3.1.2  Placement of NSIS Entities

   The NI, NF  Signaling to Hosts, Networks and NR definitions do not make any assumptions about
   placements of Proxies

   There are different possible triggers for the NSIS signaling. Amongst
   them are signaling entities in respect to the particular
   part applications (that are using NSIS signaling
   services), other instances of the signaling, network or data-forwarding path.

   They can be located along the data path (hosts generating and
   receiving data flows, edge routers, intermediate routers etc.) but it
   may not 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.

   NSIS 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.

   While end-to-edge (host-to-network) scenario requires only one desirable location. 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 single domain or multiple concatenated NSIS domains. The latter
   case assumes the existence of the trust relation between domains.

   In some cases it is desired to be able to initiate and/or terminate
   NSIS signaling not from the end host that generates/receives sends/receives the data
   flow, but from the some other entities on the network that can be
   called NSIS signaling application proxies. There could be various reasons for this:
   signaling on behalf of the end hosts that are not
   enabled with NSIS, 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 etc. The proxy and so on. This configuration can
   communicate the relevant information to the host in
   be considered as a kind of "on the data path", see Figure 2.

                 Proxy1                         Proxy2
   +------+      +----+     +----+    +----+    +----+      +--------+
   |Sender|-...->|Appl|---->| R  |-.->| R  |--->|Appl|-...->|Receiver|
   |      |      |+--+|     |+--+|    |+--+|    +----+      |        |
   +------+      ||NE||=====||NE||=.==||NE||====||NE||      +--------+
                 |+--+|     |+--+|    |+--+|    |+--+|
                 +----+     +----+    +----+    +----+

      +--+
      |NE| = NSIS      ==== = Signaling    ---> = Data flow messages
      +--+   Entity           Messages            (unidirectional)

      Appl = signaling application
   specific, maybe compressed, form.

   Support for

                      Figure 2: "On path" NSIS proxies affects the protocol in proxy

   This configuration presents a set of specific challenges to the following way: NSIS
   signaling:

   *) The protocol should accommodate proxy that terminates signaling with on behalf of the scope NSIS-unaware
   host (or part of the network) should be able to make determination
   that it is a
   single last NSIS peer relationship; aware node along the path.
   *) Where a proxy initiates NSIS signaling could be propagated over
   multiple peer relationships all the way toward the destination (end-
   to-end).
    *) In the particular case where the proxy is not on behalf of the data path, NSIS
   unaware host, interworking with some other "local" technology might have to
   be extended required, for example to allow separated data provide QoS reservation from proxy to the
   end host in the case of QoS signaling application.

   Another possible configuration, shown in Figure 3 is where an NE can
   send and receive signaling
   paths, although information off path for and from remote
   processing. The NSIS protocols may or may not be suitable for this analysis
   remote processing but in any case it is not initially in scope.

   Further discussion currently part of these issues the
   NSIS problem. This configuration is given in sections 3.2.1 and
   3.3.3.

   As it can be seen from supported by considering the usage cases presented in NE
   as 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.5.

                                                     Receiver
   +------+      +----+      +----+      +----+      +-----------+
   |Sender|----->| PA |----->| R2 |----->| R3 | ---->|Application|
   |      |      |+--+|      |+--+|      +----+      |   +--+    |
   +------+      ||NE||======||NE||==================|===|NE|    |
                 |+--+|      |+--+|                  |   +--+    |
                 +-..-+      +----+                  +-----------+
                   ..
                   ..
                   ..
                   ..
                 +-..-+
                 |Appl|
                 +----+

            Appl = signaling         PA = Proxy for signaling
                   application            application

                      Figure 3: "Off path" NSIS
   requirements draft [2] proxy

3.1.3  Signaling Messages and Network Control State

   The distinguishing features of the NSIS signaling procedures may depend on
   the part/type of supported by the network where NSIS
   protocols are that it is used. In fact related to satisfy
   sometimes-conflicting requirements specific flows (rather than to
   network operation in [2], different procedures general), and
   possibly different kinds of that it involves nodes in the NSIS
   network (rather than running transparently between the end hosts).

   Therefore, each signaling application (upper layer) protocol can be used on
   different parts/types must
   carry per-flow information for the aspects of network-internal
   operation corresponding to that signaling application. An example for
   the network. Sections 3.2 and 7.5 provide
   more details on this topic.

3.1.3  NSIS Protocol Components

   In order to achieve a modular solution for case of an RSVP-like QoS signaling application would be state
   data representing resource reservations. However, more generally, the NSIS requirements, it
   is proposed to structure what we refer to overall as 'the NSIS
   protocol' into 2 layers, similarly
   per-flow information might be related to the original proposal some other control function
   in [8]:
    *) a 'signaling transport' layer, responsible for moving routers and middleboxes along the path. Indeed, the signaling
   messages around, which should
   might simply be independent of any used to gather per-flow information, without
   modifying network operation at all.

   We call this information generically 'network control state'.
   Signaling messages may install, modify, refresh, or simply read this
   state from network elements for particular
   signaling application; data flows. Usually a
   network element will also manage this information at the per-flow
   level, although coarser-grained state management is also possible.

3.1.4  Data Flows and
    *) Sessions

   Formally, a 'signaling application' layer, data flow is a (unidirectional) sequence of packets
   between the same endpoints which contains functionality
   such as message formats follow a unique path through the
   network (determined by IP routing and sequences, specific to other network layer
   configuration). A flow is defined by a particular
   signaling application.

   For packet classifier (in the purpose of this document,
   simple cases, just the destination address and topological origin are
   needed). In general we use assume that when discussing only the term 'NSIS Transport
   Layer Protocol' (NTLP) data flow
   path, we only need to refer consider 'simple' fixed classifiers (e.g. IPv4
   5-tuple or equivalent).

   A session is an application layer concept for a (unidirectional) flow
   of information between two endpoints, for which some network state is
   to the component that will be used in
   the transport layer; it may allocated or may not be based on the monitored. (Note that this use of
   existing transport protocols. We also use the term 'NSIS Signaling
   Layer Protocol' (NSLP) to refer generically to any protocol component
   within
   'session' is distinct from the signaling application layer; usage in RSVP. It is closer to the end, there will be
   several NSLPs. These relationships are illustrated in Figure 2.

                 ^                     +-----------------+
                 |                     | NSIS Signaling  |
                 |                     | Layer Protocol  |
          NSIS   |    +----------------| for middleboxes |
       Signaling |    | NSIS Signaling |        +-----------------+
         Layer   |    | Layer Protocol +--------| NSIS Signaling  |
                 |    |     for QoS     |       | Layer Protocol  |
                 |    |                 |       |
   session concept of, for something   |
                 |    +-----------------+       |     else        |
                 V                              +-----------------+
                      =============================================
                 ^         +--------------------------------+
                 |         | NSIS Transport Layer Protocol  |
          NSIS   |         |       ....................     |
       Transport |         |       .Standard transport.     |
         Layer   |         |       . protocol (maybe) .     |
                 |         |       ....................     |
                 V         +--------------------------------+

                    Figure 2: NSIS Protocol Components example, the Session Initiation Protocol.)

   The precise boundary between these layers is not defined at this
   stage; see section 3.3.5 for some initial discussion of this point.

3.2 Options for Modes of NSIS Operation

   This section discusses several possible modes of NSIS operation. Each
   mode of simplest service provided by NSIS operation is briefly introduced and where needed
   analyzed and compared with the alternatives. It signaling is not assumed that
   NSIS will support all network control
   state management at the mode variants flow level, as described in these
   subsections; after the tradeoffs described here have been evaluated,
   some might be excluded from further consideration.

3.2.1  Path-Coupled and Path-Decoupled Signaling

   We can consider two basic paradigms for resource reservation
   signaling, which we refer previous
   subsection. In particular, it is possible to monitor routing updates
   as "path-coupled" and "path-decoupled".

   In they change the path-coupled case, signaling messages are routed only through
   nodes (NEs) that are in path taken by a flow and, for example, update
   network state appropriately. This is no different from the data path. They do not have to reach 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-related
   ones, see [3] and [8]) it is desirable to update the nodes on flow:session
   relationship during the data path (for session lifetime. For example, there could a new flow can
   be proxies
   distinct from the sender added, and receiver as described the old one deleted (and maybe in section 3.1.2,
   or intermediate signaling-unaware nodes); and between adjacent NEs, that order, for a
   'make-before-break' handover), effectively transferring the route taken by signaling and network
   control state between data might diverge. The path-coupled
   case flows to keep it associated with the same
   session. Such updates can only be supported managed by various addressing styles, with the end systems (because
   of the packet classifier change). To enable this, it must be possible
   for end systems to relate signaling messages
   either explicitly addressed to sessions as well as
   data flows.

3.2 Layer Model for the neighbor on-path NE, or routed
   identically Protocol Suite

3.2.1  Layer Model Overview

   In order to achieve a modular solution for the data packets and intercepted. These cases are
   considered in section 3.3.4. In NSIS requirements, it
   is proposed to structure the second case, some network
   configurations may split NSIS protocol suite into 2 layers,
   similar to the signaling and data paths (see section
   5.2); this is considered an error case original proposal in [9]:
    *) a 'signaling transport' layer, responsible for path-coupled signaling.

   In the path-decoupled case, moving signaling
   messages are routed to nodes
   (NEs) around, which are not assumed to should be on the data path, but which are
   (presumably) aware independent of it. Signaling messages will always be directly
   addressed to the neighbor NE, any particular
   signaling application; and
    *) a 'signaling application' layer, which contains functionality
   such as message formats and sequences, specific to a particular
   signaling application.

   For the NI/NR may have no relation at
   all with the ultimate data sender or receiver.

   There are potentially significant differences in purpose of this document, we use the way that term 'NSIS Transport
   Layer Protocol' (NTLP) to refer to the two
   signaling paradigms should component that will be analyzed, for example in terms of
   scaling behavior, failure recovery, security properties, mechanism
   for NSIS peer determination, and so on. These differences might or
   might not cause changes used in
   the way that the NSIS protocol operates.

   The initial goal of NSIS and this framework is to concentrate mainly
   on transport layer. We also use the path-coupled case.

3.2.2  Inter-domain and Intra-domain term 'NSIS Signaling

   Inter-domain NSIS signaling is where Layer
   Protocol' (NSLP) to refer generically to any protocol component
   within the NSIS signaling messages are
   originated in one NSIS domain and are terminated application layer; in another NSIS
   domain.

   In the path-coupled case, inter-domain NSIS signaling can end, there will be used to
   signal NSIS information to
   several NSLPs. These relationships are illustrated in Figure 4. Note
   that the edge nodes of one NTLP may or more NSIS
   domains.

   In the path-decoupled case, inter-domain NSIS signaling can be used
   to signal NSIS information to entities that are may not have an interesting internal structure
   (e.g. based on the data path
   (i.e., "out-of-band" NFs), and additionally to signal from off-path
   entities to on-path edge nodes .

   NSIS inter-domain signaling has to fulfill several requirements, such
   as:
    *) Basic functionality, such as scalable, simple and fast signaling.
   Because different networks have different resource management
   characteristics, such as cost use of bandwidth and performance, this
   basic functionality may differ from one NSIS domain to another.
    *) All other requirements specified in [2].

   Intra-domain NSIS signaling existing transport protocols) but that is where the
   not relevant at this level.

                 ^                     +-----------------+
                 |                     | NSIS signaling messages are
   originated, processed and terminated within the same Signaling  |
                 |                     | Layer Protocol  |
          NSIS domain.
   Note that these messages could be handled within a local instance of   |    +----------------| for middleboxes |
       Signaling |    | NSIS signaling; another possibility could be to piggyback them on
   inter-domain Signaling |        +-----------------+
         Layer   |    | Layer Protocol +--------| NSIS messages.

   Intra-domain signaling can be used to signal Signaling  |
                 |    |     for QoS     |       | Layer Protocol  |
                 |    |                 |       | for something   |
                 |    +-----------------+       |     else        |
                 V                              +-----------------+
                      =============================================
                 ^         +--------------------------------+
          NSIS information to the
   edge nodes (i.e., routers located at the border of the   |         |                                |
       Transport |         | NSIS domain) Transport Layer Protocol  |
         Layer   |         |                                |
                 V         +--------------------------------+
                      =============================================
                           +--------------------------------+
                           |                                |
                           .      IP and to the interior nodes (i.e., routers located within the lower layers       .
                           .                                .

                    Figure 4: NSIS
   domain Protocol Components
   Note that are not edge nodes).

   The NSIS intra-domain signaling approach every generic function has to fulfill fewer
   requirements than inter-domain signaling. These are:
    *) Basic functionality, such as scalable, simple and fast signaling.
   Due to be located in the fact that different networks have different resource
   management characteristics, this basic functionality may differ from
   one NSIS domain NTLP.
   Another option would be to another.
    *) Provides have re-usable components within the necessary functionality to interact between inter-
   domain
   signaling and intra-domain signaling.

3.2.3  End-to-End, Edge-to-Edge, and End-to-Edge

   End-to-end: When used end-to-end, application layer. Functionality within the NTLP should be
   restricted to that which interacts strongly with other transport and
   lower layer operations.

   Because NSIS protocol is initiated by
   an end host and problem includes multiple signaling applications, it is terminated by another end host. In this context,
   NSIS can
   very likely that a particular NSLP will only be applied as needed within all implemented on a
   subset of the NSIS domains between
   the end hosts. In the end-to-end NSIS-aware nodes on a path, NSIS may be used both for
   intra-domain NSIS signaling, as well as shown in Figure 5.
   Messages for inter-domain signaling.

   Edge-to-edge: In this scenario unrecognized NSLPs are forwarded at the NSIS protocol is initiated by an
   edge node of a NSIS domain and is terminated by another edge node of NTLP level.

               +------+    +------+    +------+    +------+
               |  NE  |    |  NE  |    |  NE  |    |  NE  |
               |+----+|    |      |    |+----+|    |+----+|
               ||NSLP||    |      |    ||NSLP||    ||NSLP||
               ||    ||    |      |    ||    ||    ||    ||
               || 1  ||    |      |    || 2  ||    || 1  ||
               |+----+|    |      |    |+----+|    |+----+|
               |  ||  |    |      |    |      |    |  ||  |
               |+----+|    |+----+|    |+----+|    |+----+|
           ====||NTLP||====||NTLP||====||NTLP||====||NTLP||====
               |+----+|    |+----+|    |+----+|    |+----+|
               +------+    +------+    +------+    +------+

               Figure 5: Signaling with Heterogeneous NSLPs

3.2.2  Layer Split Concept

   This section describes the same (or possibly different) NSIS domain. NSIS can be applied
   either within one single NSIS domain, basic concepts which is denoted as edge-to-
   edge in a single domain, or underlie how the
   necessary functionality within the NTLP can be determined. Firstly,
   we make a concatenated number working assumption that the protocol mechanisms of NSIS
   domains, which the NTLP
   operate only between adjacent NEs (informally, the NTLP is denoted as edge-to-edge in a multi-domain. When an
   appropriate security trust relation exists between two or more
   concatenated NSIS domains, these concatenated NSIS domains 'hop-by-
   hop' protocol), whereas any larger scope issues (including e2e
   aspects) are
   considered, in terms of NSIS, left to be a single, larger NSIS domain.

   End-to-edge: In this scenario the NSIS protocol upper layers.

   The way in which the NTLP works can be described as follows: When a
   signaling message is either initiated
   by an end host and ready to be sent from one NE, it is terminated by an edge node or given to the
   NTLP along with information about what flow it is initiated by
   an edge node and for; it is terminated by an end host. In then up
   to the path-coupled
   case, NTLP to get it to the edge node may be a proxy that next NE along the path (up- or down-
   stream), where it is located on a boundary node
   of a NSIS domain. In received and the path-decoupled case, responsibility of the edge node may be a
   proxy NTLP
   ends. Note that there is located on an off-path node that controls, or no assumption here about how the messages
   are actually addressed (this is
   associated with, a NSIS domain.

3.2.4  Global protocol design issue, and Local Operation

   It the
   options are outlined in section 4.2). The key point is likely that the appropriate way to describe 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 resources NSIS receiving NE either forwards the message directly,
   or, if there is an appropriate signaling application locally, passes
   it upwards for will vary from one part of further processing; the network signaling application can then
   generate another message to another.
   In particular, resource descriptions that are valid for inter-domain
   links will probably be different from those useful for intra-domain
   operation (and sent via the latter will differ from one NSIS domain to
   another).

   One way to describe NTLP. In this issue is to consider the resource
   description objects carried by NSIS (typically within way, larger
   scope (including end-to-end) message delivery can be automatically
   achieved.

   This definition relates to NTLP operation. It is not intended to
   restrict the ability of an NSLP to send messages by other means. For
   example, an NE in the middle or end of the signaling
   application layer) path could send
   a message directly to the other end as divided in globally-understood objects ("global
   objects") and locally-understood objects ("local objects"). The local
   objects are only applicable a notification of or
   acknowledgement for intra-domain signaling, while some signaling application event. However, it
   appears that the
   global objects are mainly used issues in inter-domain signaling. Note that sending such local objects messages (endpoint discovery,
   security, NAT traversal and so on) are still part so different from the direct
   peer-peer case that there is no benefit in extending the scope of the NSIS protocol, unlike opaque
   data
   NTLP to include such non-local functionality; instead, an NSLP which would be invisible
   requires such messages and wants to avoid traversing the protocol; local objects can path of NEs
   should use some other existing transport protocol - for example, UDP
   would be
   inserted, used a good match for many of the scenarios that have been
   proposed. Acknowledgements and removed by one single domain.

   The purpose notifications of this division is to provide additional flexibility type are
   considered further in
   defining the objects carried by section 3.3.5.

   One motivation for restricting the NSIS protocol such that NTLP to only
   those objects peer-relationship
   scope is that if there are applicable any options or variants in a particular setting are used.
   An example design approach for reflecting the distinction
   - or, worse, in the signaling basic functionality - it is that local objects could be put into separate local messages that
   are initiated and terminated within one single NSIS domain and/or
   they could be "stacked" within the NSIS messages that are used for
   inter-domain signaling. These possibilities will be considered
   further during the protocol design activity.

3.2.5  Multicast versus Unicast

   Multicast support, compared easier to unicast support, would introduce a
   level of manage the
   resulting complexity into if it only impacts direct peers rather than
   potentially the NSIS protocol mainly related to:
    *) complex state maintenance whole network.

3.2.3  Core NTLP Functionality

   This section describes the basic functionality to support dynamic membership changes
   in be supported by the multicast groups, such as reservation state merging and
   maintenance.
    *) a state per flow
   NTLP. Note that the analysis has to be maintained based on considering NSLP and
   NTLP operation jointly; for example, we can always assume that an
   NSLP is used during
   backward routing.

3.2.6  Sender versus Receiver Initiated Signaling

   A sender-initiated approach is when operating above the sender NTLP and taking care of the data flow
   initiates end-to-end issues
   (e.g. recovery of messages after restarts and maintains the resource reservation used for that flow.
   In so on).

   Therefore, NTLP functionality is essentially just efficient upstream
   and downstream peer-peer message delivery in a receiver-initiated approach the receiver wide variety of
   network scenarios. Message delivery includes the data flow
   initiates and maintains the resource reservation used act of locating
   and/or selecting which NTLP peer to carry out signaling exchanges
   with for the 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 path-coupled case, and in the absence NTLP can sensibly carry out most of NSIS proxies, the
   following relationships apply:
    *) in the sender initiated case, the sender functions of the data
   enabling signaling messages to pass through middleboxes, since this
   is closely related to the NSIS
   Initiator, while the receiver problem of routing the data is the NSIS Responder;
    *) signaling messages
   in the receiver initiated case, first place.

   Two major open issues remain about NTLP functionality, namely what
   classical transport capabilities (congestion avoidance,
   retransmission and so on) it should have, or whether these functions
   can be left entirely to the receiver of upper layers; and to what extent the data NTLP
   should provide a common state management service to the signaling
   applications. These questions are discussed in section 3.4.

3.2.4  Path De-Coupled Operation

   Path-decoupled signaling is defined as signaling for state
   installation along the
   NSIS Initiator, while data path, without the sender restriction of passing
   only through nodes (NEs) that are located on the data is the NSIS Responder.
   In the path-decoupled case, the mapping is not necessarily clear cut
   (for example, if path. Signaling
   messages can be routed to NEs off the NI and NR data path, but which are not located
   (presumably) aware of it. This allows a looser coupling between NEs
   and data plane nodes, e.g. at the end systems
   themselves). AS level.

   The main differences between the sender-initiated and receiver-
   initiated approaches advantages of path-decoupled signaling are the following:
    *) Compared with the receiver-initiated approach, a sender using a
   sender-initiated approach can be informed faster when the reservation
   request is rejected. In other words, when using ease of
   deployment and support of additional functionality. The ease of
   deployment comes from a sender-initiated
   approach, restriction of the reservation request response time can be shorter number of impacted nodes
   in the case of deployment and/or upgrade of an unsuccessful reservation than with a receiver-initiated
   approach.
    *) In NSLP. It would allow, for
   instance, deploying a receiver-initiated approach, solution without upgrading any of the signaling messages
   traveling from routers
   in the receiver 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 sender must be backward routed
   such way that they follow exactly the same path as was followed by the two
   signaling messages belonging to the same flow traveling from paradigms should be analyzed. Using a single centralized
   off-path NE may increase the
   sender requirements in terms of message
   handling. This effect, however, is orthogonal to the receiver. This implies that a backward routing state
   per flow must NSIS charter,
   since path-decoupled signaling is equally applicable to distributed
   off-path entities. Failure recovery scenarios need to be maintained. When using a sender-initiated approach,
   provided acknowledgements analyzed
   differently because fate-sharing between data and notifications control plane can
   no longer be securely delivered
   to assumed. Furthermore, the sending node, backward routing is not necessary, and nodes do
   not have to maintain backward routing states.
    *) 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 interpretation of
   sender/receiver orientation becomes less obvious. With the receiver about its handover procedure, thus
   allowing local
   operation of NTLP, the receiver to initiate a reservation for these flows.
    *) Where impact of path-decoupled signaling on the
   routing of signaling messages is looking for presumably restricted to the last (nearest problem
   of peer determination. The assumption that the off-path NEs are
   loosely tied to receiver)
   NE on the data path, receiver oriented signaling is most efficient;
   sender orientation would path suggests, however, that peer
   determination can still be possible, but take more messages.

3.2.7  Uni-Directional and Bi-Directional Reservations based on L3 routing information.

3.3 Signaling Application Properties

   It is possible clear that a resource many signaling applications will only be required for one
   direction require specific
   protocol behavior in their NSLP. This section outlines some of traffic, for example the
   options for a media stream with no feedback
   channel. Reservations for both directions NSLP behavior; further work on selecting from these
   options would depend on detailed analysis of traffic may be required
   for other the application in
   question.

3.3.1  Sender/Receiver Orientation

   In some signaling applications, one end of the data flow takes
   responsibility for example requesting special treatment - such as a voice call. Therefore, resource
   reservation - from the network. The appropriate end may depend on the NSIS
   signaling protocol must allow for both uni- application, or characteristics of the network deployment.

   A sender-initiated approach is when the sender of the data flow
   requests and bi-directional maintains the resource reservations.

   The most basic method reservation used for bi-directional reservations is based on
   combining two uni-directional reservations. This allows that flow.
   In a receiver-initiated approach the
   signaling messages for one direction receiver of the bi-directional data flow
   requests and maintains the resource reservation are able used for that flow.
   The NTLP has no freedom in this area: next peers have to follow a different path from messages
   traveling be
   discovered in the opposite sender to receiver direction, which but after that time
   the default assumption is necessary for path-
   coupled that signaling in the presence of asymmetric routing. (Other more
   integrated approaches may be is possible in constrained network
   topologies where parts of the route are symmetric.) The bi-
   directional reservations can, for example, both upstream
   and downstream (unless possibly an application specifically indicates
   this is not required). This implies that backward routing state must
   be used to make maintained or that backward routing information must be available
   in the NSIS signaling procedure required after a handover procedure more
   efficient.

3.3 Basic Assumptions and Conceptual Issues

3.3.1  Basic Assumptions packet.

   The following assumptions have been made during prior NSIS
   requirements work sender and initial framework discussions. They are
   summarized here for completeness. receiver initiated approaches have several differences
   in operational characteristics. The subsequent subsections describe
   more generic conceptual assumptions and issues. Note that a complete
   overview of current open issues is contained in section 8. main ones are as follows:

   *) The solution developed by NSIS must be sufficiently flexible and
   modular that it can be efficiently deployed and used with
   functionality appropriate to In a receiver-initiated approach, the part/type of signaling messages traveling
   from the network. (Sections
   3.2.2 and 3.2.3.)

    *) The protocol developed by receiver to the NSIS working group will sender must be path-
   coupled. Considerations related to a potential path-decoupled
   solution are part of this framework, because backward routed such that
   they are also needed in
   order to co-exist with existing solutions; however, follow exactly the NSIS working
   group currently has no plans to develop path-decoupled signaling
   protocol. (Section 3.2.1.)

    *) End-to-end message routing will be achieved same path as was followed by each NE
   determining the next appropriate NSIS peer, based on signaling
   messages belonging to the same flow in
   question and information within the NTLP layer, not requiring any
   node or traveling from the upper layers sender to acquire end-to-end topology information.
   (Section 3.2.4.)

    *) Multicast support introduces a level of complexity into the NSIS
   protocol
   receiver. This implies that is not needed in support of unicast applications.
   Therefore, a working assumption is be that the NSIS protocol should
   be optimized for unicast. (Section 3.2.5.)

    *) The NSIS protocol can backward routing state per flow must be used for setup of both uni-directional
   maintained. When using a sender-initiated approach, provided
   acknowledgements and bi-directional reservations. (Section 3.2.7.)

3.3.2  NI, NF, NR functionality

   The basic functions that notifications can be fulfilled by an NSIS entity are
   request, accept, notify, modify and release of a reservation. At this
   point, it securely delivered to the
   sending node, backward routing is not clear which responsibilities can be assumed by each
   of the NSIS entities. More in particular, it is necessary, and nodes do not clear whether:
   have to maintain backward routing states.
   *) an NF In a sender-initiated approach, a mobile node can request, modify or release initiate a reservation. If it cannot,
   reservation for its outgoing flows as soon as it needs has moved to another
   roaming subnetwork. In a receiver-initiated approach, a mobile node
   has to notify inform the NI in order receiver about its handover procedure, thus
   allowing the receiver to perform initiate a reservation for these functions. flows. For
   incoming flows, the reverse argument applies.
   *) an NR can modify A sender- (receiver-) initiated approach will allow faster setup
   and release a reservation. Even modification if the NR can
   reject or accept the reservation with modification, it might still be
   required to notify the NI to signal the release or modification.

3.3.3  NI, NF, NR relationship

   An important open issue sender (receiver) is related also authorized to carry
   out the way in which NSIS entities
   maintain relations operation. A mismatch between each other. These relations could be
   purely local, where an NSIS entity only maintains relations with its
   direct neighbors (peers). In that case, messages will be sent to authorizing and
   accepted from these neighbors only. Alternatively, initiating NEs
   will cause additional message exchanges either in the relations
   between NSIS entities could have NSLP or in a more global scope.

   The type of
   protocol executed prior to NSIS peering relations invocation. Note that this may have an impact
   complicate modifications of network control state for existing flows.
   *) Where the signaling is looking for the last (nearest to receiver)
   NE on the
   complexity involved with protocol security. data path, receiver oriented signaling is most efficient;
   sender orientation would be possible, but take more messages.
   *) In case of inter-domain
   signaling, either case, the security relations are likely to initiator can generally be built between
   neighboring NSIS entities informed faster
   about reservation failures than the remote end.

3.3.2  Uni- and Bi-Directional Operation

   For some signaling applications and scenarios, signaling may only be
   considered for scalability reasons. one direction of the data flow. However, in other
   cases, there may be interesting relationships between the signaling
   for the two directions; an example is QoS for a voice call. In that the
   basic case,
   each NSIS entity will establish and maintain bi-directional signaling can simply use a security relation with
   each separate
   instance of its peers and accept only messages from these peers.

   Conversely, there the same signaling mechanism in each direction. Note that
   the path in the two directions may exist larger domains differ due to asymmetric routing.

   In constrained topologies where parts of NSIS entities that have
   a trust relationship (trusted domains). This the route are symmetric, it
   may be possible to use a more unified approach to bi-directional
   signaling, e.g. carrying the case two signaling directions in common
   messages. This optimization might be used for
   intra-domain signaling. example to make mobile
   QoS signaling more efficient.

   In this either case, an NE may accept messages from
   all other NSIS entities the correlation of the signaling for the two flow
   directions is carried out in the domain. Both alternatives need not NSLP. The NTLP would simply be
   mutually exclusive.
   enabled to bundle the messages together.

3.3.3  Heterogeneous Operation

   It is conceivable likely that different instances of the
   NSIS protocol (or different NSIS protocols) use the NSIS security
   model appropriate way to a larger or lesser extent, provided that overall security is
   not impacted. An analysis of describe the state NSIS threats is available
   signaling for will vary from [5].

   The NSIS peering relations may also have an impact one part of the network to another
   (depending on signaling application). For example in the required
   amount of state at each NSIS entity. When direct interaction with
   remote 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 NSIS peers domain to another).

   One way to address this issue is not allowed, it may be required to keep track of consider the path state description
   carried within the NSLP as divided in globally-understood objects
   ("global objects") and locally-understood objects ("local objects").
   The local objects are only applicable for intra-domain signaling,
   while the global objects are mainly used in inter-domain signaling.
   Note that an NSIS message has followed through such local objects are still part of the network. This NSIS protocol and
   can be achieved inserted, used and removed by keeping per-flow state at one single domain.

   The purpose of this division is to provide additional flexibility in
   defining the NSIS entities or objects carried by
   maintaining the NSLP such that only those objects
   that are applicable in a record route object particular setting are used. An example
   approach for reflecting the distinction in the signaling is that
   local objects could be put into separate local messages that are
   initiated and terminated within one single NSIS messages.

   An initial working domain and/or they
   could be "stacked" within the NSLP messages that are used for inter-
   domain signaling.

3.3.4  Peer-Peer and End-End Relationships

   The assumption taken 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 simply
   concatenating these relationships. Any non-local operation (if any)
   will take place only in particular NSLPs.

3.3.4  NSIS Addressing

   The are potentially two ways to establish a signaling connection by
   means of the NSIS protocol. On the one hand, peering relations may also have an impact on the required amount
   of state at each NSIS message could
   be addressed to a neighboring NSIS entity (NE) that entity. When direct interaction with remote
   peers is known to not allowed, it may be
   closer required to keep track of the destination NE. On the other hand, the NSIS path
   that a message
   could be addressed to has followed through the destination directly, and intercepted network. This can be achieved
   by an
   intervening NE. We denote keeping per-flow state at the latter approach as end-to-end
   addressing and NSIS entities or by maintaining a
   record route object in the former as peer-peer addressing.

   With peer-peer addressing, an NE will determine messages.

   Note that, for the address reasons discussed in section 3.2.1, NSLP peers are
   not inevitably NTLP peers. This has a number of implications for the
   next NE based on the payload of
   relationship between the NSIS message (and potentially
   also signaling layers, in that NSLP peers may
   depend on the previous NE). This requires the address service provided by a concatenation of the
   destination NE NTLP peer
   relationships rather than a single one, which makes it harder to be derivable from information present in the
   payload. This can be achieved through
   exploit fully some NTLP properties (e.g. channel security,
   reliability).

3.3.5  Acknowledgements and Notifications

   We are assuming that the availability of NTLP provides a local
   routing table simple message transfer
   service, and any acknowledgements or through participation in notifications it generates are
   handled purely internally (and apply within the routing protocol. Peer-
   peer addressing inherently supports tunneling scope of NSIS a single
   peer relationship).

   However, we expect that some signaling
   messages between NEs, and is equally applicable to applications will requires
   acknowledgements regarding the path-coupled
   and path-decoupled cases.

   In case failure/success of end-to-end addressing, state installation
   along the NSIS message data path, and this will be an NSLP function.

   Acknowledgements can be sent with along the address sequence of the NR, NTLP peer
   relationships towards the signaling initiator, which then necessarily needs to be on relieves the data
   path. This requires (some of)
   requirements on the data-path entities security associations that need to be upgraded
   (NSIS-aware) maintained
   by NEs and can ensure NAT traversal in order to be able to intercept the NSIS messages. The
   routing of the NSIS signaling should follow exactly the same path as
   the data flow for which the reservation both directions. (If this
   direction is requested.

3.3.5  NSIS Layer Boundaries

   The detailed boundary between towards the NTLP and NSLPs is an area for
   (considerable) further analysis. In particular, flow sender, it is not clear how
   the key issues described earlier (such as sender/receiver
   orientation) are allocated to the different layers. However, some
   initial assumptions have been made about the functionality implies maintaining reverse
   routing state in
   different layers.

   *) It is assumed that some flow description information is part of the NTLP (see section 4.3.1 and 4.5.1). This might NTLP). In certain circumstances (e.g. trusted
   domains), an optimization can be needed made by
   signaling application unaware entities located at address boundaries.
   It is not clear to which level of complexity the flow description
   needs sending acknowledgements
   directly to be available at this level.
    *) It is not assumed that the operation of an NSLP is totally
   independent of the NTLP; for example, the appropriate interpretation
   of an NSLP message might depend on the local status of the NTLP.

3.3.6  NSIS Acknowledgement and Notification Semantics signaling initiator (see section 3.2.2).

   The semantics of the acknowledgement and notification messages are of particular
   importance. An NE sending a message can 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 NSIS entity.

4. Protocol Components

4.1 Lower Layer Interfaces

   Within a signaling entity, NSIS interacts with the 'lower layers' of
   the protocol stack for two nearly independent purposes: sending and
   receiving signaling messages; and configuring point in the operation of the
   lower layers themselves.

   For sending and receiving messages, this framework places the lower
   boundary of network.

   Notifications differ from acknowledgements because they are not
   (necessarily) generated in response to other signaling messages. This
   means that it may not be obvious to determine where the NTLP at notification
   should be sent. Other than that, the IP layer. (It is possible same considerations apply as for
   acknowledgements. One useful distinction to make would be to
   differentiate between notifications that NSIS could
   use trigger a standard transport protocol above the IP layer to provide some
   of its functionality; this is discussed in section 4.3.1.) The
   interface with the lower layers is therefore very simple:
    *) The NTLP sends raw IP packets
    *) signaling action
   and others that don't. The NTLP receives raw IP packets. In security requirements for the case of peer-peer
   addressing, latter are
   less stringent, which means they have been addressed could be sent directly to it. In the case of
   end-to-end addressing, NE
   they are destined for (provided this will NE can be by intercepting packets that have
   been marked in determined).

3.3.6  Security and other AAA Issues

   In some special way (by special protocol number or cases it will be possible to achieve the necessary level of
   signaling security by
   some option interpreted within using basic 'channel security' mechanisms [10]
   at the IP layer, such as level of the Router Alert
   option [6] NTLP, and [7].)

   For correct message routing, the NTLP needs to possibilities are described in
   section 4.6. In other cases, signaling applications may have some information
   about the link specific
   security requirements, in which case they are free to invoke their
   own authentication and IP layer configuration of the local networking
   stack. For example, it needs key exchange mechanisms and apply 'object
   security' to know:
    *) [in general] how to select specific fields within the outgoing interface for a signaling
   message, in case this needs NSLP messages.

   In addition to match authentication, authorisation (to manipulate network
   control state) has to be considered as functionality above the interface that NTLP
   level, since it will be used
   by the corresponding flow. This might entirely application specific. Indeed,
   authorisation decisions may be as simple as just allowing
   the IP layer handed off to handle a third party in the message using its own routing table.
    *) [in
   protocol (e.g. for QoS, the case of IPv6] what address scopes resource management function as described
   in section 6.1.5). Many different authorisation models are associated possible,
   and the variations impact
   *) what message flows take place - for example, whether authorisation
   information is carried along with a control state modification
   request, or is sent in the
   interfaces that messages reverse direction in response to it;
   *) what administrative relationships are sent required - for example,
   whether authorisation takes place only between peer signaling
   applications, or over longer distances.

   Because the NTLP operates only between adjacent peers, and received places no
   constraints on (to interpret
   scoped addresses the direction or order in flow identification, if which signaling applications
   can send messages, these authorisation aspects are left open to be allowed).

   The way
   defined by each NSLP. Further background discussion of this issue is
   contained in which [11].

3.4 Open Layer Model Issues

3.4.1  Classical Transport Functionality

   The first major issue is the lower layers are actually configured extent to handle which the flow depends on NTLP should include
   'traditional' transport like functions, or whether these should be
   seen as either fundamentally unnecessary or automatically handled by
   the particular NSIS signaling application; for
   example, if NSIS is being used for QoS signaling, this might involve
   configuration of traffic classification and conditioning parameters,
   for example local packet queues, type of filters, type of scheduling,
   and so on. However, none of this is directly related upper layers. The following functions have been identified as
   candidates:

   1. Local retransmission to improve reliability. The argument in favor
   is that the NTLP can recover from congestive loss or
   indeed any NSLP; therefore, this interaction corruption much
   more rapidly than end-to-end (NSLP) mechanisms; the argument against
   is handled indirectly
   via a resource management function, as described that the additional complexity in section 5.1.

4.2 Upper Layer Services

   The combination of the NTLP and an NSLP provides a signaling service,
   appropriate is not needed for a particular signaling application. We can describe
   such a all
   signaling service as an abstract set of capabilities, provided
   at a service interface, defined from three perspectives:

    *) What basic control primitives are available at applications. (It's assumed that the interface;
    *) What information NTLP is exchanged not actually
   providing perfect message delivery guarantees or notifications, for
   example because NSLP peers may be separated by more than one NTLP
   peer relationship. A signaling application that needs peer-peer
   acknowledgements of this nature should define them within these primitives;
    *) What assumptions the NSLP.)
   In-order message delivery and duplicate detection are made about operations carried out above related
   functions.

   2. Congestion control. Here, the
   interface.

   The set of control primitives required question is quite small.
   At whether the initiating (NI) end:
    *) Signaling application requests signaling for NTLP should
   include a new resource;
    *) Signaling application requests modification or removal common mechanism which protects the local portion of an
   existing resource.
    *) Signaling application receives progress indications (minimally,
   success the
   network from overload, or failure).
   At whether this can be derived from the responding (NR) end:
    *) Notification to
   behavior of each signaling application application.

   3. Message fragmentation. For NSLPs that a resource has been
   set up.
   At either end:
    *) Notification generate large messages, it
   will be necessary to signaling application that something has changed
   about the available resource fragment and other error conditions.

   This description is in terms of a 'hard state' interface, without
   explicit refresh messages between re-assemble them efficiently within
   the signaling application and NSIS,
   although this is an implementation issue. In any case,
   implementations will need network, where the use IP fragmentation may lead to reduced
   reliability and be able to detect conditions when
   instances of signaling applications fail without issuing explicit
   resource removal requests.

   The information in incompatible with some addressing schemes. (It's
   assumed that the control primitives consists essentially counterpart functionality, of two
   parts. The first is bundling small
   messages together, can be provided locally by the definition NTLP as an option
   if desired; it doesn't affect the operation of the data flow for which network
   elsewhere.)

   4. Flow control. Here, the
   resource is being signaled. The format (e.g. socket id or packet
   fields or whatever) question is an implementation issue; it has to be
   interpreted into how a 'wire format' (as in section 4.5). Since NSIS
   could support both sender and receiver initiation, receiving NSLP should be
   protected from overload - whether the NTLP should provide a flow
   definition must also state whether it is incoming
   controlled channel, or outgoing over a
   particular interface (this can whether this should be inferred when the initiator is
   colocated with the flow endpoint). The second part of managed using
   application layer acknowledgements, for example.

   It appears that all these issues don't affect the information
   exchanged is basic way in which
   the service definition NSLP/NTLP layers relate to each other (e.g. QoS description in terms of the case
   semantics of the inter-layer interaction); it is much more a QoS request). This will be opaque at least to question
   of the NTLP, which
   only knows overall performance/complexity tradeoff implied by placing
   certain functions within each layer.

3.4.2  State Management

   It is clear that the specific NSLP being used.

   We NTLP may have a basic design goal not to duplicate functionality that is
   already present in (or most naturally part of) existing signaling
   protocols which could be used by the upper layers. Therefore NSIS
   (implicitly) assumes that certain procedures are carried out
   'externally'. The main aspects of this are:
    *) Negotiation of service configuration (e.g. discovering what
   services are available to be requested);
    *) Agreement manage some per-flow state to use NSIS
   carry out its message delivery functions (for example, state about
   the reverse route for signaling, signaling messages, or state needed for route
   change detection). How this state is stored and coordination of which
   end will be managed is an
   internal matter for the initiator.

   In addition, as well as NSIS (presumably NTLP (see section 4), and the NTLP) providing a
   'native' capability details (in
   particular, any connection model it might use) is in any case
   entirely invisible to determine the peer to carry out signaling
   with, applications.

   However, signaling applications are frequently managing network
   control state for their own purposes, and it is possible that this information could be provided from
   some external source (which might be helpful in some access
   scenarios, or in the path-decoupled case). See also an open issue how
   much the security
   discussion in section 6.

   Actually providing these functions might require enhancements NTLP should provide a common service to
   these other protocols. These do this for them.

   The simplest case is that the NTLP simply delivers messages, and any
   state-related aspects (lifetimes, message semantics and so on) are still
   entirely invisible to be identified.

4.3 Protocol Structure

4.3.1  Internal Layering

   We can model NSIS in two layers, as shown in Figure 3. it, being part of the signaling application
   data. This provides the simplest interface between NTLP and NSLP.

   The other extreme is
   initially just where the NTLP provides a way complete state
   management service, including explicit commands for creation,
   modification and deletion of grouping associated functionality, and does
   not mean that all these layers state with known lifetimes in remote
   nodes. This service could necessarily operate or even be
   implemented independently.

                    ..................................
                    .     Signaling Application      .
                    .        (section 4.2)           .
                    .                                .
                    +--------------------------------+
                    | NSIS Signaling Layer Protocol  |
                    |  (for some specific signaling  |
                    |          application)          |
                    |                                |
                    +--------------------------------+
                    | NSIS Transport Layer Protocol  |
                    |      ....................      |
                    |      .Standard transport.      |
                    |      . protocol (maybe) .      |
                    |      ....................      |
                    +--------------------------------+
                    .     Interface make it easy to IP layer      .
                    .         (section 4.1)          .
                    .                                .
                    ..................................

                      Figure 3: NSIS Layer Structure

   The lower layer interface (to IP) has been described in section 4.1.
   The support of the write new signaling application is as described in section
   4.2. The degree of independence between the NTLP and NSLP is unclear
   and might depend on
   applications, at the particular signaling application. To make cost of increasing the
   NTLP independent complexity of the signaling application, we must allow that
   NSLPs could
   NTLP/NSLP interface; in particular, there would be explicitly dependent on the layer below. This is
   similar many more events
   and error conditions to generate within the ALSP/CSTP coupling described in [8].

   The distinction between the NTLP NTLP, and any 'Standard Transport
   Protocol' is not functionally clear cut, but one there may be
   several different types of convenience. In
   outline:
    *) state management semantics required by
   different signaling applications. The 'standard' protocol could provide (at most) commonality with other parts of
   NTLP functionality
   which might be available from existing protocols, such as SCTP [9] or
   IPSec [10]. is not clear.

   An extreme intermediate case could be is where there is particular support for the binding update
   refresh messages used for soft-state maintenance. The characteristics
   of
   mobility these messages are that they can be sent and processed without
   invoking signaling (section 5.3.4).
    *) The NTLP provides (at least) functionality which is somehow application specific to path-coupled signaling.

   Functionality reasonable to re-use from existing protocols might
   include reliability and re-ordering protection, dead peer detection
   (keepalive), multihoming support, payload multiplexing
   (piggybacking), logic, and security services, such as establishment of
   security contexts and carrying out key exchange.

   Functionality which would probably have that their timing
   can be manipulated to fit in with other NTLP requirements (e.g.
   jittering to avoid network synchronization, or to allow bundling with
   other messages). Therefore, provided this functionality can be
   defined simply and universally, there may be benefits in supporting
   it within the NTLP itself. The implication would
   include flow and reservation identification, be that some error handling,
   demultiplexing between different NSLPs, as well as possibly NTLP
   messages contain timing and other control information (to allow the basic
   NSIS messages. More details on
   refresh to be handled correctly at intermediate NSLP-unaware nodes).
   In addition, the messages are in section 4.3.2 automatic generation and reception of refreshes
   could be handled above or below the identifier aspects in section 4.5. NSLP/NTLP boundary (this seems to
   be mainly an API issue).

4. The choice of using NSIS Transport Layer Protocol

   This section describes the overall functionality required from an existing protocol or re-
   specifying it as part of the NTLP is for further analysis.
   NTLP.  It
   probably depends on mentions possible protocol components within the function in question, NTLP layer
   and in the end might different possible addressing modes that can be
   left flexible to allow optimization to local circumstances. (For
   example, Diameter allows utilized.
   The interfaces between NTLP and the use layers above and below it are
   identified, with a description of IPSec for security services, but
   also includes its own CMS application as an alternative.) Whichever
   approach the identity elements that appear
   on these interfaces.

   It is taken, not the combination intention of this discussion to design the NTLP and supporting transport
   protocol must or even
   to discuss design options, although some are described as examples.
   The goal is to provide a uniform protocol capability general discussion of required functionality
   and to highlight some of the NSLPs
   which support the actual signaling applications.

4.3.2 issues associated with this.

4.1 Internal Protocol Messages Components

   The NSIS protocols will include a set of messages to carry out
   particular operations along NTLP includes all functionality below the signaling path. Initial work for RSVP
   concentrated on the particular case of QoS signaling, although application
   layer and above the
   implication of IP layer. The functionality that is required
   within the analysis in [8] NTLP is that this message set
   generalizes to a wide variety of signaling applications described in section 3.2.

   Some NTLP functionality could be provided via components existing as
   sublayers within the NTLP design.  For example, if specific transport
   capabilities are required, such as congestion avoidance,
   retransmission, security and so we use
   it on, then existing protocols, such as a starting point. (A very similar set of messages was generated
   in [11].) However, in principle, the necessary basic messages
   TCP or TLS, could
   depend on be incorporated into the signaling application that NTLP. This possibility is
   not required or excluded by this framework.

                ====================      ===========================
             ^  +------------------+      +-------------------------+
             |  |                  |      | NSIS Specific Functions |
             |  |                  |      |            .............|
      NSIS   |  |    Monolithic    |      |+----------+.   Peer    .|
   Transport |  |     Protocol     |      || Existing |. Discovery .|
     Layer   |  |                  |      || Protocol |.  Aspects  .|
             |  |                  |      |+----------+.............|
             V  +------------------+      +-------------------------+
                ====================      ===========================

                   Figure 6: Options for NTLP Structure

   If peer-peer addressing (section 4.2) is being used for,
   which means that we are not specific here about whether these
   messages are visible for some messages, then
   active next-peer discovery functionality will be required within the
   NTLP or only NSLP.

   Note that the 'direction' column in the table below only indicates to support the 'orientation' explicit addressing of the message. The messages can be originated and
   absorbed at NF nodes as well these messages. (This
   could use message exchanges for dynamic peer discovery as a sublayer
   within the NI or NR; an example might NTLP; there could also be NFs
   at the edge of an interface to external
   mechanisms to carry out this function.)

4.2 Addressing

   There are two ways to address a domain exchanging signaling message being transmitted
   between NSIS messages peers:
    *) peer-peer, where the message is addressed to set up resources
   for a flow across a it.

   Note neighboring NSIS
   entity that is known to be closer to the working assumption destination NE.
    *) end-to-end, where the message is addressed to the destination
   directly, and intercepted by an intervening NE.

   With peer-peer addressing, an NE will determine that responder as well as address of the initiator
   can release a reservation (comparable
   next NE based on the payload of the message (and potentially on the
   previous NE). This requires the address of the destination NE to rejecting it in be
   derivable from the first
   place). It is left open if information present in the responder payload.  This can modify be
   achieved through the availability of a reservation,
   during local routing table or after setup. This seems mainly a matter through
   participation in active peer discovery message exchanges.  Peer-peer
   addressing inherently supports tunneling of assumptions
   about authorization, messages between NEs, and
   is equally applicable to the possibilities might depend on resource
   type specifics.

   +-------+---------+---------------------------------------------+
   | Name  |Direction|                  Semantics                  |
   +-------+---------+---------------------------------------------+
   |Request| I-->R   |     Create a new reservation for a path-coupled and path-decoupled cases.

   In the case of end-to-end addressing, the message is addressed to the
   data flow     |
   +-------+---------+---------------------------------------------+
   |Modify | I-->R   |        Modify an existing reservation       |
   |       |(&R-->I?)|                                             |
   +-------+---------+---------------------------------------------+
   |Release| I-->R & |  Delete (tear down) an existing reservation |
   |       |  R-->I  |                                             |
   +-------+---------+---------------------------------------------+
   |Accept/| R-->I   |  Confirm (possibly modified?) or reject a   |
   | Reject|         |             reservation request             |
   +-------+---------+---------------------------------------------+
   |Notify | I-->R & |     Report an event detected within the     |
   |       |  R-->I  |  network (e.g. congestion condition or end  |
   |       |         |                of condition)                |
   +-------+---------+---------------------------------------------+
   |Refresh| I-->R   |      State management (see section 4.4)     |
   +-------+---------+---------------------------------------------+

   The table also explicitly includes a refresh message. This does
   nothing to a reservation except extend its lifetime, receiver, and is one
   possible state management mechanism for NSIS. This is considered in
   more detail in section 4.4.

4.4 State Management (some of) the NEs along the data path
   intercept the messages.  The prime purpose routing of NSIS is to manage state information along the messages should follow
   exactly the same path taken by a as the associated data flow. There two critical flow (but see section
   5.1.1 on this point). Note that securing messages sent this way
   raises some interesting security issues to be considered (these are discussed in building a robust protocol to handle this problem:
    *) The protocol must be scalable.
   [12]).

   It should minimize is not possible at this stage to mandate one addressing mode or
   the state
   storage demands that it makes on intermediate nodes; other. Indeed, each is necessary for some aspects of NTLP
   operation: in particular,
   storage initial discovery of state per 'micro' flow is likely to be impossible except
   at the very edge of next downstream
   peer will usually require end-to-end addressing, whereas reverse
   routing will always require peer-peer addressing. For other message
   types, the network.

    *) The choice is a matter of protocol must be robust against failure and other conditions,
   which imply that design. The mode used is
   not visible to the stored state has to be moved or removed.

   The total amount of state that has to be stored depends both on NSIS NSLP, and on the specific signaling application information needed in use. The signaling
   application might require per flow or lower granularity state;
   examples of each for the case of QoS would be IntServ is
   available from the flow identifier (section 4.5.1) or RMD (per
   'class' state) respectively. locally stored
   NTLP state.

4.3 Lower Layer Interfaces

   The NSIS protocol should not overburden
   an application that was otherwise lightweight in state requirement.
   However, depending on design details, it might require storage of
   per-flow state including reverse path peer addressing, simply for
   sending NSIS messages themselves.

   There are several robustness problems, which roughly align NTLP interacts with the
   'layers' of the NSIS protocols 'lower layers' of Figure 3, that can be handled by the soft state principle. (Independence of these layers therefore
   implies protocol stack for the danger
   purposes of duplication of functionality.) sending and receiving signaling messages. This relies on
   periodic refresh of framework
   places the state information with lower boundary of the current context,
   relying on invalid state being timed out. Soft state can be used
   either as NTLP at the primary mechanism IP layer. The interface
   to handle the problem, or sometimes
   as a backup to some other approach. lower layer is therefore very simple:
    *) At The NTLP sends raw IP packets
    *) The NTLP receives raw IP packets. In the lowest level, soft state can be used to detect dead NSIS
   peers - loss of several periodic messages implies termination case of peer-peer
   addressing, they have been addressed directly to it. In the
   signaling. (The same inference can case of
   end-to-end addressing, this will be made e.g. if failure is
   detected at the link layer.) The assumption is then achieved by intercepting packets
   that have been marked in some special way (by special protocol number
   or by some option interpreted within the
   corresponding reservation should be automatically deleted, and the
   deletion propagated along the remainder of IP layer, such as the path. Router
   Alert option [13] and [14]).
    *) At the next level, in The NTLP receives indications from the event of a routing change (for example
   caused by network IP layer regarding route
   changes or end host mobility), reservation state
   should be removed from and similar events (see section 5.1).

   For correct message routing, the old path NTLP needs to have some information
   about link and added IP layer configuration of the local networking stack.
   For example, it needs to know:
    *) [in general] how to select the new one. This outgoing interface for a signaling
   message, in case this needs to match the interface that will be handled automatically used
   by periodic messaging, provided that the entities on corresponding flow. This might be as simple as just allowing
   the new path accept a Refresh message IP layer to install a
   new reservation. (A partial alternative handle the message using its own routing table. There
   is no intention to have a routing-aware
   NSIS implementation, if 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 route change takes place at an NSIS-aware
   node.) NTLP processing must
   account for this.
    *) At [in the highest level, a particular signaling application might
   have timing limits case of IPv6] what address scopes are associated with a particular reservation (e.g.
   credit limited network access). Periodic re-authorized requests can
   be used as part of the time control.

   All of
   interface that messages are sent and received on (to interpret scoped
   addresses in flow identification, if these can are to be handled with a single soft state mechanism,
   although it may be hard allowed).

   Configuration of lower layer operation to choose a single refresh interval and
   message loss threshold appropriate handle flows in particular
   ways is handled by the signaling application.

4.4 Upper Layer Services

   The NTLP offers transport layer services to higher layer signaling
   applications for all of them. Even where
   alternative approaches two purposes: sending and receiving signaling
   messages, and exchanging control and feedback information.

   For sending and receiving messages, two basic control primitives are possible, for example using knowledge of
   required:
    *) Send Message, to allow the fact that a routing change has occurred signaling application to pass data to trigger an explicit
   release message, it seems that a soft state mechanism is always
   necessary as a backup.

4.5 Identity Elements

   NSIS will carry certain identifiers within
   the NTLP. The most
   significant identifier needs seem NTLP for transport.
    *) Receive Message, to be allow the following.

4.5.1  Flow Identification NTLP to pass received data to the
   signaling application.

   The flow identification is a method of identifying a flow in a unique
   way. All packets and/or messages NTLP and signaling application may also want to exchange other
   control information, such as:
    *) Signaling application registration/de-registration, so that are associated
   particular signaling application instances can register their
   presence with the same
   flow will transport layer. This may also require some
   identifier to be identified by agreed between the same flow identifier. In principle, it
   could be a combination of NTLP and signaling application to
   allow support the following information (note that this
   is not an exclusive list exchange of further control information that could be used for flow
   identification):
    *) source IP address;
    *) destination IP address;
    *) protocol identifier and higher layer (port) addressing; to
   allow the de-multiplexing of incoming data.
    *) flow 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.

    *) Error messages, to allow the NTLP to indicate error conditions to
   the signaling application and vice versa.
    *) Feedback information, such as route change indications so that
   the signaling application can decide what action to take.

   The exact form of the primitives used across this interface and the
   information exchanged by them depends on a decision about what the
   responsibility of the layers is either side of the interface, and
   where state is managed (see section 3.4.2).

4.5 Identity Elements

4.5.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 that 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:
    *) source IP address;
    *) destination IP address;
    *) protocol identifier and higher layer (port) addressing;
    *) flow label (typical for IPv6);
    *) SPI field for IPSec encapsulated traffic; data;
    *) DSCP/TOS field
   It is assumed that wildcarding on these identifiers is not needed
   (further analysis may be required).

   We've assumed here that the flow identification is not hidden within
   the NSLP, but is explicitly part of the NTLP. The justification for
   this is that it might be valuable to be able to do NSIS processing
   even at a node which was unaware of the specific signaling
   application; this would be a case of
   application (see section 3.2.1): an NSIS forwarder with no
   interface to any resource management function. An example scenario would be NSIS
   messages passing through an addressing boundary where the flow
   identification had to be re-written.

   The very flexibility possible in flow classification is a possible
   source of difficulties: when wildcards or ranges

4.5.2  Session Identification

   There are included, circumstances where it is
   probably unreasonable to assume a standard classification capability
   in routers; on the other hand, negotiating this capability would be a
   significant protocol complexity.

4.5.2  Reservation Identification

   There are several circumstances where it is important important to be able to refer to a reservation
   signaling application state independently of whatever other information is
   associated with it. The prime example is a mobility-induced the underlying flow.
   For example, if the address
   change (handover) which required of one of the flow identifier associated with endpoints changes due
   to a reservation mobility event, it is desirable to be rewritten able to change the flow
   identifier without installing having to install a totally completely new
   reservation (see section 5.3.1 for some security and scoping
   implications of this use). reservation.

   The same capability could also be used session identifier provides a method to
   simplify refresh or release messages in some circumstances, and might
   be useful within correlate the protocol to resolve reservation collisions
   (where both sender and receiver initiate for signaling
   about the different flows with the same flow).

   A reservation network control state.

   The session identifier performs these roles. It is open how the
   reservation identifier space should be defined and managed, and what
   the scope of the identifier 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 (only peer-peer, or end-end,
   when interpreted in conjunction with some of the addressing
   information). Some of visible within the necessary identifier functions, especially NTLP. This enables it to do with local operation of NSIS, may also be provided used to
   control NTLP behavior, for example, by lower controlling how the transport
   layer should forward packets belonging to this session (as opposed to
   this signaling transport protocols.

4.5.3  NSLP Identification

   Since application).  In addition, the NTLP session identifier can
   be used by the NTLP to support several NSLPs, there demultiplex received signaling messages
   between multiple instances of the same signaling application, if such
   an operational scenario is a need
   to supported (see section 4.5.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 which 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 use for this purpose.

4.5.3  Signaling Application Identification

   Since the NTLP can be used to support several NSLP types, there is a
   need to identify which one type a particular NSIS signaling message exchange
   is being used for: for.  This is to support:
    *) processing of incoming messages at a responder - the NTLP should be able to
   demultiplex these towards the appropriate signaling
   application; applications;
    *) processing of general NSIS 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 the
   upper layer information.

   Signaling

   No position is taken on the form of the signaling application identifiers would probably require an IANA
   registry.

5. NSIS Protocol Interactions

   So far as possible,
   identifier, or even the NSIS protocol structure of the signaling application
   'space' - free-standing applications, potentially overlapping groups
   of capabilities, etc. These details should be usable in isolation,
   without explicitly depending on other protocols to operate. However,
   in many cases, NSIS functionality overlaps with not influence the problem spaces rest of
   other protocols. In order
   NTLP design.

4.6 Security Properties

   It is assumed that the only security service required within NTLP is
   channel security. Channel security requires a security association to determine
   be established between the boundaries signaling endpoints, which minimize
   any explicit interdependencies, these protocol interactions must be
   analyzed.

   This is different from considering the use of NSIS protocols carried out
   via some authentication and key management exchange. This
   functionality could be provided by reusing a standard protocol.

   In order to
   support protect a particular signaling application, or example configurations
   in which exchange, the NSIS might be deployed. These subjects are discussed in
   section 7.

5.1 Resource Management Interactions

   The NSIS protocol is used for signaling resource requests from an
   NSIS Initiator entity
   needs to an NSIS Responder. The NSIS protocol should be
   useful for many signaling applications, but should not be involved select the security association that it has in
   any specific resource allocation or management techniques. As such,
   we need to define place with
   the interaction between an next NSIS entity and what we that will call be receiving the Resource Management Function (RMF). signaling message.
   The RMF is
   responsible for all resource provisioning, monitoring and assurance
   functions in ease of doing this depends on the network.

   The RMF may interact with NSIS entities addressing model in two different ways: as a
   client or as a server.

   First, use by the RMF
   NTLP (see section 4.2).

   Channel security can act as a client towards the NSIS protocol, as a
   particular application triggering NSIS signaling for resources in the
   network. This is a special case provide many different types of general NSIS triggering protection to
   signaling exchanges, including integrity and will replay protection and
   encryption.  It is not be elaborated here. This case could for instance apply with
   multi-level NSIS signaling (section 7.5).

   Second, clear which of these is required at the RMF NTLP
   layer, although most channel security mechanisms support them all.

   Channel security can act as a server towards the NSIS protocol. In
   that case, also be applied to the signaling decision taken by messages with
   differing granularity, i.e. all or parts of the NF signaling message may depend on
   be protected.  For example, if the
   content or processing flow is traversing a NAT, only the
   parts of the NSIS payload.

   The RMF may or may message that do not need to be co-located with processed by the NSIS protocol
   processing. To cater for both cases, we define a (possibly logical)
   NF-RMF interface, see Figure 4. (As mentioned in section 3.1.1, the
   NI and NR could also interact with an RMF. Note that this could also NAT
   should be modeled protected. It is an open question as co-location to which parts of the NI&NF
   NTLP messages need protecting, and NR&NF. This distinction
   should have no impact on the operation what type of protection should be
   applied to each.

5. Interactions with Other Protocols

5.1 IP Routing Interactions

   The NSIS Transport Layer (NTLP) is responsible for discovering the protocol.) Over this
   interface, information may
   next node to be provided from visited by the RMF about monitoring,
   resource availability, topology, configuration, and so on.
   Additionally, resource provisioning requests may signaling protocol. For path-coupled
   signaling, this next node should be issued towards the RMF. Note one that will be visited by
   the actual implications for NSIS data flow. In practice, this peer discovery will be approximate,
   as a protocol are
   the same, regardless any node could use any feature of whether the RMF is centralized or
   distributed, since NSIS sees the same interface towards the RMF in
   each case.

           +----+   NSIS   +----+   NSIS    +----+   NSIS   +----+
           | NI |==========| NF |====...====| NF |==========| NR |
           +----+          +----+           +----+          +----+
                              ^                ^
                              |                |
                              V                V
                           +----+           +----+
                           | RMF|           | RMF|
                           +----+           +----+

                   Figure 4: Basic NSIS-RMF Relationship

   One way peer discovery packet to formalize
   route it differently than the interface corresponding data flow packets.
   Divergence between the NF data and signaling path can occur due to load
   sharing or load balancing (section 5.1.1). An example specific to the RMF
   case of QoS is via given in section 6.1.1. Route changes cause a Service Level Agreement (SLA).
   temporary divergence between the data path and the path on which
   signaling state has been installed. The SLA may be static or it may be
   dynamically updated by means occurrence, detection and
   impact of a negotiation protocol. Such a
   protocol route changes is outside the scope described in section 5.1.2. A description
   of NSIS.

5.2 IP Routing Interactions

   Several situations may occur when routing diverges from standard
   layer 3 routing. These are summarized this issue in the sections below.

5.2.1 context of QoS is given in section 6.1.2.

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. The significance of load sharing in
   the context of NSIS is that, if the load sharing mechanism in use
   will forward packets on any basis other than source and the destination address,
   routing of NSIS messages using end-to-end addressing does not guarantee
   that the messages will follow the data path. In this
   section, we briefly survey what standard methods have been used Policy-based forwarding
   for
   load sharing within standard routing protocols. 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 flow packets may diverge because of these
   techniques. In OSPF, load balancing can be used between equal cost
   paths [12] [15] or unequal cost paths. An example of the latter approach
   is Optimized Multi Path (OMP). OMP discovers multiple paths, not
   necessarily equal cost paths, to any destinations in the network, but
   based on the load reported from a particular path, it determines
   which fraction of the
   traffic data to direct to the given path. Incoming
   packets are subject to a (source, destination address) hash
   computation, and effective load sharing is accomplished by means of
   adjusting the hash thresholds. BGP [13][14] [16][17] advertises the routes
   chosen by the BGP decision process to other BGP speakers. In the
   basic specification, routes with the same Network Layer reachability
   information (NLRI) as previously advertised routes implicitly replace
   the original advertisement, which means that multiple paths for the
   same prefix cannot exist. Recently, however, a new mechanism was
   defined that will allow the advertisement of multiple paths for the
   same prefix without the new paths implicitly replacing any previous
   ones [15]. [18]. The essence of the mechanism is that each path is
   identified by an arbitrary identifier in addition to its prefix.

   The distribution of traffic over

   If the available path routing decision is based on both source and destination
   address, signaling and data flow packets may be done per
   destination, per message in a round-robin fashion or with a
   predefined hashing function. The determination still diverge because of
   layer 4 load-balancing (based on TCP/UDP or port-based). Such
   techniques would, however, constrain the hashing image
   may take into account use of proxies. Proxies
   would cause ICMP errors to be misdirected to the source/destination IP address, QoS
   information such as source of the DSCP or protocol ID. When data
   because of source address spoofing.

   If the routing decision is no longer based on the destination address only, however,
   there is a risk that data plane messages and control plane messages
   will not follow complete five-tuple,
   divergence may still occur because of the presence of router alert
   options. In this case, the same route.

5.2.2  QoS Routing

   The are several proposals constraint on proxy use applies as
   above. Additionally, it becomes difficult for the introduction of end systems to
   distinguish between data and signaling packets. Finally, QoS awareness in
   the routing protocols. All of these essentially lead to
   techniques (section 6.1.3) may base the existence routing decision on any field
   in the packet header (e.g. DSCP, ...).

   Most load-balancing techniques use the first n bytes of multiple paths (with different QoS) towards the same destination.
   As such, they also contain an inherent risk for a divergence between
   control plane packet
   header (including SA, DA and data plane, similar to protocol field) in the load sharing case.

   For intra-domain traffic, hashing function.
   In this case, the difference in routing may result from a
   QoS-aware traffic engineering scheme, that e.g. maps incoming traffic
   to LSPs above considerations regarding source/destination
   address or five-tuple based on multi-field classification. forwarding apply.

5.1.2  Route Changes

   In BGP, several
   techniques for including QoS information in the routing decision are
   currently proposed. A first proposal a routed network, each packet is independently routed based on its
   header information. Whenever a newly defined
   BGP-4 attribute, better route towards the QoS_NLRI attribute [16]. The QoS_NLRI attribute destination
   becomes available, this route is an optional transitive attribute that can installed in the forwarding table
   and will be used to advertise a
   QoS route to for all subsequent (data and signaling) packets.
   This can cause a peer or to provide QoS information in divergence between the path along with which state has
   been installed and the
   Network Layer Reachability Information (NLRI) in a single BGP update.
   A second proposal is based on controlled redistribution path along which forwarding will actually take
   place.

   The possibility of AS routes
   [17]. It defines a new extended community (the redistribution
   extended community) that allows a router to influence how a specific route should be redistributed towards a specified set of eBGP
   speakers. The types changes requires the presence of redistribution communities may result three
   processes in a
   specific route not being announced to a specified set of eBGP
   speakers, that it should not be exported or that the signaling protocol
   1. route should be
   prepended n times.

5.2.3  Route pinning

   Route pinning refers to change detection
   2. installation of state on the independence new path
   3. teardown of state on the old 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). This independence may for instance

   Many route change detections methods can be caused by the
   configuration used, some of static LSPs or by which need
   explicit protocol support and some of which are implementation-
   internal. They differ in their speed of reaction and the establishment types of explicitly
   routed LSPs by means
   change they can detect. In rough order of increasing applicability,
   they can be summarized as:
   a) monitoring changes in local interface state
   b) monitoring network-wide topology changes in a signaling link-state routing
   protocol (RSVP-TE or CR-LDP). If
   the NSIS
   c) inference from changes in data packet TTL
   d) inference from loss of packet stream in a downstream flow-aware
   router
   e) inference from changes in signalling packet TTL
   f) changed route of a PATH-like (end-to-end addressed) signaling messages follow standard Layer 3 routing, this may
   cause
   packet
   g) changed route of a divergence between control plane and data plane. If
   reservations specific end-to-end addressed probe packet

   There are made on the control plane, this may result essentially three ways in
   sending which detection can happen: based
   on network monitoring (method a-b), based on data along an unreserved path while maintaining a reservation packet monitoring
   (method c-d) and based on monitoring signaling protocol messages
   (method e-g). Methods contingent on monitoring signaling messages
   become less effective as refresh reduction techniques are used.

   When a path route change has been detected, it is important that state is not used.

5.2.4  Route Changes

   In this section, we will explore
   installed as quickly as possible along the expected interworking between a
   signaling for resource BGP routing updates, although new path. It is not
   guaranteed that the new path will be able to provide the same applies
   for any source
   characteristics that were available on the old path. In order to be
   able to avoid duplicate state installation or, worse, rejection of routing updates. The normal operation
   the signaling message because of previously installed state, it is
   important to be able to recognize the NSIS
   protocol will lead new signaling message as
   belonging to an existing session. In this respect, we distinguish
   between route changes with associated change of the situation depicted flow
   specification (e.g. in Figure 5, where the
   reserved resources match case of a mobility event when the data path.

                    reserved +----+  reserved  +----+
                     ------->| NF |----------->| NF |
                             +----+            +----+
                  =====================================
                                data path

                 Figure 5: Normal NSIS protocol operation

   A IP source
   might change) and route changes without change (triggered by a BGP routing update for instance) can
   occur while such a reservation is of the flow
   specification (e.g. in place. In case of RSVP, a link failure along the
   route change will be path). The
   former case requires an identifier independent from the flow
   specification.

   When state has been installed immediately and any data that is sent
   will be forwarded on along the new path. This situation is depicted
   Figure 6.

                           Route update
                                |
                                v
                    reserved +----+  reserved  +----+
                     ------->| NF |----------->| NF |
                             +----+            +----+
                     ========== |
                             || |           +----+
                             || +---------->| NF |
                             ||             +----+
                             ============================
                               data path

                          Figure 6: Route Change

   Resource reservation path, the existing state
   on the new old path will only needs to 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) removed. With the data path. To minimize soft-state principle,
   this time interval
   several techniques could be considered. As an example, RSVP [18] has will happen automatically because of the concept lack of local repair, where refresh
   messages. Depending on the router refresh timer, however, it 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 required
   to tear down this
   option may not be available for NSIS if no per-flow state much faster (e.g. because it is kept in
   the NF.

   It is not guaranteed tied to an
   accounting record). In that case, the new path will teardown message needs to be
   able to provide the
   same guarantees that were available on the old path. Therefore, in a
   more desirable scenario, the NF should wait until resources have been
   reserved on distinguish between the new path before installing and the route change. old path.

   The
   route change procedure then consists problem of the following steps:
    1. NF receives route changes would not occur if there was a way to do
   route announcement,
    2. Refresh messages are forwarded along pinning. Route pinning refers to the current path,
    3. A copy independence of the refresh message is remarked as request and send
   along the new path that was announced,
    4. When the NF has been acknowledged about the reservations on the
   new path the route will be installed and the traffic will flow along
   the new path.

   Another example related to route
   taken by certain data packets from reachability changes is denoted as severe
   congestion and is explained in [19]. This solution adapts to a route
   change, when a route change creates a congestion on the new routed
   path.

5.2.5 caused by
   routing updates from an Interior Gateway Protocol (OSPF, IS-IS) or an
   Exterior Gateway Protocol (BGP).

5.1.3  Router Redundancy

   In some environments, it is desired to provide connectivity and per
   flow or per class resource flow management with high-availability
   characteristics, i.e. with rapid transparent recovery even in the
   presence of route changes. This may involve interactions with the
   basic protocols which are used to manage the routing in this case,
   such as VRRP [20]. [19]. A future version of this document may consider
   interactions between NSIS and such protocols in support of high
   availability functionality.

5.3

5.2 Mobility Interactions

   Mobility, in most cases, causes changes to the data path that packets
   take.  Assuming that signaling has taken place prior to any mobility
   to establish some state along the data path, new signaling may be
   needed in order to (re)establish state along the changed data path.

   The interactions between mobility and resource signaling protocols have been
   extensively analyzed in recent years, primarily in the context of
   RSVP and Mobile IP interaction (e.g. [21]), [20]), but also in the context
   of other types of network (e.g. [22]). [21]). This analysis work has shown
   that some difficulties in the interactions are quite deep
   seated deeply rooted in
   the detailed design of these protocols; however, the problems and
   their possible solutions fall under five broad headings. The main issue is to limit
   issues for a resource signaling application are limiting the period
   after handovers during for which the resource state has states are not been installed on
   available along the path, in particular path; and avoiding double reservations -
   reservations on both the old path and new part of the path.

   We can use this work as the starting point for considering the
   framework aspects Similar issues may
   apply to other types of a new signaling protocol like NSIS, which will
   need to interwork with mobility signaling, from Mobile IP to mobility
   paradigms based on micromobility or application layer approaches.

5.3.1 application.

5.2.1  Addressing and Encapsulation

   A mobility solution typically involves address reallocation on
   handover (unless a network supports per host routing) and may involve
   special packet formats (e.g. the routing header and Home Address
   option of MIPv6). Since NSIS may depend on end system addresses for
   forwarding signaling messages and defining flows (section 4.5.1), the
   special implications of mobility for addressing need to be
   considered. Examples of possible approaches that could be used to
   solve the addressing and encapsulation problem are as follows:
    *)

   * Use a flow identification based on low level IP addresses (e.g. the
   Care of Address) and other 'standard' fields in the IP header. This
   makes least demands on the packet classification engines within the
   network. However, it means that even on a part of the flow path
   which that
   is unchanged, the reservation session will need to be modified to reflect the
   changed flow identification (see section 5.3.3).
    *) 5.2.3).

   * Use a flow identification that does not change (e.g. based on Home
   Address); this is the approach assumed in [23]. [22]. This simplifies the
   problem of reservation session update, at the likely cost of considerably
   complicating the flow identification requirements.

   In the first approach, to prevent double reservation, NSIS nodes entities
   need to be able to recognize that a reservation session with the new flow
   identifier is to be correlated with an existing one. The reservation A session
   identifier (section 4.5.2) was introduced could be used for exactly this purpose.
   Note that this would require This is why the reservation session
   identifier as described in section 4.5.2 has to have
   (secure) end to end significance. (An additional optimization here
   would be use a local mobility management scheme to localize the
   visibility of end-to-end
   semantics.

   While the address change.)

   The feasibility and performance of this first approach needs to
   be assessed, including a detailed analysis of the signaling scenarios
   after a handover. However, given the high impact of requiring more sophisticated
   packet classifiers, initially it still seems more plausible than the second
   approach. This implies that the NSIS
   initiator signaling applications should define
   flows in terms of real real, routable (care of) addresses rather than
   virtual (home) addresses. Thus, it would have detailed
   access to lower layer interface configuration (cf. section 4.1),
   rather than operating as a pure application level daemon as is
   commonplace with current RSVP implementations.

5.3.2

5.2.2  Localized Path Repair

   In any mobility approach, a handover will cause at least some changes
   in the path of upstream and downstream packets. At some point along
   the joined path, an NSIS needs entity should be able to install
   new recognize this
   situation, based upon session identification. New state needs to be
   installed on the new path, and remove it on removed from the old. Provided that
   some NSIS node on the joined path - Who triggers the crossover router - can
   recognize this situation (which again depends on reservation
   identification),
   new state installation and teardown can be done locally
   between it and the mobile node. (This may have implications for be constrained by which entities are allowed to generate carry
   out which message types, see section
   4.3.2). It seems that the basic NSIS framework already contains the
   fundamental components necessary for this. state manipulations, which is then a signaling application
   question.

   A critical point here is the signaling that is used to discover the
   crossover router. node. This is a generalization of the problem of finding
   next-NSIS-hop nodes:
   next-NSIS peer: it requires extending the new path over several hops
   until it intersects the old one. This is easy for the uplink traffic
   direction (where the mobile is the sender), but much harder for
   downlink
   traffic without signaling via the correspondent. There is no reason
   for the crossover routers node for uplink and downlink flows to be the same,
   even for the same correspondent. The problem is discussed further in [24].

5.3.3  Reservation
   [23].

5.2.3  Update on the Unchanged Path

   On the path between the crossover router(s) node(s) and the correspondent, it
   is necessary to avoid, if possible, double reservations, but rather
   to update the reservation network control state to reflect new flow
   identification
   (if this (this is needed, which is by the default assumption of section
   5.3.1).
   5.2.1). Examples of approaches that could be used to solve this
   problem are the following:

   *) Use a reservation session state definition identification that does not change even if
   the flow definition changes (see Section 4.5.2). In this case this
   problem Signaling is solved.
    *) Use signaling all the way still
   needed to the correspondent node (receiver end
   host), accepting the additional latency that this might impose. update a changed flow identification, but it should be
   possible to avoid AAA and admission control processing.

   *) Use an NSIS-capable crossover router that manages this
   reservation update
   autonomously (more efficiently than the end
   nodes), nodes could), with
   similar considerations to the local path repair case.

5.3.4

   Note that in the case of an address change, end to end message
   exchanges will be required at the application layer anyway, so
   signaling to update the flow identifier does not necessarily add to
   the handover latency.

5.2.4  Interaction with Mobility Signaling

   In existing work on mobility protocol and resource signaling protocol
   interactions, several framework proposals describing the protocol
   interactions have been made. Usually they have taken existing
   protocols (Mobile IP and RSVP respectively) as the starting point; it
   should be noted that an NSIS protocol might operate in quite a
   different way. In this section, we provide an overview of how these
   proposals would be reflected in framework of NSIS. The mobility
   aspects are described using Mobile IP terminology, but are generally
   applicable to other network layer mobility solutions. The purpose of
   this overview is not to select or prioritise any particular approach,
   but simply to point out how they would fit into our framework and any
   major issues with them.

   We can consider that two signaling processes are active: mobility
   signaling (e.g. binding updates or local micromobility signals) and
   NSIS. NSIS signaling. The discussion so far considered how
   NSIS signaling should operate. There is still a question of how the
   interactions between the NSIS and mobility signaling should be
   considered.

   The basic case of totally independent specification and
   implementation seems likely to lead to ambiguities and even
   interoperability problems (see [23]). [22]). At least, the addressing and
   encapsulation issues for mobility solutions that use virtual links or
   their equivalents need to be specified in an implementation-neutral
   way.

   A type of 'loose' integration is to have independent protocol
   definitions, but to define how they trigger each other - in
   particular, how the mobility protocol triggers NSIS to send sending of
   refresh/modify/tear messages. A pair of implementations could use
   these triggers to improve performance, primarily reducing latency.
   (Existing RSVP modification modifications consider the closer interaction of
   making the RSVP implementation mobility-routing mobility routing aware, e.g. so it is
   able to localize refresh signaling; this would be a self contained
   aspect of NSIS.) This information could be developed for NSIS by analyzing
   message flows for various mobility signaling scenarios as was done in [21].
   [20].

   An even tighter level of integration is to consider a single protocol
   carrying both mobility and resource network control state information.
   Logically, there are two cases:

   1.  Carry mobility routing information (a 'mobility object') in the
   resource
   signaling messages, as is done in [23]. [22]. (The prime purpose in this
   approach is to enable crossover router discovery.)

   2.  Carry resource signaling in the mobility messages, typically as a new
   extension header. This was proposed in [25] [24] and followed up in [26]; [27] [25];
   [26] also anticipates this approach. In our framework, we could
   consider this a special case of NSIS layering, with the mobility
   protocol playing the role of the signaling transport (as
   in 4.3.1).
   The usefulness of this class of approach depends on a tradeoff
   between specification simplicity and performance. Simulation work is
   under way to compare the performance of the two approaches in the
   case of RSVP and micromobility protocols. transport.

   Other modes of interaction might also be possible. The critical point
   with all these models is that the general solutions developed by NSIS
   should not depend fundamentally on the choice be independent of any particular mobility protocol. Especially if it has interdomain scope, tight protocols. Tight integration would
   have major deployment issues (even loose
   integration could require NSIS implementations to hook into multiple
   different mobility protocols). especially in interdomain cases.
   Therefore, any tightly integrated solution should be is considered out of scope
   of initial NSIS
   development, and even in the long term is probably only applicable if
   it can be localized within a particular part of the network.

5.3.5 development.

5.2.5  Interaction with Fast Handoff Support Protocols Context Transfer

   In the context of mobility between different access routers, it is
   common to consider performance optimizations in two areas: selection
   of the optimal access router to handover to, and transfer of state
   information between the access routers to avoid having to regenerate
   it in the new access router after handover. The seamoby working group Seamoby Working Group
   is developing solutions for these protocols for pure IP based
   networks (CARD[28] (CARD [27] and CT[29] Context
   Transfer [28] respectively); other networks, which
   use NSIS for resource signaling within the network, may use different
   types of solution.

   In this section, we consider how NSIS should interact alternative approaches with these
   functions, however they similar
   characteristics are implemented. Detailed also possible.

   As these solutions are not
   proposed, but the way in which interaction these functions still underdevelopment, it is seen
   within premature to
   specify details on the NSIS framework interaction.  It is described. thought that Context
   Transfer transfers state between access routers based upon changes
   caused by mobility.  NSIS should be able to
   operate independently of these protocols. However, significant
   performance gains could be achieved if they could protocol state may be made to
   cooperate. In addition, the resource signaling aspects of these
   protocols could profitably use a common set of resource types and
   definitions, since they candidate for
   context transfer.  Such work, should it be undertaken, will probably be supporting done
   in the same overall
   signaling application.

   The question arises, what Seamoby working group.

5.3 Interactions with NATs

   Because at least some messages will almost inevitably contain address
   and possibly higher layer information as payload, we must consider
   the mode of interaction should be:
   independent operation, NSIS triggering access router discovery and
   state transfer, or vice versa. The questions with address translation devices (NATs). As well as
   'traditional' NATs of various types (as defined in [29]) very similar
   considerations would apply to some IPv4/v6 transition mechanisms such
   as SIIT [30].

   In the simplest case of an NSIS unaware NAT in the signaling path,
   payloads will be uncorrected and the signaling will be for the two cases seem
   incorrect flow. Applications could attempt to be independent.

   For access router discovery, a typical model use STUN [31] or
   similar techniques to detect and recover from the presence of operation is that the
   mobile carries out an information gathering exercise about
   NAT. Even then, NSIS protocols would have to use a range of
   capabilities. In addition, where those capabilities relate purely well known
   encapsulation (TCP/UDP/ICMP) to avoid being dropped by the more
   cautious low-end NAT devices.

   A simple 'NSIS-aware' NAT would require flow identification
   information to be in the AR clear and mobile, there not integrity protected. An
   alternative conceptual approach is no role for NSIS (its special to consider the NAT functionality is not relevant). However, considering resource
   aspects, one aspect
   being part of message processing itself, in which case the AR 'capability' is resource availability
   translating node can take part natively in any NSIS protocol security
   mechanisms. Depending on the path between it and the correspondent, and NSIS should protocol layering, it would be able
   to fulfill this part. Indeed, possible
   for this processing to be done in an NSIS entity which was otherwise
   ignorant of any particular signaling applications. This is effectively precisely the
   application considered
   motivation for including basic flow identification information in [26], where it the
   NTLP (section 4.5.1).

   Note that all of this discussion is a sort independent of special case the use of
   resource signaling during handover.

   Therefore, a possible model
   specific NSLP for general control of access router discovery/NSIS
   relationship NATs (and firewalls). This is that some entity
   considered in a candidate AR triggers NSIS
   using resource and reservation information (including reservation id)
   from section 6.2.

6. Signaling Applications

   This section describes NSLPs for particular signaling applications.
   The assumption is that the current AR to find out about what would be available on NSLP uses the
   new path. Note that this should be a query rather than an actual
   reservation; this semantic could be included either in generic functionality of the
   NTLP or
   NSLP.

   The given earlier; this section describes specific aspects of NSLP
   operation.

6.1 Signaling for Quality of Service

   In the case of state transfer signaling for QoS, all the basic NSIS concepts of
   section 3.1 apply. In addition, there is more complex. There are two obvious
   options, corresponding to whether an assumed directionality of
   the signaling process, in that one transfers just end of the signaling
   application state or NSIS state as well:
    1. "State transfer triggering NSIS": A state transfer process passes flow takes
   responsibility for actually requesting the 'raw' resource state resource. This leads to
   the new AR. This triggers following definitions:
   *) NSIS Initiator (NI): the signaling entity which makes the resource
   request, usually as a new instance result of user application request.
   *) NSIS to request Responder (NR): the signaling entity that resource.
    2. "NSIS using state transfer": NSIS transfers its own state
   information from acts as the old to
   endpoint for the new AR. It signaling and can then carry out optionally interact with
   applications as well.
   *) NSIS Forwarder (NF): the
   same update signaling as though it was a single 'virtual AR' entity an NI and NR which
   had just had a topology change towards the correspondent. (This is
   essentially
   propagates NSIS signaling further through the conceptual model network.
   Each of these entities will interact with a resource management
   function (RMF) which actually allocates network resources (router
   buffers, interface bandwidth and so on).

   Note that there is no constraint on which end of [21].)

   The first model is simpler, and maybe more in line with the basic
   state transfer expectation; however, it seems hard to avoid double
   reservations since signaling flow
   should take the two NSIS protocol instances are not
   coordinated. Therefore, Initiator role: with respect to the second model seems more appropriate. An
   advantage data flow
   direction it could be at the sending or receiving end.

6.1.1  Protocol Messages

   The QoS NSLP will include a set of messages to carry out resource
   reservations along the 'virtual AR' model signaling path. A message set for the QoS NSLP
   is that it ensures shown below (a very similar set of messages was generated in
   [32]). Note that the
   impact 'direction' column in the table below only
   indicates the 'orientation' of the interaction is limited to message. The messages can be
   originated and absorbed at NF nodes as well as the NSIS instances NI or NR; an
   example might be NFs at ARs
   themselves, since the rest edge of the network must be able a domain exchanging messages to handle
   set up resources for a
   topology change anyway. flow across a it.

   Note that there is an open issue of who is responsible between the
   mobile and AR to decide working assumption that responder as well as the state transfer procedures have not
   happened for whatever reason - e.g. because they were not even
   implemented - and take recovery action initiator
   can release a reservation (comparable to have rejecting it in the mobile refresh
   reservations promptly. first
   place). It appears this has to be an NSIS
   responsibility in is left open if the AR, and probably requires responder can modify a custom notification
   message for this circumstance.

5.4 NSIS Interacting with NATs

   Because at least some NSIS messages will almost inevitably contain
   address and possibly higher layer information as payload (see section
   4.5.1), we must consider the interaction between NSIS and address
   translation devices (NATs). As well as 'traditional' NATs of various
   types (as defined in [30]) very similar considerations would apply to
   some IPv4/v6 transition mechanisms such as SIIT [31].

   In the simplest case of an NSIS unaware NAT in the signaling path,
   payloads will be uncorrected and the signaling will be for the
   incorrect flow. Applications could attempt to use STUN [32] or
   similar techniques to detect and recover from the presence of the
   NAT. Even then, NSIS would have to use a well known encapsulation
   (TCP/UDP/ICMP) to avoid being dropped by the more cautious low-end
   NAT devices.

   A simple 'NSIS-aware' NAT would require flow identification
   information to be in the clear and not integrity protected. An
   alternative conceptual approach is to consider the NAT functionality
   being part of NSIS message processing itself, in which case the
   translating node can take part natively in any NSIS security
   mechanisms. Depending on NSIS layering, it could be possible for this
   processing to be done in an NSIS node which was otherwise ignorant of
   any particular NSIS signaling applications.

   Note that all of this discussion is independent of the use of NSIS
   for general control of NATs (and firewalls). This is considered in
   section 7.4.

6. Security and AAA Considerations

   A framework is meant to create boundaries for a later protocol and to
   describe the interaction between the protocol and its environment.
   Security issues usually turn out to have impacts in the interaction
   of these protocols and must therefore be appropriately addressed in
   such a framework. This section describes these general security
   issues, and in particular considers the interactions between NSIS and
   authentication, authorization and accounting. Together with
   authentication the protection of the signaling messages is addressed
   - namely replay and integrity protection.

   An initial analysis of the major security threats that apply in the
   typical of scenario where NSIS is expected to be used is given in
   [5]; these threats are described at the overall scenario level, in
   terms of the impact on users and networks. However, in any given
   scenario, NSIS will be just one part of the overall solution.
   Ultimately, the framework will need to define which of these threats
   need to be handled by NSIS (and which parts of NSIS) and which by the
   other components. Currently, we can only make initial scoping
   assumptions of this sort.

6.1 Authentication

   Authentication and key establishment for a signaling protocol should
   be seen as a two-phase process. The first-phase is usually more
   performance intensive because of a larger number of roundtrips,
   denial of service protection, cross-realm handling, interaction with
   other protocols and the likely larger cryptographic computation
   associated with it. As stated in section 4.3, this functionality
   could be provided externally to NSIS, e.g. by reusing a standard
   protocol which already included this functionality.

   At the end of this phase it should be possible to create or derive
   security associations that are usable for the protection of the NSIS
   signaling messages themselves. The functionality required here
   relates to (data origin) authentication (including integrity and
   replay protection) of individual signaling messages. Key
   establishment, rekeying, synchronization issues are issue that may be
   addressed here depending on the specific method. In any case the
   protection applied to each signaling message must be fast and
   efficient.

   When using cryptography to protect signaling messages, it is obvious
   that a node must be able to select the appropriate security
   association in order to be able to apply signaling message
   protection. This should just be a general point about endpoint
   identity issues. Hence the identifier must be available to the
   transmitting node. Regarding identities there is a need to support
   different identity types to enable the flexible usage of several
   signaling initiators and receivers. Supporting static configuration
   and dynamic learning of these identities should be provided.

6.2 Authorization

   Authorization information can be seen in an abstract form as "Can the
   resource requestor be trusted to pay for the reservation?". This
   abstraction is supported by the fact that reservations require some
   form of incentive to use some 'default' resource (or vice versa -
   penalty for not reserving too many resources). In general, the
   semantics of the authorisation will depend on the signaling
   application in use. The implication of this is that NSIS will not
   directly make authorisation decisions; instead, the authorisation
   information must be fed into the resource management function
   (section 5.1) which actually decides on the request.

   Some negotiation needs to take place to determine which node will
   take responsibility for authorising a resource request, the
   implication being that the same node will ultimately be accounted to
   for it. Such a negotiation needs to be flexible enough to support
   most currently deployed schemes (e.g. reverse charging, etc.) while
   keeping efficiency and simplicity in mind. This negotiation might be
   executed before starting resource signaling (assumed in section 4.2),
   although it could also be part of the NSIS signaling messages (as in
   some proposals dealing with charging and RSVP). Since information
   needs to be sent to the networks, some information needs to be
   included to provide the network with the necessary information to
   start the authorisation process. Hence fully opaque objects might not
   always be the proper choice.

   It is not clear if 'initiation' of a reservation is related to
   willingness to accept authorisation responsibility. (Current
   practices tend to assume that flow originators are responsible.) In
   any case, it seems unlikely that a domain will make a cost-incurring
   request of a peer domain without already having received a matching
   request from the peer in the other direction - in other words,
   requests must propagate between domains in the same direction as
   authorisation responsibility.

   If this argument is correct, and if NSIS initiation and authorisation
   responsibility are decoupled, it must be possible for the
   authorisation responsibility to propagate both in the direction
   initiator->responder and vice versa. Also, if both [flow] sender and
   receiver initiation are possible, service descriptions must include
   information about the authorisation policy to be applied, which must
   be imposed consistently along the whole path. These issues should be
   analyzed to determine if 1, 2 or 4 alternative scenarios are possible
   and realistic.

   A second question is that of which entities actually authorise which.
   One end user must ultimately get authorisation for the request (this
   may or may not be assumed to be the NSIS initiator, see below). There
   are then two possible models for how this authorisation is done
   throughout the path.

   The first model assumes that each network along the path is able to
   authenticate and authorise the user directly. The implication for a
   signaling protocol is that the user credentials cannot be removed
   after the first hop and have to be further included in the message
   when forwarded to other networks. Every node along the path is then
   able to verify the user and to provide policy based admission
   control.

   The second model assumes that the user credentials are removed at the
   first hop. The first network knows the user identity requesting the
   resources but does not include this information further along the
   path. The first network can therefore be seen as acting on behalf of
   the originator to take responsibility to enable further reservations
   to be done along the path i.e. in particular to the next network
   only. This procedure is then applied on a hop-by-hop basis.

   Note that both models are independent of whether a traditional
   subscription based approach or an alternative means of payment (such
   as pre-pay on on-line charging by the visited network) is used. These
   issues only have an impact for the transmission of accounting records
   and for a requirement to execute an online verification whether a
   user still has sufficient credits/funds; therefore, these details do
   not affect NSIS operation.

6.3 Accounting

   It is obvious that accounting/charging is an important part for the
   success and the acceptance of a resource signaling protocol. Most of
   the thinking in this area is derived from the specific case of
   signaling for QoS; however, we make an initial working assumption
   that the same paradigm should apply to any signaling application for
   which accounting is necessary. We make the general assumption here
   that accounting records are generated by the resource management
   function based entirely on traffic measurements and processed in
   accordance with the authorisation information that was used in
   deciding to grant the request in the first place.

   Therefore, NSIS plays no further part in this activity; the
   accounting records are transmitted using the AAA infrastructure, and
   charging and billing for the overall service is carried out at some
   higher layer. This would include feedback to applications (and users)
   about total session cost (of which the network resource cost might be
   only a part). An open issue is whether a query (without actually
   making a reservation) to the network should also generate a
   chargeable event; this could be considered as an aspect of the
   service definition.

6.4 End-to-End vs. Peer Relationship Protection

   It is reasonable to assume that peer relationship security (with
   chain-of-trust) is used for most signaling environments relevant to
   NSIS. Especially the separation of signaling into different network
   parts (intra-domain within the access network, end-node to access
   network, intra-domain, and so on) and new proposals regarding
   mobility and proxy support show that traditional end-to-end signaling
   is not applicable in every environment (or possibly only in a minor
   number of environments). End-to-end security in a signaling protocol
   is actually problematic for two reasons:

    1. Even if the messages use the address of the end-host (to support
   routing), the messages still have to be interpreted and modified
   along the path.

    2. The only property that can be achieved by using end-to-end
   security is that one end-host can be assured that the other end-host
   included some parameters (possibly resource parameters) that have not
   been modified along the path. Nodes along the path usually do not
   have the possibility to cryptographically verify the protected
   message parts. If the two end-points negotiate which side has to pay
   for the reservation (or possibly how much and other parameters)
   within the signaling protocol then there is a need to protect this
   information. This leads to the question which protocols are executed
   before the signaling message exchange starts. If resource parameters
   and payment/charging related information are already exchanged
   beforehand as part of a separate protocol (possibly SIP) then there
   is little need to protect (and possibly retransmit) this information
   at the NSIS level basis. In most cases an opaque token to link the
   different protocols may be sufficient.

7. NSIS Application Scenarios

   This section considers various application scenarios or deployment
   configurations for NSIS. Our goal is that an NSIS protocol designed
   according to the framework presented in the previous sections should
   be able to support these scenarios if implemented appropriately;
   therefore, this section does not form part of the framework
   definition, but rather provides examples of how NSIS can be used to
   do something interesting. In the long term, some of this material may
   be contained in specific NSIS applicability statements.

7.1 NSIS and Existing Resource Signaling Protocols

   It is hoped that NSIS could eventually achieve widespread use for
   resource signaling. However, it is bound to have to inter-operate
   with existing resource signaling protocols at least during transition
   and possibly long term. The prime example for QoS is RSVP, although
   other proprietary or domain specific protocols (e.g. bandwidth broker
   related) may also be considered. A related issue is that NSIS will be
   only one part of the solution: it will always need to interwork with
   other resource-related protocols (e.g. COPS).

   Analyzing the constraints on NSIS that come from these requirements
   is hard before further refinement of the framework has been carried
   out and critical assumptions pinned down. However, we can identify
   various modes of interoperation, and the attributes of the framework
   that will make them easy.

   Firstly, we allow for NSIS use over a 'long range', in conjunction
   with a different protocol locally (e.g. intra-domain); or, the two
   roles could be reversed. This is actually very similar to the case of
   use of NSIS layered over itself (section 7.5). In the case where the
   'inter-layer' interaction is mediated via resource management, the
   same should approach should work with non-NSIS protocols. What needs
   to be validated here is whether NSIS layering requires the exchange
   of NSIS specific information between the layers.

   A second issue is that NSIS should be deployable within an
   environment without radical changes to supporting resource (or AAA)
   related protocols. The main issue here is that NSIS should be
   flexible in its ability to support different service definitions (and
   possibly flow classifications). This is already one of the main goals
   of the framework presented here.

   The final point is that it should be possible to use NSIS over one
   network region, concatenated with another protocol over an adjacent
   region. The main issue here, apart from the flexible service and flow
   capabilities already mentioned, is that NSIS should be adaptable in
   what it assumes about signaling paths (e.g. to interwork with both
   path-coupled and decoupled solutions), and in initiation paradigms
   (e.g. to interwork with sender and receiver initiated solutions).

7.2 NSIS Supporting Centralized QoS Resource Management

   One area of application for the NSIS protocol is for QoS resource
   reservation and provisioning. The NSIS protocol may be used to
   provide intra-domain or inter-domain QoS bandwidth reservation setup
   by means of its interaction with the RMF. In what follows we assume
   that the NEs are colocated with an admission control entity that has
   a logical (abstract) view on the resources managed by the RMF, as
   described in section 5.1.

   The NEs in a domain can interface with an RMF managing the complete
   domain, in which case, the abstract topology view provided between
   NSIS and RMF can be formalized as a Service Level Agreement (SLA).
   This situation is depicted schematically in Figure 7.

             +----+   NSIS     +-----+    NSIS     +----+
             | NI |============| NF  |=============| NR |
             +----+            +-----+             +----+
                                  |
                                  | SLA
                                  |
                               +------+
                               | RMF  |
                               +------+

       Figure 7: Resource Reservation using RMF as a Server to NSIS

   In case of centralized RMF, the SLA or its technical part, the
   Service Level Specification (SLS) [33] specifies the resource
   guarantees that the RMF needs to provide to the NF. These guarantees
   apply between one or more ingress and egress points of the network.
   The SLS also specifies the availability and reliability of the
   service. In the case of QoS signaling, it may refer to a bandwidth
   service with certain performance guarantees regarding delay, jitter
   or packet loss. The SLS interface can be automated by means of an SLS
   negotiation protocol. This allows for more dynamical SLS
   modifications and the exchange of notification messages with the NF.
   These can for instance be used to provide monitoring feedback from
   the RFM to the NF.

   The decoupling of NSIS signaling and network management by means of
   an SLS has some attractive properties:
    *) It allows a Network Provider to easily share the use of its
   infrastructure between several Service Providers using NSIS signaling
   to provide their service.
    *) It allows a clear separation between resource provisioning and
   management and reservation signaling and admission control.
    *) It relieves the NF from several tasks, making it potentially more
   scalable in the core of the network.

   The NF can perform either per-flow or per-class admission control
   decisions based on the requested QoS information and on the
   reservation state it keeps regarding active flows (or classes).
   Keeping per-flow state may be required for policing,
   accounting/billing and explicit reservation teardown. These functions
   are mandatory in the access or edge of the network. Conveniently,
   this is also where the processing needed to maintain per-flow state
   will remain manageable. In the core, this approach may not scale very
   well and per-class state may be used as an alternative that is very
   scalable and allows for a lightweight processing of signaling
   messages. With per-class state, however, we lose the ability to
   directly notify the NI in case of unsolicited network events because
   the affected flows cannot be identified. Instead, the NI needs to be
   indirectly notified in response to a refresh message which in turn
   mandates the use of soft-state with separate messages or message
   structure for requests and refreshes.

   The RMF can execute its network provisioning functions according to
   its internal policies. In the easiest case, it may run an
   overprovisioned network with only monitoring capabilities in order to
   follow up on the delivered performance. In more complex scenarios, it
   may use a whole array of network optimization tools in order to
   deliver and maintain service quality according to the SLS. reservation,
   during or after setup. This may
   require network monitoring, the installation and use seems mainly a matter of appropriate
   protection mechanisms assumptions
   about authorization, and providing feedback regarding actual traffic
   performance to the NSIS entity.

   Alternatively, the NSIS protocol may be used for possibilities might depend on resource
   provisioning. In that case, the RMF acts as
   type specifics.

      +-------+---------+---------------------------------------------+
      | Name  |Direction|                  Semantics                  |
      +-------+---------+---------------------------------------------+
      |Request| I-->R   |     Create a client towards the NSIS
   protocol, as new reservation for a particular "application" triggering flow     |
      +-------+---------+---------------------------------------------+
      |Modify | I-->R   |        Modify an NI for
   resources in the network. This situation is depicted in Figure 8.

                               +------+
                    +----------| RMF  |----------+
                   /           +------+           \
                  /                                \
                 /                                  \
                /                                    \
             +----+   NSIS     +-----+    NSIS     +----+ existing reservation       | NI |============| NF  |=============| NR
      |
             +----+            +-----+             +----+

                 Figure 8: NSIS for Resource Provisioning

   In this case the RMF is providing traffic classification and
   conditioning functions. An example of such functionality is described
   in [34]. The packet "classifiers" select the packets in       |(&R-->I?)|                                             |
      +-------+---------+---------------------------------------------+
      |Release| I-->R & |  Delete (tear down) an existing reservation |
      |       |  R-->I  |                                             |
      +-------+---------+---------------------------------------------+
      |Accept/| R-->I   |  Confirm (possibly modified?) or reject a traffic
   stream based on the content of some portion of   |
      | Reject|         |             reservation request             |
      +-------+---------+---------------------------------------------+
      |Notify | I-->R & |     Report an event detected within the packet header.     |
      |       |  R-->I  |                    network                  |
      +-------+---------+---------------------------------------------+
      |Refresh| I-->R   |      State management (see section 4.4)     |
      +-------+---------+---------------------------------------------+

   The
   traffic "conditioner" performs metering, shaping, policing,
   scheduling and/or re- marking of packets to ensure that the traffic
   entering table also explicitly includes a node conforms refresh message. This does
   nothing to a certain predefined policy.

7.3 NSIS Supporting Distributed Resource reservation except extend its lifetime, and is one
   possible state management mechanism (see next section).

6.1.2  State Management

   Section 7.2 described the situation where

   The prime purpose of NSIS is supporting a
   centralized RMF. This section introduces to manage state information along the situation where NSIS is
   supporting
   path taken by a distributed RMF. When data flow. The issues regarding state management
   within the RMF is distributed NTLP (state related to message transport) are described in
   section 4. The QoS NSLP will typically have to handle additional
   state related to the
   network, desired resource reservation to be made.

   There two critical issues to be considered in building a robust NSLP
   to handle this problem:
   *) The protocol for communication with the NI, NF, NR may not must be
   required. In this case scalable. It should allow minimization of the RMF is providing traffic classification
   and conditioning functions; an example
   resource reservation state storage demands that it implies for
   intermediate nodes; in particular, storage of such functionality state per 'micro' flow
   is
   described in [34]. Figure 9 shows how a distributed RMF could
   interact with likely to be impossible except at the NSIS protocol.

     +----+   NSIS   +-----+    NSIS   +-----+   NSIS   +----+
     | NI |==========| NF  |====...====| NF  |==========| NR |
     +----+          +-----+           +-----+          +----+
     +----+          +-----+           +-----+          +----+
     |RMF |          | RMF |           | RMF |          |RMF |
     +----+          +-----+           +-----+          +----+

              Figure 9: Distributed RMF as a server for NSIS

7.4 NSIS very edge of the network. A
   QoS signaling application might require per flow or lower granularity
   state; examples of each for Middlebox Signaling

   As well as the use case of QoS would be IntServ [33] or
   RMD [34] (per 'class' state) respectively.
   *) The protocol must be robust against failure and other conditions,
   which imply that the stored resource reservation state has to be
   moved or removed.

   For resource reservations, typically soft state management is
   considered for 'traditional' QoS signaling, it robustness reasons. It is currently open whether the
   soft state protocol aspects should be
   possible to use NSIS to set up flow-related state in middleboxes
   (firewalls, NATs, and so on). Requirements built into the NSLP for such communication are
   given
   specific signaling applications, or provided as a generic service by
   the NTLP; this issue is discussed in [35], and initial discussions section 3.4.2.

6.1.3  QoS Forwarding

   The assumption is that the NTLP works with standard (i.e. best-
   effort) layer 3 routing. There are, however, several proposals for
   the introduction of NSIS-like solutions are
   contained QoS awareness in [36], [37] and [38]. A future version the routing protocols. All of this document
   may
   these essentially lead to the existence of multiple paths (with
   different QoS) towards the same destination. As such, they also
   contain more details on how an NSIS should be used inherent risk for a divergence between control plane and
   data plane, similar to the load sharing case. Clearly, any QoS NSLP
   needs to be able to handle this type of signaling application.

7.5 Multi-Level NSIS Signaling

   This section describes a way of separating routing.

   For intra-domain data flows, the NSIS signaling
   protocol into more than one hierarchical level. difference in routing may result
   from a QoS-aware traffic engineering scheme, that e.g. maps incoming
   flows to LSPs based on multi-field classification. In this section three
   levels of hierarchy BGP, several
   techniques for including QoS information in the routing decision are considered (see Figure 10); however,
   currently proposed. A first proposal is based on a newly defined BGP-
   4 attribute, the
   approach QoS_NLRI attribute [16]. The QoS_NLRI attribute is quite general
   an optional transitive attribute that can be used to more (or fewer) levels: advertise a QoS
   route to a peer or to provide QoS information along with the important
   issue Network
   Layer Reachability Information (NLRI) in a single BGP update. A
   second proposal is the use based on controlled redistribution of NSIS at more than one level at all.

   The lowest hierarchical level ("level 1") provides basic resource
   management functionality related AS routes
   [17]. It defines a new extended community (the redistribution
   extended community) that allows a router to scalable, simple and fast soft
   state maintenance and influence how a specific
   route should be redistributed towards a specified set of eBGP
   speakers. The types of redistribution communities may result in a
   specific route not being announced to transport functions, such as reliable
   delivery a specified set of signaling messages, congestion control notification and
   load sharing adaptation. Soft state eBGP
   speakers, that is maintained by this level
   is usually per traffic class based.

   The second hierarchical level ("level 2") is more complex than level
   1 as regards soft state maintenance. Soft state maintained by this
   hierarchical level is usually per flow. Note it should not be exported or that this level, like
   level 1, also supports transport functions. When an NSIS edge-to-edge
   multi-domain protocol is used, level 2 stretches beyond domain
   boundaries and is applied on all the edges of route should be
   prepended n times.

6.1.4  Route Changes and QoS Reservations

   In this section, we will explore the domains that are
   included in expected interworking between a
   signaling for resource BGP routing updates, although the multidomain region. same applies
   for any source of routing updates. The third hierarchical level ("level 3") includes a set normal operation of upper-
   level signaling functions that are specific the NSIS
   protocol will lead to particular signaling
   applications. Such functions could, for example, be security, policy,
   billing, etc.

   As shown the situation depicted in Figure 10, 7, where the three hierarchical levels might be applied
   on different
   reserved resources match the data path.

                    reserved +----+  reserved  +----+
                     ------->| NF |----------->| NF |
                             +----+            +----+
                  =====================================
                                data path

                 Figure 7: Normal NSIS entities.

   This three-level architecture protocol operation

   A route change (triggered by a BGP routing update for NSIS signaling instance) can be provided by
   using:
    *)
   occur while such a single end-to-end NSIS protocol that supports all three
   hierarchical levels
    *) two independent NSIS protocols: Level 3 reservation is supported by an end-
   to-end NSIS protocol, and levels 1 in place. In case of RSVP, the
   route change will be installed immediately and 2 are supported by another
   edge-to-edge NSIS protocol.

   |-----|   |-------|                           |-------|   |-----|
   |level|<--| level |<--------------------------| level |<->|level|
   |  3  |<--|   3   |                           |   3   |<->|  3  |
   |-----|   |-------|                           |-------|   |-----|
   |     |   |       |                           |       |   |     |
   |     |   |-------|                           |-------|   |     |
   |     |   | level |<------------------------->| level |   |     |
   |     |   |   2   |                           |   2   |   |     |
   |     |   |-------|                           |-------|   |     |
   |     |   |       |                           |       |   |     |
   |-----|   | any data that is sent
   will be forwarded on the new path. This situation is depicted Figure
   8.

                              Route update
                                   |
                                   v
                       reserved +----+  reserved  +----+
                        ------->| NF |----------->| NF |
              -------     -------|   |-------|   |-------|   |-----|
   |level|<->| level |<->| level |<->| level |<->| level |<->|level|
                                +----+            +----+
                        ========== |  1  |<->|   1   |<->|   1   |<->|   1   |<->|   1   |<->|  1
                                || |
   |-----|   |-------|   |-------|   |-------|   |-------|   |-----|
     NI         NF          NF          NF           +----+
                                || +---------->| NF         NR
              (edge)     (interior)  (interior)   (edge) |
                                ||             +----+
                                ============================
                                  data path

                          Figure 10: Three level architecture for NSIS signaling

   The components in 8: Route Change

   Resource reservation on the new path will only be started once the scenario
   next control message is routed along the new path. This means that
   there is a certain time interval during which resources are as follows:
    *) NI (NSIS Initiator): can not
   reserved on (part of) the data path. To minimize this time interval
   several techniques could be considered. As an end-host or example, RSVP [4] has
   the concept of local repair, where the router may be triggered by a proxy and can
   process and use
   route change. In that case the "level 1" and "level 3" protocol components
    *) NR (NSIS Responder): RSVP node can start sending PATH
   messages directly after the route has been changed. Note that this
   option may not be an end-host or available if no per-flow state is kept in the NF.

   It is not guaranteed that the new path will be able to provide the
   same guarantees that were available on the old path. Therefore, in a proxy and can
   process and use
   more desirable scenario, the "level 1" and "level 3" protocol components
    *) NF (NSIS Forwarder) (edge): can be should wait until resources have been
   reserved on the new path before installing the route change (unless
   of course the old path no longer exists). The route change procedure
   then consists of the following steps:
   1. NF receives a Diffserv edge, MPLS edge,
   etc. It can process route announcement,
   2. Refresh messages are forwarded along the current path,
   3. A copy of the refresh message is re-marked as a request and use send
   along the "level 3", "level 2" new path that was announced,
   4. When the NF has been acknowledged about the reservations on the
   new path the route will be installed and "level 1"
   protocol components. Usually, "level 2" provides an interworking
   between "level 1" the data will flow along the
   new path.

   Another example related to route changes is denoted as severe
   congestion and "level 3" protocol components.
    *) NF (interior): can be any router within is explained in [34]. This solution adapts to a domain. It can process
   and use only route
   change, when a route change creates a congestion on the "level 1" protocol component. new routed
   path.

6.1.5  Resource Management Interactions

   The "level 3" and
   "level 2" protocol components are QoS NSLP itself is not processed (used involved in any specific resource
   allocation or checked). management techniques. The hierarchical level separation can be provided by supporting definition of an NSLP for
   resource reservation with Quality-of-Service, however, implies the
   notion of admission control. For a
   hierarchical object structure. In other words, QoS NSLP, the NSIS protocol
   objects should measure of signaling
   success will be structured and positioned within the NSIS messages ability to reserve resources from the total
   resource pool that is provisioned in a hierarchical way, i.e., first the "level 1" objects, then network. We define the
   "level 2" objects and finally
   function responsible for allocating this resource pool as the "level 3" objects.

8. Open Issues
   Resource Management Function (RMF). The following issues are currently open points within RMF is responsible for all
   resource provisioning, monitoring and assurance functions in the framework.
   They are summarized here
   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 single overview.

    1. server towards client NSLP(s). It is not clear which of noted, however, that the NI, NF and NR can modify or release
   existing reservations (this is essentially an authorisation issue).
   (Section 3.3.2.)
    2. It is not clear whether NSIS entities relate to each other only
   locally (peer-peer) or whether longer distance, non-local
   interactions and state have RMF
   may in turn use another NSLP instance to be managed and stored. (Section
   3.3.3.)

    3. NSIS messages could be addressed either explicitly (to do the actual resource
   provisioning in the
   neighboring peer) or implicitly, using network. In this case, the flow endpoint addresses.
   (Section 3.3.4.)

    4. It is not clear where RMF acts as the
   initiator (client) of an NSLP.

   This essentially corresponds to draw a multi-level signaling paradigm,
   with an 'upper' level handling internetworking QoS signaling,
   possibly running end-to-end, and a 'lower' level handling the boundaries more
   specialised intradomain QoS signaling, running between just the NTLP edges
   of the network (see [35], [36], and [37] for a discussion of similar
   architectures). Given that NSIS signaling layer, and how is already supposed to establish the extent be
   able to which the
   requirements support multiple instances of the diverse signaling applications considered NSLPs for
   NSIS should influence NTLP functionality. (Section 3.3.5.)

    5. If NSIS has explicit acknowledgement a given flow, and notification messages,
   limited scope (e.g. edge-to-edge) operation, it is open whether they should relate not currently
   clear that supporting the multi-level model leads to anything beyond any new protocol
   requirements for the
   immediate peer relationship. (Section 3.3.6.)

    6. To function QoS NSLP.

   The RMF may or may not be co-located with an NF (note that co-
   location with an NI/NR can be handled logically as part of a complete system, combination
   between NF and NI/NR). To cater for both cases, we define a (possibly
   logical) NF-RMF interface. Over this interface, information may be
   provided from the NSIS protocol RMF about monitoring, resource availability,
   topology, and configuration. In the other direction, the interface
   may
   need to be supported by extensions used to other protocols. These
   extensions are still trigger requests for resource provisioning. One way to be identified. (Section 4.2.)

    7. The NSIS protocol could be constructed on the services offered by
   lower layer protocols, but
   formalize the dividing line interface between NSIS the NF and these
   lower layers the RMF is not fixed. Use of standard lower layer protocols via a Service
   Level Agreement (SLA). The SLA may be difficult if 'end-to-end addressing' (see section 3.3.4) is used.
   (Section 4.3.1.)

    8. It is commonly expected that static or it may be dynamically
   updated by means of a negotiation protocol. Such a future resource signaling protocol
   would need to use abstract reservation identifiers. However, is
   outside the
   precise properties needed scope of these identifiers are unclear, and
   enabling their secure use NSIS.

   There is no assumed restriction on the placement of the RMF. It may
   be hard. (Sections 4.5.2 and 5.3.2.)

    9. Use of some routing techniques (e.g. load sharing a centralized RMF per domain, several off-path distributed RMFs,
   or QoS
   routing), even in remote parts an on-path RMF per router. The advantages and disadvantages of the network, could
   both approaches are well-known. Centralization typically allows
   decisions to be incompatible taken on more global information with naive use more efficient
   resource utilization as a result. It also facilitates deployment or
   upgrade of end-to-end addressing. (Sections 5.2.1 policies. Distribution allows local decision processes and 5.2.2.)

    10. The correct flow identification semantics need
   rapid response to be defined in data path changes.

6.2 Other Signaling Applications

   As well as the case where mobility encapsulations might make use for 'traditional' QoS signaling, it ambiguous which
   addresses should be
   possible to use. (Section 5.3.1.)

    11. The interactions between mobility and resource use develop NSLPs for other signaling during
   path updating need to be further analyzed, especially from the point
   of view applications which
   operate on different types of combined overall latency. (Section 5.3.2 network control state. One specific
   case is setting up flow-related state in middleboxes (firewalls,
   NATs, and 5.3.3.)

9. Change History

9.1 Changes from draft-ietf-nsis-fw-00.txt

   1. Editorial fix so on). Requirements for such communication are given in 'classifier' definition (section 2).
   2. Added definition
   [6], and initial discussions of 'peer determination' (finding the right peer NSIS-like solutions are contained in
   [38], [39] and [40]. Other examples include network monitoring and
   testing, and tunnel endpoint discovery.

   A future version of this document may contain more details on how to
   build NSLPs for these types of signaling application.

7. Security Considerations

   This document describes a given flow) (section 2).
   3. Added definitions framework for 'sender' and 'receiver' refers to role
      relative to data packets always (section 2, and minor fixes in
      sections 3.2.6 and 3.2.7).
   4. Updated references.
   5. Replaced 'peer session' with 'peer relationship' and 'peer
      session addressing' signaling protocols which
   assumes a two-layer decomposition, with 'peer-peer addressing' (throughout), and
      attempted redraw a common lower layer (NTLP)
   supporting a family of Figure 1 to make it less session-like
      (corresponding changes in Figure 4, Figure 7, Figure 8, and
      Figure 9).
   6. Added terms for transport and signaling application specific upper layer
   protocols
      (NTLP/NSLP) and explanation (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 new section 3.1.3. New terms used
      throughout (significant rewrites 4.6. We have assumed
   that the role of the NTLP will be to section 4, although provide message protection over
   the scope of a single peer relationship (between adjacent signaling
   entities), and that this can most likely be provided by some kind of
   channel security mechanism using an external key management mechanism
   based on mutual authentication. In addition, the NTLP should be at most a change
   resilient against denial of emphasis rather than technical
      content).
   7. Clarified that section 3.2 service attacks on the protocol itself.

   Security for the NSLPs is about possible modes of operation
      (listing alternatives, not all to entirely dependent on signaling application
   requirements. In some cases, no additional protection may be supported).
   8. Clarified 'local object' definition in 3.2.4.
   9. Added working assumption in 3.3.1 that end-to-end routing required
   compared to what is done provided by sequentially determining the right peer in the NTLP, NTLP. In other cases, more
   sophisticated object-level protection and no-
      one discovers or uses global topology information the use of public key based
   solutions may be required. In addition, the NSLP needs to consider
   the authorisation requirements of the signaling application.

   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 this.
   10.Added working assumption in 3.3.3 that authorisation
   aspects; this complicates the analysis of basing signaling
   application security on NTLP operates only
      locally.
   11.Slightly trimmed 3.3.5 in preparation for turning it into protection. Further work on this and
   other security design will depend on a
      discussion about refinement of the NSIS layering boundaries.
   12.Clarified in section 4.2 that peer determination doesn't have to
      be a separate capability, just that it could additionally be done
      separately.
   13.Fixed some flow identification terminology inconsistencies threats
   work begun in
      section 5.3.1.

9.2 [12].

8. Change History

8.1 Changes from draft-hancock-nsis-fw-00.txt

    1. Changed title, document name draft-ietf-nsis-fw-01.txt

   This -02 version has been very significantly restructured compared to
   the previous version, and dates.
    2. Updated references.
    3. Editorial fix in NSIS Forwarder definition (section 2).
    4. Revised a section 3.2.1 (path-coupled terminology), by section change history is
   probably neither possible or useful. Instead, this section lists the
   major technical and structural changes.

   1. The concept of splitting the protocol suite into two layers is
      now used
   consistently in introduced much earlier, and the rest of the document. Likewise, 'signaling
   application' terminology used consistently in remainder of document.
    5. Split old section 5 into new sections (new 5 "real interactions",
   new 7 "how to use NSIS framework
      restructured around it. In general, the content is supposed to do something useful").

    6. Added new resource management text be
      signaling application independent: possibilities for section 5.1; slight
   smoothing to balance centralized and distributed, and comment on
   NI/NF/NR distinction.
    7. Added VRRP placeholder application
      dependent behavior are described in routing section 3.3, and the specific
      case of section 5 (5.2.5).
    8. Added section 5.4 on NSIS/NAT interactions based on Melinda's
   email.
    9. Added new text for resource QoS/resource management in is restricted to section 7.2; slightly
   trimmed 6.1.
   2. Sender and made clearer that it receiver orientation is mainly discussing now assumed to be a signaling
      application protocol property (section 3.3.1), with the centralized
   case (and isn't NTLP by
      default operating bidirectionally (section 3.2.3). As a
      consequence, the initiator, forwarder, and responder concepts
      only appear in the later sections.
   3. In general, the NTLP is now a 'thinner' layer than previously
      envisaged (e.g. without specific to reserve/tear messages), and so
      the possible inter-layer coupling with the NSLP is much reduced.
      However, the option of the inter-domain case). Comment that it's
   OK to use NTLP providing some kind of generic
      state management service is still an open issue (section 3.4.2).
   4. In general, authorisation issues are still handled by the Q-word here since we aren't talking about NSLP,
      including the NSIS
   protocol but a use question of which network entities are allowed to
      modify network state. In particular, the NSIS protocol.
    10. Added section 7.3 for discussion issue of how NSIS can 'session'
      (previously 'reservation') ownership (section 3.1.4) is assumed
      to be used in a
   distributed resource management environment.
    11. Added a placeholder in section 7.4 for use of NSIS for midcom
   (no technical content, but references handled by the NSLP level, although session identification
      is still visible to the midcom requirements NTLP (section 4.5.2). The implication is
      that most key aspects of mobility support (section 5.2) are now
      NSLP responsibilities.

   5. Both peer-peer and end-to-end addressing modes are assumed to be
      needed for the TIST NTLP, and NEC drafts).
    12. Moved open issues from section 3.3.1 to new section 8 (left
   assumptions behind).
    13. Added this changes section 9. any choice between them is a protocol
      design issue (not visible externally).

References

   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Brunner, M., "Requirements for QoS Signaling Protocols", draft-
      ietf-nsis-req-05.txt (work in progress), November 2002

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

   3  Brunner, M., "Requirements for QoS Signaling Protocols", draft-
      ietf-nsis-req-05.txt (work in progress), November 2002

   4  Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
      ReSerVation Protocol (RSVP) -- Version 1 Functional
      Specification", RFC 2205, September 1997

   5  Chaskar, H. (editor), "Requirements of a QoS Solution for Mobile
      IP", draft-ietf-mobileip-qos-requirements-03.txt (work in
      progress), July 2002

   6  Swale, R. P., P. A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
      Communications (midcom) Protocol Requirements", RFC 3304, August
      2002

   7  Manner, J. and X. Fu, "Analysis of Existing Quality of Service
      Signaling Protocols", draft-ietf-nsis-signalling-analysis-00.txt draft-ietf-nsis-signalling-analysis-01.txt
      (work in progress), February 2003

   8  Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-
      thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002

   9  Braden, R., and B. Lindell, "A Two-Level Architecture for Internet
      Signaling", draft-braden-2level-signaling-01.txt (work in
      progress), October November 2002

   5

   10 Rescorla, E. et al., "Guidelines for Writing RFC Text on Security
      Considerations", draft-iab-sec-cons-03.txt (work in progress),
      January 2003

   11 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne,
      "NSIS Threats", draft-ietf-nsis-threats-00.txt Authentication, Authorization and Accounting Issues", draft-
      tschofenig-nsis-aaa-issues-00.txt (work in progress), October 2002

   6 February
      2003
   12 Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
      draft-ietf-nsis-threats-01.txt (work in progress), January 2003

   13 Katz, D., "IP Router Alert Option", RFC 2113, February 1997

   7

   14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711,
      October 1999

   8  Braden, R., and B. Lindell, "A Two-Level Architecture for Internet
      Signaling", draft-braden-2level-signaling-01.txt (work in
      progress), November 2002
   9  Stewart, R., Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer,
      T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxson, "Stream
      Control Transmission Protocol", RFC 2960, October 2000

   10 Kent, S., R. Atkinson, "Security Architecture for the Internet
      Protocol", RFC 2401, November 1998

   11 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework
      for Edge-to Edge NSIS Signaling", draft
                 -                           -westberg-nsis-edge-edge-
      framework-00.txt (work in progress), May 2002

   12

   15 Apostolopoulos, G., D. Williams, S. Kamat, R. Guerin, A. Orda,
      T. Przygienda, "QoS Routing Mechanisms and OSPF Extensions", RFC
      2676, August 1999

   13

   16 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC
      1771, March 1995

   14

   17 Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
      draft-ietf-idr-bgp4-17.txt (work in progress), January 2002
      (expired)

   15

   18 Walton, D., D. Cook, A. Retana and J. Scudder, "Advertisement of
      Multiple Paths in BGP", draft-walton-bgp-add-paths-00.txt (work in
      progress), May 2002

   16 Cristallo, G., C. Jacquenet, "Providing Quality-of-Service
      Indication by the BGP-4 Protocol: the QoS_NLRI Attribute", draft-
      jacquenet-qos-nlri-04.txt (work in progress), March 2002 (expired)

   17 Bonaventure, O., S. De Cnodder, J. Haas, B. Quoitin and R. White,
      "Controlling the redistribution of BGP Routes", draft-bonaventure-
      bgp-redistribution-02.txt draft-walton-bgp-add-paths-01.txt (work in
      progress), February November 2002
      (expired)

   18 Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource
      ReSerVation Protocol (RSVP) -- Version 1 Functional
      Specification", RFC 2205, September 1997

   19 Westberg, L., M. Jacobsson, G. Karagiannis, S. Oosthoek, D.
      Partain, V. Rexhepi, R. Szabo, P. Wallentin, "Resource Management
      in Diffserv (RMD) Framework", draft-westberg-rmd-framework-02.txt
      (work in progress), October 2002
   20 Knight, S., D. Weaver, D. Whipple, R. Hinden, D. Mitzel, P. Hunt,
      P. Higginson, M. Shand, A. Lindem, "Virtual Router Redundancy
      Protocol", RFC2338, April 1998

   21

   20 Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-
      thomas-nsis-rsvp-analysis-00.txt (work in progress), October 2002

   22

   21 Partain, D., G. Karagiannis, P. Wallentin, L. Westberg, "Resource
      Reservation Issues in Cellular Radio Access Networks", draft-
      westberg-rmd-cellular-issues-01.txt (work in progress), June 2002

   23

   22 Shen, C. et al., "An Interoperation Framework for Using RSVP in
      Mobile IPv6 Networks", draft-shen-rsvp-mobileipv6-interop-00.txt
      (work in progress), July 2001 (expired)

   24

   23 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-00.txt draft-manner-lrsvp-01.txt
      (work in progress), May 2002

   25 January 2003

   24 Chaskar, H. and R. Koodli, "A Framework for QoS Support in Mobile
      IPv6", draft-chaskar-mobileip-qos-01.txt (work in progress), March
      2001 (expired)

   26
   25 Fu, X., et al, "QoS-Conditionalized Binding Update in Mobile
      IPv6", draft-tkn-nsis-qosbinding-mipv6-00.txt (work in progress),
      January 2002 (expired)

   27

   26 Kan, Z., "Two-plane and Three-tier QoS Framework for Mobile IPv6
      Networks", draft-kan-qos-framework-01.txt (work in progress), July
      2002

   28

   27 Trossen, D., G. Krishnamurthi, H. Chaskar, J. Kempf, "Issues in
      candidate access router discovery for seamless IP-level handoffs",
      draft-ietf-seamoby-cardiscovery-issues-04.txt (work in progress),
      October 2002

   29

   28 Kempf, J., "Problem Description: Reasons For Performing Context
      Transfers Between Nodes in an IP Access Network", RFC3374,
      September 2002

   30

   29 Srisuresh, P. and M. Holdrege, "IP Network Address Translator
      (NAT) Terminology and Considerations", RFC2663, August 1999

   31

   30 Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
      RFC2765, February 2000
   32

   31 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
      Traversal of UDP Through Network Address Translators", draft-ietf-
      midcom-stun-03.txt
      midcom-stun-05.txt (work in progress), December 2002

   32 Westberg, L., G. Karagiannis, D. Partain, V. Rexhepi., "Framework
      for Edge-to-Edge NSIS Signaling", draft-westberg-nsis-edge-edge-
      framework-00.txt (work in progress), October May 2002

   33 Danny Goderis, et al. "Service Level Specification Semantics and
      Parameters", draft-tequila-sls-02.txt (work Braden, R., D. Clark, S. Shenker, "Integrated Services in progress), February
      2002 (expired) the
      Internet Architecture: an Overview", RFC 1633, June 1994

   34 Blake, S., D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
      Architecture Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
      Partain, D., Pop, O., Rexhepi, V., Szabó, R., Takács, A.,
      "Resource Management in Diffserv (RMD): A Functionality and
      Performance Behavior Overview", Seventh International Workshop on
      Protocols for Differentiated Services", RFC2475, December 1998 High-Speed networks - PfHSN 2002, 22 - 24 April 2002

   35 Swale, R. P., P. Ferrari, D., A. Mart, P. Sijben, S. Brim, M. Shore, "Middlebox
      Communications (midcom) Protocol Requirements", RFC3304, August
      2002 Banerjea, H. Zhang, "Network Support for
      Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
      072, November 1992

   36 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated
      Services Architecture for the Internet", RFC 2638, July 1999
   37 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
      RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001

   38 Shore, M., "Towards a Network-friendlier Midcom", draft-shore-
      friendly-midcom-01.txt (work in progress), June 2002

   37

   39 Shore, M., "The TIST (Topology-Insensitive Service Traversal)
      Protocol", draft-shore-tist-prot-00.txt (work in progress), May
      2002

   38

   40 Brunner, M. and M. Stiemerling, "Middlebox Signaling in a NSIS
      Framework", draft-brunner-nsis-mbox-fmwk-00.txt (work in
      progress), June 2002

Acknowledgments

   The authors would like to thank Anders Bergsten, Bob Braden, Maarten
   Buchli, Eleanor Hepworth, Melinda Shore and Hannes Tschofenig for
   significant contributions in particular areas of this draft. In
   addition, the authors would like to acknowledge Cedric Aoun, Marcus
   Brunner, Danny Goderis,
   Eleanor Hepworth, Cornelia Kappler, Mac McTiffin, Hans De Neve,
   David Partain, Vlora Rexhepi, Henning Schulzrinne and Lars Westberg
   for insights and inputs during this and previous framework
   activities.

Author's

Authors' Addresses

   Ilya Freytsis
   Cetacean Networks Inc.
   100 Arboretum Drive
   Portsmouth, NH 03801
   USA
   email: ifreytsis@cetacean.com

   Robert Hancock
   Roke Manor Research
   Old Salisbury Lane
   Romsey
   Hampshire
   SO51 0ZN
   United Kingdom
   email: robert.hancock@roke.co.uk
   Georgios Karagiannis
   Ericsson EuroLab Netherlands B.V.
   Institutenweg 25
   P.O.Box 645
   7500 AP Enschede
   The Netherlands
   email: georgios.karagiannis@eln.ericsson.se

   John Loughney
   Nokia Research Center
   11-13 Italahdenkatu
   00180 Helsinki
   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

Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   "Copyright (C) The Internet Society (2002). (2003). All Rights Reserved. This
   document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns. This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS 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.

Hancock et al.         Expires - Septemb