NSIS Working Group
   Internet Draft                               Robert Hancock (editor)
                                            Siemens/Roke Manor Research
                                                          Ilya Freytsis
                                                      Cetacean Networks
                                                   Georgios Karagiannis
                                          University of Twente Twente/Ericsson
                                                          John Loughney
                                                                  Nokia
                                                     Sven Van den Bosch
                                                                Alcatel
   Document: draft-ietf-nsis-fw-03.txt draft-ietf-nsis-fw-04.txt
   Expires: December 2003                                     June March 2004                                   September 2003

                    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.

   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 Next Steps in Signaling working group is considering protocols
   for signaling information about a data flow along its path in the
   network. Based on existing work on signaling requirements, this
   document proposes an architectural framework for such signaling
   protocols.

   This document provides a model for the network entities that take
   part in such signaling, and the relationship between signaling and
   the rest of network operation. We decompose the overall signaling
   protocol suite into a generic (lower) layer, with a separate upper
   layers for each specific signaling application. An initial proposal
   for the split between these layers is given, describing the overall
   functionality of 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
   signaling and other network layer functions, specifically routing,
   mobility, and address translators. The different events that impact
   signaling operation are described, along with how their handling
   should be 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 [1].
   [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
   2 Terminology ....................................................5
   3 Overview of Signaling Scenarios and Protocol Structure .........6
     3.1   Fundamental Signaling Concepts ...........................6
     3.1.1   Simple Network and Signaling Topology ..................6
     3.1.2   Path-Coupled and Path-Decoupled Signaling ..............7
     3.1.3   Signaling to Hosts, Networks and Proxies ...............8
     3.1.4   Signaling Messages and Network Control State ..........10
     3.1.5   Data Flows and Sessions ...............................10
     3.2   Layer Model for the Protocol Suite ......................11
     3.2.1   Layer Model Overview ..................................11
     3.2.2   Layer Split Concept ...................................13 ...................................12
     3.2.3   Bypassing Intermediate Nodes ..........................13
     3.2.4   Core NTLP Functionality ...............................14
     3.2.4 ...............................15
     3.2.5   State Management Functionality ........................14
     3.2.5 ........................15
     3.2.6   Path De-Coupled Operation .............................15 .............................16
     3.3   Signaling Application Properties ........................16 ........................17
     3.3.1   Sender/Receiver Orientation ...........................16 ...........................17
     3.3.2   Uni- and Bi-Directional Operation .....................17 .....................18
     3.3.3   Heterogeneous Operation ...............................18 ...............................19
     3.3.4   Aggregation ...........................................19
     3.3.5   Peer-Peer and End-End Relationships ...................18
     3.3.5 ...................20
     3.3.6   Acknowledgements and Notifications ....................19
     3.3.6 ....................20
     3.3.7   Security and Other AAA Issues .........................19 .........................21
   4 The NSIS Transport Layer Protocol .............................20 .............................21
     4.1   Internal Protocol Components ............................20 ............................22
     4.2   Addressing ..............................................21 ..............................................22
     4.3   Classical Transport Functions ...........................22 ...........................23
     4.4   Lower Layer Interfaces ..................................23 ..................................25
     4.5   Upper Layer Services ....................................24 ....................................25
     4.6   Identity Elements .......................................24 .......................................26
     4.6.1   Flow Identification ...................................24 ...................................26
     4.6.2   Session Identification ................................25 ................................27
     4.6.3   Signaling Application Identification ..................25 ..................27
     4.7   Security Properties .....................................26 .....................................28
   5 Interactions with Other Protocols .............................26 .............................28
     5.1   IP Routing Interactions .................................26 .................................28
     5.1.1   Load Sharing and Policy-Based Forwarding ..............27 ..............29
     5.1.2   Route Changes .........................................28
     5.1.3   Router Redundancy .....................................29 .........................................29
     5.2   Mobility Interactions ...................................29
     5.2.1   Addressing and Encapsulation ..........................30
     5.2.2   Localized Path Repair .................................31
     5.2.3   Update on the Unchanged Path ..........................31
     5.2.4   Interaction with Mobility Signaling Multihoming Interactions ...................31
     5.2.5   Interaction with Seamless Handover Protocols ..........33
     5.3   Interactions with NATs ..................................33
     5.4   Interactions with IP Tunneling ..........................34
   6 Signaling Applications ........................................34 ........................................35
     6.1   Signaling for Quality of Service ........................34 ........................35
     6.1.1   Protocol Messages .....................................34 Message Semantics ............................36
     6.1.2   State Management ......................................35 ......................................36
     6.1.3   QoS Forwarding ........................................36
     6.1.4   Route Changes and QoS Reservations ....................36
     6.1.5 ....................37
     6.1.4   Resource Management Interactions ......................38
     6.2   Other Signaling Applications ............................39 ............................40
   7 Security Considerations .......................................39 .......................................40
   8 Change History ................................................40 ................................................41
     8.1   Changes from draft-ietf-nsis-fw-02.txt ..................40 draft-ietf-nsis-fw-03.txt ..................41
     8.2   Changes from draft-ietf-nsis-fw-02.txt ..................42
     8.3   Changes from draft-ietf-nsis-fw-01.txt ..................40
   References.......................................................41
   Acknowledgments..................................................43 ..................42
   References.......................................................43
   Acknowledgments..................................................45
   Authors' Addresses...............................................44 Addresses...............................................46
   Intellectual Property Considerations.............................45 Considerations.............................46
   Full Copyright Statement.........................................45 Statement.........................................47

1 Introduction

1.1 Definition of the NSIS Signaling Problem

   The NSIS working group is considering protocols for signaling
   information about a data flow along its path in the network.

   It is assumed that the path taken by the data flow is already
   determined by network configuration and routing protocols,
   independent of the signaling itself; that is, signaling to set up the
   routes themselves is not considered. Instead, the signaling simply
   interacts with nodes along the data flow path. Additional
   simplifications are that the actual signaling messages pass directly
   through these nodes themselves (i.e. the 'path-coupled' case, see
   section 3.1.2) and that only unicast data flows are considered.

   The signaling problem in this sense is very similar to that addressed
   by RSVP [2]. [1]. However, there are two generalizations. Firstly, the
   intention is that components of the NSIS protocols protocol suite will be
   usable in different parts of the Internet, for different needs,
   without requiring a complete end-to-end deployment (in particular,
   the signaling protocol messages may not need to run all the way
   between the data flow endpoints).

   Secondly, the signaling is intended for more purposes than just QoS
   (resource reservation). The basic mechanism to achieve this
   flexibility is to divide the signaling protocol stack into two
   layers: a generic (lower) layer, and an upper layer specific to each
   signaling application. The scope of NSIS work is to define both the
   generic protocol, and initially an upper layer layers suitable for QoS
   signaling similar (similar to the corresponding functionality in RSVP. Further
   signaling applications, such as RSVP) and
   middlebox signaling, signaling. Further applications may be considered later.

1.2 Scope and Structure of the NSIS Framework

   The underlying requirements for signaling in the context of NSIS are
   defined in [3] [2] and a separate security threats document [4]; [3]; other
   related requirements can be found in [5] [4] and [6]. [5]. This framework does
   not replace or update these requirements. Discussions about lessons
   to be learned from existing signaling and resource management
   protocols are contained in separate analysis documents [7], [8]. [6], [7].

   The role of this framework is to explain how NSIS signaling should
   work within the broader networking context, and how the signaling
   protocols should be structured at to describe the
   overall level. structure of the protocol suite itself. Therefore, it
   discusses important protocol considerations, such as routing,
   mobility, security, and interactions with network 'resource'
   management (in the broadest sense).

   The basic context for NSIS protocols is given in section 3. Section
   3.1 describes the fundamental elements of NSIS protocol operation in
   comparison to RSVP; in particular, section 3.1.3 describes more
   general signaling scenarios, and 3.1.4 defines a broader class of
   signaling applications for which the NSIS protocols should be useful.
   The two-layer protocol architecture that supports this generality is
   described in section 3.2, and section 3.3 gives examples of the ways
   in which particular signaling application properties can be
   accommodated within signaling layer protocol behavior.

   The overall functionality required from the lower (generic) protocol
   layer is described in section 4. This is not intended to define the
   protocol
   detailed design of the protocol or even design options, although some
   are described as examples. It describes the interfaces between this
   lower layer protocol and the IP layer (below) and signaling
   application protocols (above), including the identity identifier elements that
   appear on these interfaces. interfaces (section 4.6). Following this, section 5
   describes how signaling applications that use the NSIS protocols can
   interact sensibly with network layer operations, specifically routing
   (and re-routing), IP mobility, and network address translation.

   Section 6 describes particular signaling applications. The example of
   signaling for QoS (comparable to core RSVP QoS signaling
   functionality) is given in detail in section 6.1, which describes
   both the signaling application specific protocol and example modes of
   interaction with network resource management and other deployment
   aspects. However, note that these examples are included only as
   background and for explanation; 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.

   [Data] flow - a stream of packets from sender to receiver which is a
   distinguishable subset of a packet stream. Each flow is distinguished
   by some flow identifier (see section 4.6.1).

   Edge node - a an (NSIS-capable) node on the boundary of some
   administrative domain.

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

   NSIS Transport Layer Protocol (NTLP) - placeholder name for the NSIS
   protocol component that will support lower layer (signaling
   application independent) functions. See also section 3.2.1.

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

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

   Peer discovery - the act of locating and/or selecting which NSIS peer
   to carry out signaling exchanges with for a specific data flow.

   Peer relationship - signaling relationship between two adjacent NSIS
   entities (i.e. NEs with no other NEs between them).

   Receiver - the node in the network which is receiving the data
   packets in a flow.

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

   Session - application layer flow of information for which some
   network control state information is to be manipulated or monitored
   (see section 4.6.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.

3 Overview of Signaling Scenarios and Protocol Structure

3.1 Fundamental Signaling Concepts

3.1.1  Simple Network and Signaling Topology

   The NSIS suite of protocols is envisioned to support various
   signaling applications that need to install and/or manipulate state
   in the network. This state is related to a data flow and is installed
   and maintained on the NSIS Entities (NEs) along the data flow path
   through the network; not every node has to contain an NE. The basic
   protocol concepts do not depend on the signaling application, but the
   details of operation and the information carried do. This section
   discusses the basic entities involved with signaling as well as
   interfaces between them.

   Two NSIS entities that communicate directly are said to be in a 'peer
   relationship'. This concept might loosely be described as an 'NSIS
   hop'; however, there is no implication that it corresponds to a
   single IP hop. Either or both NEs might store some state information
   about the other, but there is no assumption that they necessarily
   establish a long-term signaling connection between themselves.

   It is common to consider a network as composed of various domains,
   e.g. for administrative or routing purposes, and the operation of
   signaling protocols may be influenced by these domain boundaries.
   However, it seems there is no reason to expect that an 'NSIS domain'
   should exactly overlap with an IP domain (AS, area) but it is likely
   that its boundaries would consist of boundaries (segments) of one or
   several IP domains.

   Figure 1 shows a diagram of nearly the simplest possible signaling
   configuration. A single data flow is running from an application in
   the sender to the receiver via routers R1, R2 and R3. Each host and
   two of the routers contain NEs which exchange signaling messages -
   possibly in both directions - about the flow. This scenario is
   essentially the same as that considered by RSVP for QoS signaling;
   the main difference is that we make no assumptions here about the
   particular sequence of signaling messages that will be invoked.

       Sender                                               Receiver
   +-----------+      +----+      +----+      +----+      +-----------+
   |Application|----->| R1 |----->| R2 |----->| R3 | ---->|Application| |----->|Application|
   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    |
   |   |NE|====|======||NE||======||NE||==================|===|NE|    |
   |   +--+    |      |+--+|      |+--+|                  |   +--+    |
   +-----------+      +----+      +----+                  +-----------+

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

                 Figure 1: Simple Signaling and Data Flows

3.1.2  Path-Coupled and Path-Decoupled Signaling

   We can consider two basic paradigms for resource reservation
   signaling, which we refer to as "path-coupled" and "path-decoupled".

   In the path-coupled case, signaling messages are routed only through
   nodes (NEs) that are in the data path. They do not have to reach all
   the nodes on the data path (for example, there could be proxies
   distinct from the sender and receiver as described in section 3.1.3,
   or intermediate signaling-unaware nodes); and between adjacent NEs,
   the route taken by signaling and data might diverge. The path-coupled
   case can be supported by various addressing styles, with messages
   either explicitly addressed to the neighbor on-path NE, or routed addressed
   identically to the data packets but also with the router alert option
   (see [8] and [9]) and intercepted. These cases are considered in
   section 4.2. In the second case, some network configurations may
   split the signaling and data paths (see section 5.1.1); this is
   considered an error case for path-coupled signaling.

   In the path-decoupled case, signaling messages are routed to nodes
   (NEs) which are not assumed to be on the data path, but which are
   (presumably) aware of it. Signaling messages will always be directly
   addressed to the neighbor NE, and the signaling endpoints may have no
   relation at all with the ultimate data sender or receiver. The
   implications of path-decoupled operation for the NSIS protocols are
   considered briefly in section 3.2.5; 3.2.6; however, the initial goal of
   NSIS and this framework is to concentrate mainly on the path-coupled
   case.

3.1.3  Signaling to Hosts, Networks and Proxies

   There are different possible triggers for the signaling protocols.
   Amongst them are user applications (that are using NSIS signaling
   services), other instances of the signaling, signaling applications, network management actions,
   some network events, and so on. The variety of possible triggers
   requires that the signaling can be initiated and terminated in the
   different parts of the network - hosts, domain boundary nodes (edge
   nodes) or interior domain nodes.

   The NSIS protocol suite extends the RSVP model to consider this wider
   variety of possible signaling exchanges. As well as the basic end-to-
   end model already described, examples such as end-to-edge and edge-
   to-edge can be considered. The edge-to-edge case might involve the
   edge nodes communicating directly, as well as via the interior nodes.

   While the end-to-edge (host-to-network) scenario requires only intra-
   domain signaling, the other cases might need inter-domain NSIS
   signaling as well if the signaling endpoints (hosts or network edges)
   are connected to different domains. Depending on the trust relation
   between concatenated NSIS domains the edge-to-edge scenario might
   cover single domain or multiple concatenated NSIS domains. The latter
   case assumes the existence of the trust relation relations between domains.

   In some cases it is desired to be able to initiate and/or terminate
   NSIS signaling not from the end host that sends/receives the data
   flow, but from the some other entities in the network that can be
   called signaling proxies. There could be various reasons for this:
   signaling on behalf of the end hosts that are not NSIS-aware,
   consolidation of the customer accounting (authentication,
   authorization) in respect to consumed application and transport
   resources, security considerations, limitation of the physical
   connection between host and network and so on. This configuration can
   be considered as a kind of "proxy 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

                      Figure 2: "On path" NSIS proxy

   This configuration presents 2 specific challenges for the signaling:
   *) The A proxy that terminates signaling on behalf of the NSIS-unaware
   host (or part of the network) should be able to make determination
   that it is a last NSIS aware node along the path.
   *) Where a proxy initiates NSIS signaling on behalf of the NSIS
   unaware host, interworking with some other "local" technology might
   be required, for example to provide QoS reservation from proxy to the
   end host in the case of QoS signaling application.

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

            Appl = signaling         PA = Proxy for signaling
                   application            application

                      Figure 3: "Off path" NSIS proxy

   Another possible configuration, shown in Figure 3, is where an NE can
   send and receive signaling information to a remote processor. The
   NSIS protocols may or may not be suitable for this remote
   interaction, but in any case it is not currently part of the NSIS
   problem. This configuration is supported by considering the NE 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.

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

            Appl = signaling         PA = Proxy for signaling
                   application            application

                      Figure 3: "Off path" NSIS proxy 6.1.4.

3.1.4  Signaling Messages and Network Control State

   The distinguishing features of the signaling supported by the NSIS
   protocols are that it is related to specific flows (rather than to
   network operation in general), and that it involves nodes in the
   network (rather than running transparently between the end hosts).

   Therefore, each signaling application (upper layer) protocol must
   carry per-flow information for the aspects of network-internal
   operation interesting to that signaling application. An example for
   the case of an RSVP-like QoS signaling application would be state
   data representing resource reservations. However, more generally, the
   per-flow information might be related to some other control function
   in routers and middleboxes along the path. Indeed, the signaling
   might simply be used to gather per-flow information, without
   modifying network operation at all.

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

3.1.5  Data Flows and Sessions

   Formally, a data flow is a (unidirectional) sequence of packets
   between the same endpoints which all follow a unique path through the
   network (determined by IP routing and other network configuration). A
   flow is defined by a packet classifier (in the simplest cases, just
   the destination address and topological origin are needed). In
   general we assume that when discussing only the data flow path, we
   only need to consider 'simple' fixed classifiers (e.g. IPv4 5-tuple
   or equivalent).

   A session is an application layer concept for a (unidirectional) flow
   of information between two endpoints, for which some network state is
   to be allocated or monitored. (Note that this use of the term
   'session' is not identical to the usage in RSVP. It is closer to the
   session concept of, for example, the Session Initiation Protocol.)

   The simplest service provided by NSIS signaling protocols is
   management of network control state at the level of a specific flow,
   as described in the previous subsection. In particular, it should be
   possible to monitor routing updates as they change the path taken by
   a flow and, for example, update network state appropriately. This is
   no different from the case for RSVP (local path repair). Where there
   is a 1:1 flow:session relationship, this is all that is required.

   However, for some more complex scenarios (especially mobility and
   multihoming related ones, see [3] [2] and the mobility discussion of [7]) [6])
   it is desirable to update the flow:session mapping during the session
   lifetime. For example, a new flow can be added, and the old one
   deleted (and maybe in that order, for a 'make-before-break'
   handover), effectively transferring the network control state between
   data flows to keep it associated with the same session. Such updates
   are best managed by the end systems (generally, systems which
   understand the flow:session mapping and are aware of the packet
   classifier change). To enable this, it must be possible to relate
   signaling messages to sessions as well as data flows. A session
   identifier (section 4.6.2) is one component of the solution.

3.2 Layer Model for the Protocol Suite

3.2.1  Layer Model Overview

   In order to achieve a modular solution for the NSIS requirements, the
   NSIS protocol suite will be structured in 2 layers:
    *) a 'signaling transport' layer, responsible for moving signaling
   messages around, which should be independent of 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 purpose of this document, we use the term 'NSIS Transport
   Layer Protocol' (NTLP) to refer to the component that will be used in
   the transport layer. We also use the term 'NSIS Signaling Layer
   Protocol' (NSLP) to refer generically to any protocol within the
   signaling application layer; in the end, there will be several NSLPs,
   largely independent of each other. These relationships are
   illustrated in Figure 4. Note that the NTLP may or may not have an
   interesting internal structure (e.g. including existing transport
   protocols) but that is not relevant at this level of description.

                 ^                     +-----------------+
                 |                     | NSIS Signaling  |
                 |                     | Layer Protocol  |
          NSIS   |    +----------------| for middleboxes |
       Signaling |    | NSIS Signaling |        +-----------------+
         Layer   |    | Layer Protocol +--------| NSIS Signaling  |
                 |    |     for QoS     |       | Layer Protocol  |
                 |    +-----------------+       |    for ...      |
                 V                              +-----------------+
                      =============================================
          NSIS   ^         +--------------------------------+
       Transport |         | NSIS Transport Layer Protocol  |
         Layer   V         +--------------------------------+
                      =============================================
                           +--------------------------------+
                           .      IP and lower layers       .
                           .                                .

                    Figure 4: NSIS Protocol Components

   Note that not every generic function has to be located in the NTLP.
   Another option would be to have re-usable components within the
   signaling application layer. Functionality within the NTLP should be
   restricted to that which interacts strongly with other transport and
   lower layer operations.

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

               Figure 5: Signaling with Heterogeneous NSLPs
   Because NSIS problem includes multiple signaling applications, it is
   very likely that a particular NSLP will only be implemented on a
   subset of the NSIS-aware nodes on a path, as shown in Figure 5.
   Messages for unrecognized NSLPs are forwarded at the NTLP level.

3.2.2  Layer Split Concept

   This section describes the basic concepts underlying the
   functionality of the NTLP. Firstly, we make a working assumption that
   the protocol mechanisms of the NTLP operate only between adjacent NEs
   (informally, the NTLP is a 'hop-by-hop' protocol), whereas any larger
   scope issues (including e2e aspects) are left to the upper layers.

   The way in which the NTLP works can be described as follows: When a
   signaling message is ready to be sent from one NE, it is given to the
   NTLP along with information about what flow it is for; it is then up
   to the NTLP to get it to the next NE along the path (up- or down-
   stream), where it is received and the responsibility of the NTLP
   ends. Note that there is no assumption here about how the messages
   are actually addressed (this is a protocol design issue, and the
   options are outlined in section 4.2). The key point is that the NTLP
   for a given NE does not use any knowledge about addresses,
   capabilities, or status of any NEs other than its direct peers.

   The NTLP in the receiving NE either forwards the message directly,
   or, if there is an appropriate signaling application locally, passes
   it upwards for further processing; the signaling application can then
   generate another message to be sent via the NTLP. In this way, larger
   scope (including end-to-end) message delivery is achieved.

   This definition relates to NTLP operation. It does not restrict the
   ability of an NSLP to send messages by other means. For example, an
   NE in the middle or end of the signaling path could send a message
   directly to the other end as a notification of or acknowledgement for
   some signaling application event. However, the issues in sending such
   messages (endpoint discovery, security, NAT traversal and so on) are
   so different from the direct peer-peer case that there is no benefit
   in extending the NTLP to include such non-local functionality;
   instead, an NSLP which requires such messages and wants to avoid
   traversing the path of NEs should use some other existing transport
   protocol - for example, UDP or DCCP would be a good match for many of
   the scenarios that have been proposed. Acknowledgements and
   notifications of this type are considered further in section 3.3.5. 3.3.6.

   One motivation for restricting the NTLP to only peer-relationship
   scope is that if there are any options or variants in design approach
   - or, worse, in basic functionality - it is easier to manage the
   resulting complexity if it only impacts direct peers rather than
   potentially the whole Internet.

3.2.3 Core NTLP Functionality

   This section describes the basic functionality to be supported by the
   NTLP. Note that  Bypassing Intermediate Nodes

   Because the overall NSIS problem includes multiple signaling solution applications, it
   is very likely that a particular NSLP will always only be the
   result implemented on a
   subset of joint NSLP and NTLP operation; for example, we can always
   assume that an NSLP is operating above the NTLP and taking care of
   end-to-end issues (e.g. recovery of messages after restarts).

   Therefore, NTLP functionality is essentially just efficient upstream
   and downstream peer-peer message delivery, NSIS-aware nodes on a path, as shown in Figure 5. In
   addition, a wide variety of
   network scenarios. Message delivery includes the act of locating
   and/or selecting which NTLP peer node inside an aggregation region will still wish to carry out
   ignore signaling exchanges
   with messages which are per-flow, even if they are for a specific data flow. This discovery might be an active
   signaling application which the node is able to process (using specific in general.

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

               Figure 5: Signaling with Heterogeneous NSLPs
   Where signaling packets) or a passive messages traverse such NSIS-aware intermediate nodes,
   it is desirable to process (a
   side effect of using a particular addressing mode). them at the lowest level possible (in
   particular, on the fastest path). In addition, order to offer a non-trivial
   message transfer service (in terms of security, reliability and so
   on) to the peer NSLP nodes, it
   appears is important that the NTLP can sensibly carry at intermediate
   nodes is as transparent as possible, that is, it carries out minimal
   processing. In addition, if intermediate nodes have to do slow-path
   processing of all NSIS messages, this eliminates many of the functions scaling
   benefits of
   enabling signaling messages to pass through middleboxes, since this aggregation, unless tunneling is closely related to used.

   Considering first the problem case of routing the signaling messages
   in sent with the first place. Further details about NTLP functionality router alert
   option, there are
   contained in sections 3.2.4 and 4.3.

3.2.4 State Management Functionality

   Internet signaling requires the existence and management two complementary methods to achieve this bypassing
   of state
   within intermediate NEs:

   *) At the network for several reasons. This section describes how
   state management functionality is split across the NSIS layers.

   0. How the NTLP internal state is managed is IP layer, a matter for its design
   and indeed implementation.

   1. Conceptually, the NTLP provides set of protocol numbers can be used, or a uniform message delivery
   service. It is unaware range
   of the difference values in state semantics between
   different types of signaling application message (e.g. whether a
   message changes or just refreshes signaling application state, or
   even has nothing to with signaling application state at all).

   2. An NTLP instance processes and if necessary forwards all signaling
   application the router alert option. In this way, messages "immediately". (It might offer different service
   classes, but these would can be distinguished e.g. by reliability or
   priority, not state aspects.)
   marked with an implied granularity, and routers can choose to apply
   further slow-path processing only to configured subsets of messages.
   This means that is the method used in [10] to distinguish per-flow and per-
   aggregate signaling.

   *) The NTLP does not know
   explicit timer or message sequence information for could process the signaling
   application; and message but determine that there was no
   local signaling application messages pass immediately
   through an NSLP-unaware node (they can't it was relevant to. At this stage, the
   message can be jittered there, or re-
   sent onto alternative paths if re-routing takes place later).

   3. Within any node, it's an implementation decision whether returned unchanged to
   generate/jitter/filter refreshes either separately within each
   signaling application that needs this functionality, or as part of
   generic/shared code (a "soft-state management toolbox") more closely
   associated with the NTLP. The choice doesn't affect IP layer for normal
   forwarding; the NTLP
   specification at all. Implementations might piggy-back NTLP soft-
   state refresh information (if intermediate NE has effectively chosen to be
   transparent to the NTLP works this way) on signaling
   application messages, or even combine soft-state management between
   layers. The state machines message in question.

   In both cases, the existence of the NTLP and NSLPs remain logically
   independent, but an implementation intermediate NE is free to allow them to interact
   to reduce totally hidden
   from the load on NSLP nodes. If later stages of the network to signaling use directly
   addressed messages (e.g. for reverse routing), they will not involved
   the same level intermediate NE at all, except perhaps as would be
   achieved by a monolithic model.

   4. It normal router.

   There may be helpful for signaling applications to receive state-
   management related 'triggers' from cases where the NTLP, that a peer has failed
   or become available ("down/up notifications"). These triggers intermediate NE would like to do some
   restricted protocol processing, for example:
   *) Translating addresses in message payloads (compare section 4.6.1);
   note this would have to be about adjacent NTLP peers, rather than done to messages passing both directions
   through a node.
   *) Updating signaling application
   peers. We payloads with local status
   information (e.g. path property measurement inside a domain).
   If this can consider be done without fully terminating the NSIS protocols,
   this as another case would allow a more lightweight implementation of route change
   detection/notification (which the
   intermediate NE, and a more direct 'end-to-end' NTLP association
   between the peer NSLPs where the signaling application is also allowed to do anyway).
   However, apart from generating such triggers, fully
   processed. On the NTLP takes no
   action itself on such events, other than hand, this is only possible with a limited
   class of possible NTLP designs, and makes it harder for the NTLP to ensure that subsequent
   signaling
   offer a security service (since messages are correctly routed.

   5. have to be partially
   protected). The existence feasibility of these triggers doesn't replace NSLP refreshes as
   the mechanism for maintaining liveness at the signaling application
   level. In this sense, up/down notifications are advisories which
   allow faster reaction to events in the network, but shouldn't approach will be
   built into NSLP semantics. (This is essentially the same distinction
   - with evaluated during
   the same rationale - as SNMP makes between traps and normal
   message exchanges.)

3.2.5 Path De-Coupled Operation

   Path-decoupled signaling is defined as signaling for state
   installation along NTLP design.

3.2.4  Core NTLP Functionality

   This section describes the data path, without basic functionality to be supported by the restriction of passing
   only through nodes
   NTLP. Note that are located on the data path. Signaling
   messages can overall signaling solution will always be routed to nodes off the data path, but which are
   (presumably) aware
   result of it. This allows a looser coupling between
   signaling joint NSLP and data plane nodes, e.g. at NTLP operation; for example, we can always
   assume that an NSLP is operating above the autonomous system level.

   The main advantages of path-decoupled signaling are ease of
   deployment NTLP and support taking care of additional functionality. The ease
   end-to-end issues (e.g. recovery of
   deployment comes from messages after restarts).

   Therefore, NTLP functionality is essentially just efficient upstream
   and downstream peer-peer message delivery, in a restriction wide variety of
   network scenarios. Message delivery includes the number of impacted nodes
   in case act of deployment locating
   and/or upgrade of an NSLP. It would allow, selecting which NTLP peer to carry out signaling exchanges
   with for
   instance, deploying a solution without upgrading any of the routers
   in the specific data plane. Additional functionality that can flow. This discovery might be supported
   includes the use of off-path proxies to support authorization or
   accounting architectures.

   There are potentially significant differences in the way that the two an active
   process (using specific signaling paradigms should be analyzed. Using packets) or a single centralized
   off-path NE may increase the requirements in terms passive process (a
   side effect of message
   handling; on using a particular addressing mode). In addition, it
   appears that the other hand, path-decoupled signaling is equally
   applicable to distributed off-path entities. Failure recovery
   scenarios need to be analyzed differently because fate-sharing
   between data and control plane NTLP can no longer be assumed. Furthermore,
   the interpretation of sender/receiver orientation becomes less
   natural. With the local operation of NTLP, the impact sensibly carry out many of path-
   decoupled signaling on the routing functions of
   enabling signaling messages to pass through middleboxes, since this
   is
   presumably restricted closely related to the problem of peer determination. The
   assumption that routing the off-path NSIS nodes are loosely tied to signaling messages
   in the data
   path suggests, however, that peer determination can still be based on
   L3 routing information. This means that a path-decoupled first place. Further details about NTLP functionality are
   contained in sections 3.2.5 and 4.3.

3.2.5  State Management Functionality

   Internet signaling
   solution could be implemented using a lower layer protocol presenting requires the same service interface to NSLPs as existence and management of state
   within the path-coupled NTLP.

3.3 Signaling Application Properties

   It is clear that many signaling applications will require specific
   protocol behavior in their NSLP. network for several reasons. This section outlines some of describes how
   state management functionality is split across the
   options NSIS layers. (Note
   that how the NTLP internal state is managed is a matter for NSLP behavior; further work on selecting from these
   options would depend on detailed analysis of its
   design and indeed implementation.)

   1. Conceptually, the signaling
   application in question.

3.3.1 Sender/Receiver Orientation

   In some signaling applications, NTLP provides a node at one end uniform message delivery
   service. It is unaware of the data flow
   takes responsibility for requesting special treatment - such as difference in state semantics between
   different types of signaling application message (e.g. whether a
   resource reservation - from the network. Which end may depend on the
   message changes or just refreshes signaling application, application state, or characteristics of the network deployment.

   A sender-initiated approach is when the sender of the data flow
   requests and maintains the treatment for that flow. In a receiver-
   initiated approach the receiver of the data flow requests and
   maintains the treatment for that flow. The NTLP itself
   even has no freedom
   in this area: next NTLP peers have to be discovered in the sender nothing to
   receiver direction, but after that time the default assumption is
   that with signaling is possible both upstream application state at all).

   2. An NTLP instance processes and downstream (unless
   possibly a if necessary forwards all signaling
   application specifically indicates this is messages "immediately". (It might offer different service
   classes, but these would be distinguished e.g. by reliability or
   priority, not
   required). state aspects.) This implies means that backward routing state must be
   maintained by the NTLP does not know
   explicit timer or that backward routing message sequence information must be
   available in for the signaling message.

   The sender
   application; and receiver initiated approaches have several differences
   in their operational characteristics. The main ones are as follows:

   *) In a receiver-initiated approach, the that signaling application messages traveling
   from the receiver pass immediately
   through an NSLP-unaware node (their timing cannot be jittered there,
   nor can messages be stored up to the sender must be backward routed such re-sent on a new paths in case of
   a later re-routing event).

   3. Within any node, it is an implementation decision whether to
   generate/jitter/filter refreshes either separately within each
   signaling application that
   they follow exactly needs this functionality, or to integrate
   it with the same path NTLP implementation as was followed by a generic "soft-state management
   toolbox"; the signaling
   messages belonging to choice doesn't affect the same flow traveling from NTLP specification at all.
   Implementations might piggy-back NTLP soft-state refresh information
   (if the sender to NTLP works this way) on signaling application messages, or
   even combine soft-state management between layers. The state machines
   of the
   receiver. In a sender-initiated approach, provided acknowledgements NTLP and notifications can be securely delivered to the sending node,
   backward routing NSLPs remain logically independent, but an
   implementation is not necessary, and nodes do not have free to maintain
   backward routing state.
   *) In a sender-initiated approach, a mobile node can initiate a
   reservation for its outgoing flows as soon as it has moved allow them to another
   roaming subnetwork. In a receiver-initiated approach, a mobile node
   has interact to inform reduce the receiver about its handover, thus allowing load
   on the
   receiver network to initiate the same level as would be achieved by a reservation monolithic
   model.

   4. It may be helpful for these flows. For incoming
   flows, the reverse argument applies.
   *) A sender- (receiver-) initiated approach will allow faster setup
   and modification if the sender (receiver) is also authorized signaling applications to carry
   out the operation. A mismatch between authorizing and initiating NEs
   will cause additional message exchanges either in receive state-
   management related 'triggers' from the NSLP or in a
   protocol executed prior to NSIS invocation. Note NTLP, that a peer has failed
   or become available ("down/up notifications"). These triggers would
   be about adjacent NTLP peers, rather than signaling application
   peers. We can consider this may
   complicate modifications as another case of network control state for existing flows.
   *) Where route change
   detection/notification (which the signaling NTLP is looking for the last (nearest also allowed to receiver)
   NE do anyway).
   However, apart from generating such triggers, the NTLP takes no
   action itself on such events, other than to ensure that subsequent
   signaling messages are correctly routed.

   5. The existence of these triggers doesn't replace NSLP refreshes as
   the mechanism for maintaining liveness at the data path, receiver oriented signaling is most efficient;
   sender orientation would be possible, but take more messages.
   *) application
   level. In either case, this sense, up/down notifications are advisories which
   allow faster reaction to events in the initiator can generally network, but shouldn't be informed faster
   about reservation failures than
   built into NSLP semantics. (This is essentially the remote end.

3.3.2 Uni- same distinction
   - with the same rationale - as SNMP makes between traps and Bi-Directional normal
   message exchanges.)

3.2.6  Path De-Coupled Operation

   For some

   Path-decoupled signaling applications and scenarios, is defined as signaling may only be
   considered for a unidirectional data flow. However, in other cases,
   there may be interesting relationships between state
   installation along the signaling for data path, without the
   two flows restriction of a bi-directional session; an example is QoS for a voice
   call. Note passing
   only through nodes that are located on the path in the two directions may differ due to
   asymmetric routing. In the basic case, bi-directional signaling data path. Signaling
   messages can
   simply use a separate instance of the same signaling mechanism in
   each direction.

   In constrained topologies where parts of the route are symmetric, it
   may be possible to use a more unified approach routed to bi-directional
   signaling, e.g. carrying nodes off the two signaling directions in common
   messages. data path, but which are
   (presumably) aware of it. This optimization might be used for example to make mobile
   QoS allows a looser coupling between
   signaling more efficient.

   In either case, and data plane nodes, e.g. at the correlation autonomous system level.

   The main advantages of the path-decoupled signaling for are ease of
   deployment and support of additional functionality. The ease of
   deployment comes from a restriction of the two flow
   directions is carried out number of impacted nodes
   in the case of deployment and/or upgrade of an NSLP. The NTLP would simply be
   enabled to bundle the messages together.

3.3.3 Heterogeneous Operation It is likely that the appropriate way to describe the state NSIS is
   signaling would allow, for will vary from one part
   instance, deploying a solution without upgrading any of the network to another
   (depending on signaling application). For example routers
   in the QoS case,
   resource descriptions data plane. Additional functionality that are valid for inter-domain links will
   probably can be different from those useful for intra-domain operation
   (and supported
   includes the latter will differ from one domain use of off-path proxies to another).

   One support authorization or
   accounting architectures.

   There are potentially significant differences in the way to address this issue is to consider that the state description
   used within two
   signaling paradigms should be analyzed. Using a single centralized
   off-path NE may increase the NSLP as carried requirements in globally-understood objects and
   locally-understood objects. The local objects are only terms of message
   handling; on the other hand, path-decoupled signaling is equally
   applicable for
   intra-domain signaling, while to distributed off-path entities. Failure recovery
   scenarios need to be analyzed differently because fate-sharing
   between data and control plane can no longer be assumed. Furthermore,
   the global objects are mainly used in
   inter-domain signaling. Note that interpretation of sender/receiver orientation becomes less
   natural. With the local objects are still part operation of NTLP, the protocol but are inserted, used and removed by one single domain.

   The purpose impact of this division path-
   decoupled signaling on the routing of signaling messages is
   presumably restricted to provide additional flexibility in
   defining the objects carried by the NSLP such problem of peer determination. The
   assumption that only the objects
   applicable in a particular setting off-path NSIS nodes are used. One approach for
   reflecting loosely tied to the distinction is data
   path suggests, however, that local objects could peer determination can still be put into
   separate local messages that are initiated and terminated within one
   single domain; an alternative is based on
   L3 routing information. This means that they a path-decoupled signaling
   solution could be "stacked" within implemented using a lower layer protocol presenting
   the same service interface to NSLPs as the path-coupled NTLP. A new
   message transport protocol (possibly derived from the path-coupled
   NTLP) would be needed, but NSLP messages that are used anyway for inter-domain signaling.

3.3.4 Peer-Peer specifications and End-End Relationships

   The assumption in this framework is that the NTLP will operate
   'locally', that is, just over inter-layer
   interaction would be unchanged from the scope of a single peer
   relationship. End-to-end operation path-coupled case.

3.3 Signaling Application Properties

   It is built up by concatenating these
   relationships. Non-local operation (if any) clear that many signaling applications will take place require specific
   protocol behavior in NSLPs.

   The peering relations may also have an impact on their NSLP. This section outlines some of the required amount
   options for NSLP behavior; further work on selecting from these
   options would depend on detailed analysis of state the signaling
   application in question.

3.3.1  Sender/Receiver Orientation

   In some signaling applications, a node at each NSIS entity. When direct interaction with remote
   peers is not allowed, it may be required to keep track one end of the path
   that data flow
   takes responsibility for requesting special treatment - such as a message has followed through
   resource reservation - from the network. This can be achieved
   by keeping per-flow state at Which end may depend on the NSIS entities
   signaling application, or by maintaining a
   record route object in characteristics of the messages.

   Note network deployment.

   A sender-initiated approach is when the sender of the data flow
   requests and maintains the treatment for that NSLP peers are not always NTLP peers (section 3.2.1). This
   has flow. In a number receiver-
   initiated approach the receiver of implications for the relationship between data flow requests and
   maintains the
   signaling layers, in treatment for that NSLP flow. The NTLP itself has no freedom
   in this area: next NTLP peers may depend on have to be discovered in the service
   provided by a concatenation of NTLP peer relationships rather than a
   single one, which makes it harder sender to depend strongly on some NTLP
   properties (e.g. channel security, reliability).

3.3.5 Acknowledgements and Notifications

   We are assuming
   receiver direction, but after that time the NTLP provides a simple message transfer
   service, and any acknowledgements or notifications it generates are
   handled purely internally (and apply within the scope of a single
   NTLP peer relationship).

   However, we expect default assumption is
   that some signaling applications will requires
   acknowledgements regarding the failure/success of state installation
   along the data path, is possible both upstream and downstream (unless
   possibly a signaling application specifically indicates this will be an NSLP function.

   Acknowledgements can is not
   required). This implies that backward routing state must be sent along
   maintained by the sequence of NTLP peer
   relationships towards or that backward routing information must be
   available in the signaling initiator, which relieves message.

   The sender and receiver initiated approaches have several differences
   in their operational characteristics. The main ones are as follows:

   *) In a receiver-initiated approach, the
   requirements on signaling messages traveling
   from the security associations that need receiver to the sender must be maintained backward routed such that
   they follow exactly the same path as was followed by NEs and can allow NAT traversal in both directions. (If this
   direction is towards the sender, it implies maintaining reverse
   routing state in signaling
   messages belonging to the NTLP). same flow traveling from the sender to the
   receiver. In certain circumstances (e.g. trusted
   domains), an optimization a sender-initiated approach, provided acknowledgements
   and notifications can be securely delivered to send acknowledgements directly to
   the signaling initiator outside the NTLP (see section 3.2.2).

   The semantics of the acknowledgement messages are of particular
   importance. An NE sending a message could assume responsibility for
   the entire downstream chain of NEs, indicating for instance the
   availability of reserved resources for the entire downstream path.
   Alternatively, the message could node,
   backward routing is not necessary, and nodes do not have to maintain
   backward routing state.
   *) In a more local meaning,
   indicating for instance that sender-initiated approach, a certain failure or degradation
   occurred at mobile node can initiate a particular point in the network.

   Notifications differ from acknowledgements because they are not
   (necessarily) generated in response to other signaling messages. This
   means that
   reservation for its outgoing flows as soon as it may not be obvious has moved to determine where another
   roaming subnetwork. In a receiver-initiated approach, a mobile node
   has to inform the notification
   should be sent. Other than that, receiver about its handover, thus allowing the same considerations apply as for
   acknowledgements. One useful distinction to make would be
   receiver to
   differentiate between notifications that trigger initiate a signaling action
   and others that don't. The security requirements reservation for these flows. For incoming
   flows, the latter are
   less stringent, which means they could reverse argument applies.
   *) In general, setup and modification will be sent directly to fastest if the NE
   they are destined node
   responsible for (provided this NE authorizing these actions can be determined).

3.3.6 Security initiate them directly
   within the NSLP. A mismatch between authorizing and Other AAA Issues

   In some cases it initiating NEs
   will be possible cause additional message exchanges either in the NSLP or in a
   protocol executed prior to achieve NSIS invocation. Depending on how the necessary level of
   authorization for a particular signaling security by using basic 'channel security' mechanisms [9]
   at the level application is done, this
   may favor either sender or receiver initiated signaling. Note that
   this may complicate modifications of network control state for
   existing flows.
   *) Where the NTLP, and the possibilities are described in
   section 4.7. In other cases, signaling applications may have specific
   security requirements, in which case they are free to invoke their
   own authentication and key exchange mechanisms and apply 'object
   security' is looking for the last (nearest to specific fields within receiver)
   NE on the NSLP data path, receiver oriented signaling is most efficient;
   sender orientation would be possible, but take more messages.
   *) In addition to authentication, either case, the authorisation (to manipulate
   network control state) has to initiator can generally be considered as functionality above informed faster
   about reservation failures than the NTLP level, since it will be entirely application specific.
   Indeed, authorisation decisions remote end.

3.3.2  Uni- and Bi-Directional Operation

   For some signaling applications and scenarios, signaling may only be handed off to
   considered for a third party unidirectional data flow. However, in other cases,
   there may be interesting relationships between the protocol (e.g. signaling for QoS, the resource management function as
   described in section 6.1.5). Many different authorisation models are
   possible, and the variations impact:
   *) what message
   two flows take place - for example, whether authorisation
   information is carried along with of a control state modification
   request, or bi-directional session; an example is sent in QoS for a voice
   call. Note that the reverse direction path in response to it;
   *) what administrative relationships are 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 places no
   constraints on two directions may differ due to
   asymmetric routing. In the direction or order in which basic case, bi-directional signaling applications can send messages, these authorisation aspects are left open to be
   defined by
   simply use a separate instance of the same signaling mechanism in
   each NSLP. Further background discussion direction.

   In constrained topologies where parts of this issue is
   contained the route are symmetric, it
   may be possible to use a more unified approach to bi-directional
   signaling, e.g. carrying the two signaling directions in [10].

4 The NSIS Transport Layer Protocol common
   messages. This section describes the overall functionality required from optimization might be used for example to make mobile
   QoS signaling more efficient.

   In either case, the
   NTLP. It mentions possible protocol components within correlation of the NTLP layer
   and signaling for the different possible addressing modes that can be utilized, as
   well as two flow
   directions is carried out in the assumed transport and state management functionality. NSLP. The
   interfaces between NTLP and the layers above and below it are
   identified, with a description of would simply be
   enabled to bundle the identity elements that appear
   on these interfaces. messages together.

3.3.3  Heterogeneous Operation

   It is not likely that the intention of this discussion appropriate way to design describe the NTLP or even
   to enumerate design options, although some are included as examples.
   The goal state NSIS is to provide a general discussion
   signaling for will vary from one part of required functionality
   and the network to highlight some of another
   (depending on signaling application). For example in the issues associated with this.

4.1 Internal Protocol Components

   The NTLP includes all functionality below the signaling application
   layer and above the IP layer. The functionality QoS case,
   resource descriptions that are valid for inter-domain links will
   probably be different from those useful for intra-domain operation
   (and the latter will differ from one domain to another).

   One way to address this issue is required to consider the state description
   used within the NTLP is outlined in section 3.2.3, with some more details NSLP as carried in sections 3.2.4 globally-understood objects and 4.3.

   Some NTLP functionality could be provided via components operating as
   sublayers within
   locally-understood objects. The local objects are only applicable for
   intra-domain signaling, while the NTLP design.  For example, if specific transport
   capabilities global objects are required, such as congestion avoidance,
   retransmission, security and so on, then existing protocols, such as
   TCP+TLS or DCCP+IPsec, could be incorporated into mainly used in
   inter-domain signaling. Note that the NTLP. This
   possibility is not required or excluded local objects are still part of
   the protocol but are inserted, used and removed by one single domain.

   The purpose of this framework.

   If peer-peer addressing (section 4.2) division is used for some messages, then
   active next-peer discovery functionality will be required within the
   NTLP to support provide additional flexibility in
   defining the explicit addressing of these messages. This could
   use message exchanges for dynamic peer discovery as objects carried by the NSLP such that only the objects
   applicable in a sublayer within particular setting are used. One approach for
   reflecting the NTLP; there distinction is that local objects could also be put into
   separate local messages that are initiated and terminated within one
   single domain; an interface to external mechanisms to
   carry out this function.

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

                   Figure 6: Options for NTLP Structure

4.2 Addressing

   There alternative is that they could be "stacked" within
   the NSLP messages that are two ways to address used anyway for inter-domain signaling.

3.3.4  Aggregation

   It is a well known problem that per-flow signaling message being transmitted
   between NTLP peers:
    *) peer-peer, where in large-scale
   networks present scaling challenges because of the message is addressed to a neighboring NSIS
   entity large number of
   flows that is known to be closer to may traverse individual nodes.

   The possibilities for aggregation at the destination NE.
    *) end-to-end, where level of the message NTLP are quite
   limited; the primary scaling approach for path-coupled signaling is addressed
   for a signaling application to the flow
   destination directly, group flows together and intercepted by an intervening NE.

   With peer-peer addressing, an NE will determine the address of perform
   signaling for the
   next NE based on aggregate, rather than for the payload flows individually.
   The aggregate may be created in a number of ways: for example, the message (and potentially on the
   previous NE). This requires the address of
   individual flows may be sent down a tunnel, or given a common DSCP
   marking. The aggregation and deaggregation points perform per flow
   signaling, but nodes within the destination NE to aggregation region should only be
   derivable from
   forced to process signaling messages for the information present in aggregate, somehow
   ignoring the payload, either by
   using some local routing table or through participation per-flow signaling (see section 3.2.3).

   Individual NSLPs will need to specify what aggregation means in active
   peer discovery message exchanges.  Peer-peer addressing inherently
   supports tunneling of messages between NEs, their
   context, and how it should be performed. For example, in the QoS
   context it is equally applicable possible to add together the path-coupled and path-decoupled cases. resources specified in a
   number of separate reservations. In the case of end-to-end addressing, the message is addressed other applications,
   such as signaling to the
   data flow receiver, NATs and (some of) firewalls, the NEs along the data path
   intercept feasibility (and even
   the messages.  The routing meaning) of the messages should follow
   exactly the same path as the associated data flow (but see section
   5.1.1 on this point). Note that securing messages sent this way
   raises some interesting security issues (these are discussed in [4]).

   It aggregation is not possible at less clear.

3.3.5  Peer-Peer and End-End Relationships

   The assumption in this stage to mandate one addressing mode or
   the other. Indeed, each framework is necessary for some aspects of that the NTLP
   operation: in particular, initial discovery of will operate
   'locally', that is, just over the next downstream scope of a single peer
   relationship. End-to-end operation is built up by concatenating these
   relationships. Non-local operation (if any) will usually require end-to-end addressing, whereas reverse
   routing will always require peer-peer addressing. For other message
   types, take place in NSLPs.

   The peering relations may also have an impact on the choice is a matter required amount
   of protocol design. The mode used state at each NSIS entity. When direct interaction with remote
   peers is not visible allowed, it may be required to keep track of the NSLP, and the information needed in each case is
   available from path
   that a message has followed through the network. This can be achieved
   by keeping per-flow state at the flow identifier (section 4.6.1) or locally stored
   NTLP state.

4.3 Classical Transport Functions

   The NSIS signaling protocols entities or by maintaining a
   record route object in the messages.

3.3.6  Acknowledgements and Notifications

   We are responsible for transporting
   (signaling) data around assuming that the network; in general, this requires
   functionality such as congestion management, reliability, NTLP provides a simple message transfer
   service, and so on.
   This section discusses how much any acknowledgements or notifications it generates are
   handled purely internally (and apply within the scope of a single
   NTLP peer relationship).

   However, we expect that some signaling applications will require
   acknowledgements regarding the failure/success of state installation
   along the data path, and this functionality should will be
   provided within an NSLP function.

   Acknowledgements can be sent along the NTLP. It appears sequence of NTLP peer
   relationships towards the signaling initiator, which relieves the
   requirements on the security associations that need to be maintained
   by NEs and can allow NAT traversal in both directions. (If this doesn't affect
   direction is towards the
   basic way sender, it implies maintaining reverse
   routing state in which the NSLP/NTLP layers relate to each other NTLP). In certain circumstances (e.g. in
   terms of trusted
   domains), an optimization can be to send acknowledgements directly to
   the signaling initiator outside the NTLP (see section 3.2.2).

   The semantics of the inter-layer interaction); it is much
   more acknowledgement messages are of particular
   importance. An NE sending a question message could assume responsibility for
   the entire downstream chain of NEs, indicating for instance the overall performance/complexity tradeoff
   implied by placing certain functions within each layer.

   The following functionality is assumed to lie within the NTLP:
   1. Bundling together
   availability of small messages (comparable to [11]) can be
      provided locally by reserved resources for the NTLP as an option if desired; it doesn't
      affect entire downstream path.
   Alternatively, the operation of message could have a more local meaning,
   indicating for instance that a certain failure or degradation
   occurred at a particular point in the network elsewhere. The NTLP should
      always support unbundling, network.

   Notifications differ from acknowledgements because they are not
   (necessarily) generated in response to avoid the cost of negotiating the
      feature as an option. Note other signaling messages. This
   means that end-to-end addressed messages for
      different flows cannot it may not be bundled safely unless obvious to determine where the next node on notification
   should be sent. Other than that, the outgoing interface is known same considerations apply as for
   acknowledgements. One useful distinction to make would be NSIS-aware.
   2. Message fragmentation should to
   differentiate between notifications that trigger a signaling action
   and others that don't. The security requirements for the latter are
   less stringent, which means they could be provided by sent directly to the NTLP when needed.
      For NSLPs that generate large messages, NE
   they are destined for (provided this NE can be determined).

3.3.7  Security and Other AAA Issues

   In some cases it will be necessary possible to
      fragment them efficiently within achieve the network, where necessary level of
   signaling security by using basic 'channel security' mechanisms [11]
   at the use level of IP
      fragmentation may lead to reduced reliability the NTLP, and be incompatible
      with some addressing schemes. To avoid imposing the cost of
      reassembly on intermediate nodes, the fragmentation scheme used
      should allow for possibilities are described in
   section 4.7. In other cases, signaling applications may have specific
   security requirements, in which case they are free to invoke their
   own authentication and key exchange mechanisms and apply 'object
   security' to specific fields within the independent forwarding of individual
      fragments towards a node hosting an interested NSLP.

   The placement of NSLP messages.

   In addition to authentication, the following authorisation (to manipulate
   network control state) has to be considered as functionality is still open:
   1. Overload detection and control. Here, the question is whether above
   the NTLP should include common mechanisms level, since it will be entirely application specific.
   Indeed, authorisation decisions may be handed off to handle overload at the
      IP layer ("congestion control") and NTLP/NSLP layers (loosely
      "flow control"). The arguments here are complex and somewhat
      interrelated; a temporary summary can be found third party in [12].
   2. Local retransmission to improve reliability. The argument
   the protocol (e.g. for QoS, the resource management function as
   described in
      favor is that section 6.1.4). Many different authorisation models are
   possible, and the NTLP can recover from congestive loss variations impact:
   *) what message flows take place - for example, whether authorisation
   information is carried along with a control state modification
   request, or
      corruption much more rapidly than end-to-end (NSLP) mechanisms;
      the argument against is that the additional complexity sent in the
      NTLP is not needed reverse direction in response to it;
   *) what administrative relationships are required - for all example,
   whether authorisation takes place only between peer signaling applications. (It's assumed
      that
   applications, or over longer distances.

   Because the NTLP is 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 the NSLP.) In-order message delivery
      and duplicate detection are related functions.
   3. Message summarization. Benefits have been found (see [11]) in
      having the signaling protocol transport operates only 'tags' for refresh
      signaling messages rather than the full messages themselves. In between adjacent peers, and places no
   constraints on the more flexible NSIS direction or order in which signaling environment, it is not clear if
      this functionality applications
   can be provided correctly by the NTLP, or
      whether it has send messages, these authorisation aspects are left open to be done (less efficiently)
   defined by each NSLP.
   These open issues will be resolved in a future version Further background discussion of this
   document.

4.4 Lower issue is
   contained in [12].

4 The NSIS Transport Layer Interfaces Protocol

   This section describes the overall functionality required from the
   NTLP. It mentions possible protocol components within the NTLP layer
   and the different possible addressing modes that can be utilized, as
   well as the assumed transport and state management functionality. The
   interfaces between NTLP interacts and the layers above and below it are
   identified, with 'lower layers' a description of the protocol stack for identity elements that appear
   on these interfaces.

   It is not the
   purposes intention of sending and receiving signaling messages. This framework
   places this discussion to design the lower boundary NTLP or even
   to enumerate design options, although some are included as examples.
   The goal is to provide a general discussion of required functionality
   and to highlight some of the issues associated with this.

4.1 Internal Protocol Components

   The NTLP at includes all functionality below the signaling application
   layer and above the IP layer. The interface
   to the lower layer functionality that is therefore very simple:
   *) The NTLP sends raw IP packets
   *) The NTLP receives raw IP packets. In the case of peer-peer
   addressing, they have been addressed directly to it. In required
   within the case of
   end-to-end addressing, this will be achieved by intercepting packets
   that have been marked NTLP is outlined in section 3.2.4, with some special way (by special protocol number
   or by some option interpreted more details
   in sections 3.2.5 and 4.3.

   Some NTLP functionality could be provided via components operating as
   sublayers within the IP layer, NTLP design.  For example, if specific transport
   capabilities are required, such as the Router
   Alert option [13] and [14]).
   *) The NTLP receives indications from the IP layer regarding route
   changes congestion avoidance,
   retransmission, security and similar events (see section 5.1).

   For correct message routing, so on, then existing protocols, such as
   TCP+TLS or DCCP+IPsec, could be incorporated into the NTLP needs to have NTLP. This
   possibility is not required or excluded by this framework.

   If peer-peer addressing (section 4.2) is used for some information
   about link and IP layer configuration of messages, then
   active next-peer discovery functionality will be required within the local networking stack.
   In general, it needs to know how
   NTLP to select support the outgoing interface explicit addressing of these messages. This could
   use message exchanges for dynamic peer discovery as a signaling message, where this must match the interface that will be
   used by sublayer within
   the corresponding flow. This might NTLP; there could also be as simple as just
   allowing the IP layer an interface to handle the message using its own routing
   table. external mechanisms to
   carry out this function.

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

                   Figure 6: Options for NTLP Structure

4.2 Addressing

   There are two ways to address a signaling message being transmitted
   between NTLP peers:
    *) peer-peer, where the message is no intention addressed to do something different a neighboring NSIS
   entity that is known to be closer to the destination NE.
    *) end-to-end, where the message is addressed to the flow
   destination directly, and intercepted by an intervening NE.

   With peer-peer addressing, an NE will determine the address of the
   next NE based on the payload of the message (and potentially on the
   previous NE). This requires the address of the destination NE to be
   derivable from IP the information present in the payload, either by
   using some local routing (for table or through participation in active
   peer discovery message exchanges.  Peer-peer addressing inherently
   supports tunneling of messages between NEs, and is equally applicable
   to the path-coupled and path-decoupled cases.

   In the case of end-to-end addressing, the message is addressed messages); however, some hosts
   allow applications to bypass routing for their the
   data flows, flow receiver, and (some of) the
   NTLP processing must account for this. Further network layer
   information would be needed to handled scoped addresses (if such
   things ever will exist).

   Configuration NEs along the data path
   intercept the messages.  The routing of the messages should follow
   exactly the same path as the associated data flow (but see section
   5.1.1 on this point). Note that securing messages sent this way
   raises some interesting security issues (these are discussed in [3]).

   It is not possible at this stage to mandate one addressing mode or
   the other. Indeed, each is necessary for some aspects of NTLP
   operation: in particular, initial discovery of the next downstream
   peer will usually require end-to-end addressing, whereas reverse
   routing will always require peer-peer addressing. For other message
   types, the choice is a matter of protocol design. The mode used is
   not visible to the NSLP, and the information needed in each case is
   available from the flow identifier (section 4.6.1) or locally stored
   NTLP state.

4.3 Classical Transport Functions

   The NSIS signaling protocols are responsible for transporting
   (signaling) data around the network; in general, this requires
   functionality such as congestion management, reliability, and so on.
   This section discusses how much of this functionality should be
   provided within the NTLP. It appears that this doesn't affect the
   basic way in which the NSLP/NTLP layers relate to each other (e.g. in
   terms of the semantics of the inter-layer interaction); it is much
   more a question of the overall performance/complexity tradeoff
   implied by placing certain functions within each layer.

   Note that, following the discussion at the end of section 3.2.3,
   there may be cases where intermediate nodes wish to modify messages
   in transit even though they do not perform full signaling application
   processing. In this case, not all of the following functionality
   would be invoked at every intermediate node.

   The following functionality is assumed to lie within the NTLP:
   1. Bundling together of small messages (comparable to [13]) can be
      provided locally by the NTLP as an option if desired; it doesn't
      affect the operation of the network elsewhere. The NTLP should
      always support unbundling, to avoid the cost of negotiating the
      feature as an option. (The related function of refresh
      summarization - where objects in a refresh message are replaced
      with a reference to a previous message identifier - is left to
      NSLPs which can then do this in a way tuned to the state
      management requirements of lower layer operation the signaling application. Additional
      transparent compression functionality could be added to handle the NTLP
      design later as a local option.) Note that end-to-end addressed
      messages for different flows in particular
   ways cannot be bundled safely unless the
      next node on the outgoing interface is handled known to be NSIS-aware.
   2. Message fragmentation should be provided by the signaling application.

4.5 Upper Layer Services

   The NTLP offers transport layer services to higher layer signaling
   applications for two purposes: sending and receiving signaling
   messages, and exchanging control and feedback information. when needed.
      For sending and receiving NSLPs that generate large messages, two basic control primitives are
   required:
   *) Send Message, it will be necessary to allow
      fragment them efficiently within the signaling application to pass data to network, where the NTLP for transport.
   *) Receive Message, use of IP
      fragmentation may lead to allow reduced reliability and be incompatible
      with some addressing schemes. To avoid imposing the NTLP to pass received data to cost of
      reassembly on intermediate nodes, the fragmentation scheme used
      should allow for the independent forwarding of individual
      fragments towards a node hosting an interested NSLP.
   3. There can be significant benefits for signaling application.

   The NTLP and signaling application may applications if
      state-changing messages are delivered reliably (as introduced in
      [13] for RSVP; see also want the more general analysis of [14]). This
      does not change any assumption about the use of soft-state by
      NSLPs to exchange other
   control information, such as:
   *) Signaling application registration/de-registration, so that
   particular manage signaling application instances can register their
   presence with state, and leaves the
      responsibility for detecting and recovering from application
      layer error conditions in the transport layer. This may also require some
   identifier NSLP. However, it means that such
      functionality does not need to be agreed between tuned to handle fast recovery
      from message loss due to congestion or corruption in the NTLP lower
      layers, and signaling application to
   allow support also means that the exchange NTLP can prevent the
      amplification of further control information message loss rates caused by fragmentation.
      Reliable delivery functionality is invoked by the NSLP on a
      message-by-message basis and is always optional to use.
   4. The NTLP should not allow signaling messages to cause congestion
      in the de-multiplexing network (i.e. at the IP layer). Congestion could be caused
      by retransmission of incoming data.
   *) NTLP configuration, allowing lost signaling applications to indicate
   what optional NTLP features they want to use, and to configure NTLP
   operation, such as controlling what transport packets or by upper layer state should
      actions (e.g. a flood of signaling updates to recover from a
      route change). In some cases it may be
   maintained.
   *) Error messages, possible to allow engineer the NTLP to indicate error conditions
      network to
   the ensure that signaling application cannot overload it; in other
      cases, the NTLP would have to detect congestion and vice versa.
   *) Feedback information, such as route change indications so that adapt the
      rate at which it allows signaling application can decide what action messages to take.

4.6 Identity Elements

4.6.1 Flow Identification

   The flow identification is a method be transmitted.
      Principles of identifying a flow congestion control in a unique
   way.  All packets associated Internet protocols are given
      in [15]. The NTLP may or may not be able to detect overload in
      the control plane itself (e.g. an NSLP-aware node several NTLP-
      hops away which cannot keep up with the same flow will be identified by incoming message rate)
      and indicate this as a flow-control condition to local signaling
      applications. However, for both the congestion and overload
      cases, it is up to the same flow identifier. signaling applications themselves to adapt
      their behavior accordingly.

4.4 Lower Layer Interfaces

   The key aspect NTLP interacts with 'lower layers' of the flow identifier is
   to provide enough information such that protocol stack for the
   purposes of sending and receiving signaling flow receives messages. This framework
   places the same treatment along lower boundary of the data path as that actual data itself,
   i.e. consistent behavior is applied NTLP at the IP layer. The interface
   to the signaling and data flows
   by a NAT or policy-based forwarding engine.

   Information that could be used in flow identification may include: lower layer is therefore very simple:
   *) source The NTLP sends raw IP address; packets
   *) destination The NTLP receives raw IP address;
   *) protocol identifier and higher layer (port) addressing;
   *) flow label (typical for IPv6);
   *) SPI field for IPSec encapsulated data;
   *) DSCP/TOS field
   It is assumed that wildcarding on these identifiers is not needed
   (further analysis may packets. In the case of peer-peer
   addressing, they have been addressed directly to it. In the case of
   end-to-end addressing, this will be required).

   We've assumed here achieved by intercepting packets
   that the flow identification is not hidden have been marked in some special way (by special protocol number
   or by some option interpreted within the NSLP, but is explicitly part of IP layer, such as the NTLP. router
   alert option).
   *) 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 NTLP receives indications from the specific signaling
   application IP layer regarding route
   changes and similar events (see section 3.2.1): an example scenario would be
   messages passing through an addressing boundary where the flow
   identification had to be re-written.

4.6.2 Session Identification

   There are circumstances where it is important to be able to refer to
   signaling application state independently of the underlying flow. 5.1).

   For example, if correct message routing, the address of one NTLP needs to have some information
   about link and IP layer configuration of the flow endpoints changes due
   to a mobility event, local networking stack.
   In general, it is desirable needs to be able know how to change select the flow
   identifier without having to install a completely new reservation.
   The session identifier provides outgoing interface for
   a method to correlate the signaling
   about the different flows with message, where this must match the same network control state.

   The session identifier is essentially a signaling application
   concept, since it is only used in non-trivial state management
   actions that are application specific. However, we assume here interface that
   it should will be visible within
   used by the NTLP. corresponding flow. This enables it to might be used as simple as just
   allowing the IP layer to
   control handle the message using its own routing
   table. There is no intention to do something different from IP
   routing (for end-to-end addressed messages); however, some hosts
   allow applications to bypass routing for their data flows, and the
   NTLP behavior, processing must account for example, this. Further network layer
   information would be needed to handled scoped addresses (if such
   things ever will exist).

   Configuration of lower layer operation to handle flows in particular
   ways is handled by controlling how the signaling application.

4.5 Upper Layer Services

   The NTLP offers transport layer should forward packets belonging to this session (as opposed services to
   this higher layer signaling application).  In addition, the session identifier can
   be used by the NTLP to demultiplex received
   applications for two purposes: sending and receiving signaling messages
   between multiple instances of
   messages, and exchanging control and feedback information.

   For sending and receiving messages, two basic control primitives are
   required:
   *) Send Message, to allow the same signaling application, if such
   an operational scenario is supported (see section 4.6.3 for more
   information on signaling application identification).

   To be useful for mobility support, the session identifier should be
   globally unique, and it should not be modified end-to-end. It is well
   known that it is practically impossible to generate identifiers in a
   way which guarantees this property; however, using a large random
   number makes it highly likely. In any case, pass data to
   the NTLP ascribes no
   valuable semantics for transport.
   *) Receive Message, to allow the identifier (such as 'session ownership');
   this problem is left NTLP to pass received data to the
   signaling application, which application.

   The NTLP and signaling application may be able
   to secure it also want to use for this purpose.

4.6.3 exchange other
   control information, such as:

   *) Signaling Application Identification

   Since the NTLP can be used to support several NSLP types, there is a
   need to identify which type a application registration/de-registration, so that
   particular signaling message exchange
   is being used for. application instances can register their
   presence with the transport layer. This is may also require some
   identifier to be agreed between the NTLP and signaling application to
   allow support the exchange of further control information and to support:

   *) processing
   allow the de-multiplexing of incoming messages - the data.
   *) 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 able
   maintained.
   *) Error messages, to allow the NTLP to indicate error conditions to
   demultiplex these towards
   the appropriate signaling applications; application and vice versa.
   *) processing of general messages at an NSIS aware intermediate node
   - if the node does not handle Feedback information, such as route change indications so that the specific
   signaling application, it
   should be able to make a forwarding decision without having application can decide what action to parse
   upper layer information.

   No position take.

4.6 Identity Elements

4.6.1  Flow Identification

   The flow identification is taken on the form a method of identifying a flow in a unique
   way.  All packets associated with the signaling application
   identifier, or even same flow will be identified by
   the structure same flow identifier.  The key aspect of the flow identifier is
   to provide enough information such that the signaling application
   'space' - free-standing applications, potentially overlapping groups
   of capabilities, etc. These details should not influence flow receives
   the rest of
   NTLP design.

4.7 Security Properties 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 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 only security service required flow identification is not hidden within NTLP
   the NSLP, but is
   channel security. Channel security requires a security association to
   be established between explicitly part of the signaling endpoints, which NTLP. The justification for
   this is carried out
   via some authentication and key management exchange. This
   functionality could that it might be provided by reusing a standard protocol.

   In order valuable to protect be able to do NSIS processing
   even at a particular node which was unaware of the specific signaling exchange,
   application (see section 3.2.3): an example scenario would be
   messages passing through an addressing boundary where the NSIS entity
   needs flow
   identification had to select the security association that be re-written.

4.6.2  Session Identification

   There are circumstances where it has in place with
   the next NSIS entity that will is important to be receiving the able to refer to
   signaling message.
   The ease application state independently of doing this depends on the addressing model in use by underlying flow.
   For example, if the
   NTLP (see section 4.2).

   Channel security can provide many different types address of protection to
   signaling exchanges, including integrity and replay protection and
   encryption.  It is not clear which one of these is required at the NTLP
   layer, although most channel security mechanisms support them all.

   Channel security can also flow endpoints changes due
   to a mobility event, it is desirable to be applied able to change the flow
   identifier without having to install a completely new reservation.
   The session identifier provides a method to correlate the signaling messages with
   differing granularity, i.e. all or parts of
   about the signaling message may
   be protected.  For example, if different flows with the flow same network control state.

   The session identifier is traversing essentially a NAT, signaling application
   concept, since it is only the
   parts of the message used in non-trivial state management
   actions that do not need are application specific. However, we assume here that
   it should be visible within the NTLP. This enables it to be processed used to
   control NTLP behavior, for example, by controlling how the NAT transport
   layer should be protected. It is an open question as forward packets belonging to which parts of this session (as opposed to
   this signaling application).  In addition, the session identifier can
   be used by the NTLP to demultiplex received signaling messages need protecting, and what type
   between multiple instances of protection should be
   applied to each.

5 Interactions with Other Protocols

5.1 IP Routing Interactions

   The NSIS Transport Layer (NTLP) the same signaling application, if such
   an operational scenario is responsible supported (see section 4.6.3 for discovering the
   next node to more
   information on signaling application identification).

   To be visited by useful for mobility support, the signaling protocol. For path-coupled
   signaling, this next node session identifier should be one that will
   globally unique, and it should not be visited by the
   data flow. In practice, modified end-to-end. It is well
   known that it is practically impossible to generate identifiers in a
   way which guarantees this peer discovery will be approximate, as
   any node could use property; however, using a large random
   number makes it highly likely. In any feature of case, the NTLP ascribes no
   valuable semantics to the peer discovery packet identifier (such as 'session ownership');
   this problem is left to route
   it differently than the corresponding data flow packets. Divergence
   between data and signaling path can occur due application, which may be able
   to load sharing or load
   balancing (section 5.1.1). An example specific secure it to use for this purpose.

4.6.3  Signaling Application Identification

   Since the case of QoS NTLP can be used to support several NSLP types, there is
   given in section 6.1.1. Route changes cause a temporary divergence
   between the data path and the path on
   need to identify which type a particular signaling state has been
   installed. The occurrence, detection and impact of route changes is
   described in section 5.1.2. A description of this issue in the
   context of QoS message exchange
   is given in section 6.1.2.

5.1.1 Load Sharing and Policy-Based Forwarding

   Load sharing or load balancing being used for.  This is a network optimization technique
   that exploits the existence of multiple paths to support:
   *) processing of incoming messages - the same destination
   in order NTLP should be able to obtain benefits in terms of protection, resource
   efficiency or network stability. The significance of load sharing in
   demultiplex these towards the context appropriate signaling applications;
   *) processing of general messages at an NSIS is that, aware intermediate node
   - if the load sharing mechanism in use
   will forward packets node does not handle the specific signaling application, it
   should be able to make a forwarding decision without having to parse
   upper layer information.

   No position is taken on any basis other than the destination address,
   routing form of the signaling application
   identifier, or even the structure of the signaling messages using end-to-end addressing does application
   'space' - free-standing applications, potentially overlapping groups
   of capabilities, etc. These details should not
   guarantee that the messages will follow influence the data path. Policy-based
   forwarding for data packets - where rest of
   NTLP design.

4.7 Security Properties

   It is assumed that the outgoing link only security service required within NTLP is selected
   based on policy information about fields additional
   channel security. Channel security requires a security association 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 established between equal cost
   paths [15] or unequal cost paths. An example of the latter approach signaling endpoints, which is Optimized Multi Path (OMP). OMP discovers multiple paths, not
   necessarily equal cost paths, carried out
   via some authentication and key management exchange. This
   functionality could be provided by reusing a standard protocol.

   In order to any destinations in the network, but
   based on the load reported from protect a particular path, signaling exchange, the NSIS entity
   needs to select the security association that it determines
   which fraction has in place with
   the next NSIS entity that will be receiving the signaling message.
   The ease of doing this depends on the data to direct to addressing model in use by the given path. Incoming
   packets are subject
   NTLP (see section 4.2).

   Channel security can provide many different types of protection to a (source, destination address) hash
   computation,
   signaling exchanges, including integrity and effective load sharing replay protection and
   encryption.  It is accomplished by means not clear which of
   adjusting the hash thresholds. BGP [16][17] advertises the routes
   chosen by these is required at the BGP decision process NTLP
   layer, although most channel security mechanisms support them all.

   Channel security can also be applied to other BGP speakers. In the
   basic specification, routes signaling messages with
   differing granularity, i.e. all or parts of the same Network Layer reachability
   information (NLRI) as previously advertised routes implicitly replace signaling message may
   be protected.  For example, if the original advertisement, which means that multiple paths for flow is traversing a NAT, only the
   same prefix cannot exist. This restriction could
   parts of the message that do not need to be removed processed by
   suitable extensions to BGP.

   If the routing decision is based on both source and destination
   address, signaling and data flow packets may still diverge because of
   layer 4 load-balancing (based on protocol or port number). Such
   techniques would, however, constrain NAT
   should be protected (alternatively, if the use of proxies. Proxies
   would cause ICMP errors NAT takes part in NTLP
   security procedures, it only needs to be misdirected given access to the source of the data
   because of source address spoofing.

   If message
   fields containing addresses, often just the routing decision flow id). It is based on the complete five-tuple,
   divergence may still occur because an open
   question as to which parts of the presence NTLP messages need protecting, and
   what type of router alert
   options. In this case, the same constraint on proxy use applies as
   above. Additionally, it becomes difficult protection should be applied to each.

5 Interactions with Other Protocols

5.1 IP Routing Interactions

   The NTLP is responsible for determining the end systems next node to
   distinguish between data and be visited
   by the signaling packets. Finally, QoS routing
   techniques (section 6.1.3) may base protocol. For path-coupled signaling, this next node
   should be one that will be visited by the routing decision on data flow. In practice,
   this peer discovery will be approximate, as any field
   in the packet header (e.g. DSCP, ...).

   Most load-balancing techniques node could use the first n bytes any
   feature of the peer discovery packet
   header (including SA, DA and protocol field) in the hashing function.
   In this case, to route it differently from the above considerations regarding source/destination
   address
   corresponding data flow packets. Divergence between data and
   signaling path can occur due to load sharing or five-tuple based forwarding apply.

5.1.2 Route Changes

   In a routed network, each packet is independently routed based on its
   header information. Whenever a better route towards load balancing
   (section 5.1.1). An example specific to the destination
   becomes available, this route case of QoS is installed given in the forwarding table
   and will be used for all subsequent (data and signaling) packets.
   This can
   section 6.1.1. Route changes cause a temporary divergence between the
   data path along which state has
   been installed and the path along on which forwarding will actually take
   place.

   The possibility of route changes requires the presence of three
   processes in the signaling protocol
   1. route change detection
   2. installation of state on the new path
   3. removal of state on the old path

   Many route change detections methods can be used, some of which need
   explicit protocol support and some of which are implementation-
   internal. They differ in their speed of reaction has been installed.
   The occurrence, detection and the types of
   change they can detect. In rough order impact of increasing applicability,
   they can be summarized as:
   a) monitoring changes in local interface state
   b) monitoring network-wide topology route changes is described in a link-state routing
   protocol
   c) inference from changes
   section 5.1.2. A description of this issue in data packet TTL
   d) inference from loss the context of packet stream QoS is
   given in section 6.1.2.

5.1.1  Load Sharing and Policy-Based Forwarding

   Load sharing or load balancing is a downstream flow-aware
   router
   e) inference from changes network optimization technique
   that exploits the existence of multiple paths to the same destination
   in signaling packet TTL
   f) changed route order to obtain benefits in terms of a PATH-like (end-to-end addressed) signaling
   packet
   g) changed route protection, resource
   efficiency or network stability. The significance of a specific end-to-end addressed probe packet

   There are essentially three ways load sharing in which detection can happen: based
   the context of NSIS is that, if the load sharing mechanism in use
   will forward packets on network monitoring (method a-b), any basis other than the destination address,
   routing of signaling messages using end-to-end addressing does not
   guarantee that the messages will follow the data path. Policy-based
   forwarding for data packets - where the outgoing link is selected
   based on data policy information about fields additional to the packet monitoring
   (method c-d)
   destination address - has the same impact. Signaling and based on monitoring signaling protocol messages
   (method e-g). Methods contingent on monitoring signaling messages
   become less effective as refresh reduction data packets
   may diverge because of both of these techniques.

   Load balancing techniques are used.

   When a route change has have been detected, it is important that state is
   installed as quickly proposed for a number of routing
   protocols, such as possible along the new path. It is not
   guaranteed that OSPF equal cost paths [16] and others. Typically,
   based on the new path will be able to provide load reported from a particular path, load balancing
   determines which fraction of the same
   characteristics data to direct to that were available on the old path. In order to be
   able
   Incoming packets are subject to avoid duplicate state installation or, worse, rejection a (source, destination address) hash
   computation, and effective load sharing is accomplished by means of
   adjusting the hash thresholds.

   If signaling message packets are given source and destination addresses
   identical to data packets, signaling and data packets may still
   diverge because of previously installed state, it is
   important layer 4 load-balancing (based on protocol or port
   number). Such techniques would also cause ICMP errors to be able
   misdirected to recognize the new signaling message as
   belonging to an existing session. In this respect, we distinguish
   between route changes with associated change source of the flow
   identification (e.g. in case data because of a mobility event when the IP source
   might change) and route changes without change of the flow
   identification (e.g. address
   spoofing. If signaling packets are made identical in case of a link failure along the path). The
   former case requires an identifier independent from complete
   five-tuple, divergence may still occur because of the flow
   identification, i.e. presence of
   router alert options. In this case, the session identifier (section 4.6.2).

   When state has been installed along same ICMP misdirection
   applies. Additionally, it becomes difficult for the new path, end systems to
   distinguish between data and signaling packets. Finally, QoS routing
   techniques may base the existing state routing decision on any field in the old path needs to be removed. With packet
   header (e.g. DSCP, ...).

   Many load-balancing implementations use the soft-state principle,
   this will happen automatically because first n bytes of the lack of refresh
   messages. Depending
   packet header (including SA, DA and protocol) in the hash function.
   In this case, the general considerations above regarding SA/DA or
   five-tuple based forwarding continue to apply.

5.1.2  Route Changes

   In a connectionless network, each packet is independently routed
   based on its header information. Whenever a better route towards the refresh timer, however, it may be required
   to tear down
   destination becomes available, this state much faster (e.g. because it route is tied to an
   accounting record). In that case, installed in the teardown message needs to
   forwarding table and will be
   able to distinguish used for all subsequent (data and
   signaling) packets. This can cause a divergence between the new path
   along which state has been installed and the old path.

   The path along which
   forwarding will actually take place. (The problem of route changes would not occur is
   reduced if there was a way to do route pinning. pinning is performed. Route pinning refers to the
   independence of the path taken by certain data packets from
   reachability changes caused by routing updates from an Interior
   Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).

5.1.3 Router Redundancy

   In some environments,
   Nothing about NSIS signaling prevents route pinning being used as a
   network engineering technique, provided it is desired to provide connectivity and per
   flow or per class flow management with high-availability
   characteristics, i.e. with rapid transparent recovery even done in the
   presence of route changes. This may need interactions with protocols a way which are used to manage
   preserves the common routing in this case, such as VRRP [18].
   A future version of this document might consider interactions between
   NSIS signaling and such protocols data. However, even if
   route pinning is used, it cannot be depended on to support high availability functionality.

5.2 Mobility Interactions

   Mobility, prevent all route
   changes (for example in most cases, causes the case of link failures).

   Handling route changes to requires the presence of three processes in
   the data path that packets
   take.  Assuming that signaling has already taken place to establish
   some protocol:
   1. route change detection
   2. installation of state along on the data path, new signaling may be needed in order
   to (re)establish path
   3. removal of state along on the changed data path.

   The interactions between mobility old path

   Many route change detection methods can be used, some needing
   explicit protocol support and signaling protocols have been
   extensively analyzed in recent years, primarily some of which are implementation-
   internal. They differ in the context their speed of
   RSVP reaction and Mobile IP interaction (e.g. the mobility discussion of [7]),
   but also in the context of other types of network (e.g. [19]); a
   general review
   change they can detect. In rough order of the fundamental interactions is given increasing applicability,
   they can be summarized as:
   a) monitoring changes in [20],
   which provides further details on many of the subjects considered local interface state
   b) monitoring topology changes in
   these sections. This analysis work has shown that some difficulties a link-state routing protocol
   c) inference from changes in the interactions are quite deeply rooted data packet TTL
   d) inference from loss of packet stream in the detailed design a flow-aware router
   e) inference from changes in signaling packet TTL
   f) changed route of
   these protocols; however, the problems an end-to-end addressed signaling packet
   g) changed route of a specific end-to-end addressed probe packet

   These methods can be categorized as being based on network monitoring
   (method a-b), based on data packet monitoring (method c-d) and their based
   on monitoring signaling protocol messages (method e-g); method f is
   the baseline method of RSVP. Methods contingent on monitoring
   signaling messages become less effective as soft state refresh rates
   are reduced.

   When a route change has been detected, it is important that state is
   installed as quickly as possible solutions
   fall under five broad headings. The main issues for a resource
   signaling application are limiting the period after handovers during
   which along the resources are new path. It is not available along
   guaranteed that the path; and avoiding
   double reservations (reservations new path will be able to provide the same
   characteristics that were available on both the old and new path).
   Similar issues may apply path. In order to other types be
   able to avoid duplicate state installation or, worse, rejection of signaling 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 signaling may depend on end system addresses
   for forwarding signaling messages and defining flows (section 4.6.1),
   the special implications message because of mobility for addressing need previously installed state, it is
   important to be
   considered. The two possible approaches are able to recognize the new signaling message as follows:

   *) Use a
   belonging to an existing session. In this respect, we distinguish
   between route changes with associated change of the flow
   identification based on low level IP addresses (e.g.
   the Care of Address) and other 'standard' fields in case of a mobility event when the IP header.
   This makes least demands on the packet classification engines within source
   might change) and route changes without change of the network. However, it means that even on a part flow
   identification (e.g. in case of a link failure along the path). The
   former case requires an identifier independent from the flow path
   that is unchanged,
   identification, i.e. the session will need to be modified to reflect identifier (section 4.6.2). Mobility
   issues are discussed in more detail in section 5.2.

   When state has been installed along the new path, the changed flow identification (see section 5.2.3).

   *) Use a flow identification that does not change (e.g. based existing state
   on Home
   Address). This simplifies the problem of session update, at old path needs to be removed. With the
   likely cost soft-state principle,
   this will happen automatically because of considerably complicating the flow identification
   requirements and making stronger demands lack of refresh
   messages. Depending on packet classification.

   In the first approach, refresh timer, however, it may be required
   to prevent double reservation, NSIS entities
   need tear down this state much faster (e.g. because it is tied to an
   accounting record). In that case, the teardown message needs to be
   able to recognize that a session with distinguish between the new flow
   identifier path and the old path.

   In some environments, it is desired to be correlated provide connectivity and per
   flow or per class state management with an existing one. A session
   identifier (section 4.6.2) could be high-availability
   characteristics, i.e. with rapid transparent recovery even in the
   presence of route changes. This may need interactions with protocols
   which are used for to manage the routing in this purpose, case, such as VRRP [17].

   Our basic assumption about such interactions is that the NTLP would
   be responsible for detecting the route change and ensuring that
   signaling messages were re-routed appropriately along with data
   traffic; but it
   needs to have global semantics.

   While that the feasibility of further state re-synchronization (including
   failover between 'main' and 'standby' nodes in the first approach needs to high availability
   case) would be proven, the responsibility of the signaling application and
   its NSLP, possibly triggered by the NTLP.

5.2 Mobility and Multihoming Interactions

   The issues associated with mobility and multihoming are a
   generalization of the basic route change case of the previous
   section. As well as the fact that packets for a given session are no
   longer traveling over a single topological path, the impact following extra
   considerations arise:
   1) The use of requiring more sophisticated packet classifiers, it
   still seems more plausible than the second. This IP-layer mobility and multihoming means that signaling
   applications should define flows in terms of real, routable (care of)
   addresses rather more than virtual (home) addresses.

5.2.2 Localized Path Repair

   In any mobility approach, a handover
   one IP source or destination address will cause at least some changes
   in the path of upstream be associated with a single
   session. The same applies if application layer solutions (e.g. SIP-
   based approaches) are used.
   2) Mobile IP and downstream packets. At associated protocols use some point along special encapsulations
   for some segments of the joined path, an NSIS entity should be able to recognize this
   situation, based upon session identification. State needs to be
   installed on data path.
   3) The double route may persist for some time in the new path, and removed from network (e.g. in
   the old. Who triggers case of a 'make-before-break' handover being done by a multihomed
   host).
   4) Conversely, the
   new state re-routing may be constrained by which entities are authorised to
   carry out which state manipulations, which is then a signaling
   application question.

   A critical point here is rapid and routine (unlike
   network internal route changes), increasing the importance of rapid
   state release on old paths.

   The interactions between mobility and signaling that is used to discover have been extensively
   analyzed in recent years, primarily in the
   crossover node. This is a generalization context of RSVP and Mobile
   IP interaction (e.g. the problem mobility discussion of finding
   next-NSIS peer: it requires extending [6]), but also in the new path until it
   intersects
   context of other types of network (e.g. [18]); a general review of
   the old one. This fundamental interactions is easy for the uplink direction (where given in [19], which provides further
   details on many of the mobile is subjects considered in this section.

   We are assuming that the sender), but much harder for downlink without signaling via will refer to 'outer' IP headers
   when defining the correspondent. There flows it is no reason controlling. There two main reasons for
   this. The first is that the crossover
   node to data plane will usually be the same for uplink and downlink flows, even for the same
   correspondent. unable to work
   in terms of anything else when implementing per-flow treatment (e.g.
   we cannot expect a router will analyse inner headers to decide how to
   schedule packets). The problem second reason is discussed further in [21].

5.2.3 Update that we are implicitly
   relying on the Unchanged Path

   On security provided by the path between network infrastructure to
   ensure that the crossover node(s) and correct packets are given the correspondent, it special treatment being
   signaled for, and this is necessary to avoid, if possible, double reservations, but also to
   update built on the relationship between packet
   source and destination addresses and network control state to reflect new flow identification topology (this is needed, by
   essentially the default assumption of section 5.2.1).
   Examples of approaches same approach that could be is used to solve this problem are as the following:

   *) Use a session state identification basis of route
   optimization security in Mobile IPv6 [20]). The consequence of this
   assumption is that does not change even if we see the packet streams to (or from) different
   addresses as different flows, and where a flow definition changes (see Section 4.6.2). Signaling is still
   needed to update carried inside a changed
   tunnel this is seen as a different flow identification, but it should be
   possible again. The encapsulation
   issues (point (2) above) are therefore to avoid AAA and admission control processing.

   *) Use an NSIS-capable crossover router be handled the same way as
   other tunneling cases (section 5.4).

   The most critical aspect is therefore the fact that manages this update
   autonomously (more efficiently than multiple flows
   are being used, and the end nodes could), with
   similar considerations signaling for them needs to be correlated
   together. This is the local path repair case.

   Note that in intended role of the case session identifier (see
   section 4.6.2, which also describes some of the security requirements
   for such an address change, end to end message
   exchanges will be required identifier). Although the session identifier is visible
   at the NTLP, it is the signaling application layer anyway, which is responsible for
   performing the correlation (and doing so
   signaling securely). The NTLP
   responsibility is limited to update delivering the signaling messages for
   each flow identifier does not necessarily add to between the handover latency.

5.2.4 Interaction with Mobility Signaling

   In existing work on mobility protocol and correct signaling protocol
   interactions, several framework proposals describing application peers. The
   locations at which the protocol
   interactions have been made. Usually they have taken existing
   protocols (Mobile IP correlation takes place are the end system and RSVP respectively)
   the signaling application aware node in the network where the flows
   meet (this node is generally referred to as the starting point; "crossover router";
   it
   should can be noted that an NSIS protocol might operate anywhere in quite a
   different way. In this section, we provide an overview of how these
   proposals fit within the rest of this framework. The mobility aspects
   are described using MIP terminology, but are generally applicable to
   other network layer network).

   Although much work has been done in the past on finding the crossover
   router directly from information held in particular mobility solutions. The purpose
   signaling protocols, the initial focus of this overview NSIS work should be to have
   a solution which is not tightly bound to select any particular approach, but simply single mobility
   approach. In other words, it should be possible to point determine the
   crossover router based on NSIS signaling. (This doesn't rule out how
   they would fit into our framework and any major issues the
   possibility that some implementations may be able to do this
   discovery faster, e.g. by being tightly integrated with them.

   We can consider that two signaling processes are active: local
   mobility
   signaling and NSIS signaling. The discussion so far considered how
   NSIS signaling should operate. There management protocols; this is still a question of how directly comparable to
   spotting route changes in fixed networks by being routing aware.)

   Note that the
   interactions between crossover router discovery may involve end-to-end
   signaling exchanges (especially for flows towards the NSIS and mobility mobile or
   multihomed node) which raises a latency concern; on the other hand,
   end to end signaling should be
   considered.

   The basic case of totally independent specification will have been necessary in any case, both at
   the application level (to communicate changed addresses) and
   implementation can lead also to ambiguities and even interoperability
   problems. At least,
   update packet classifiers along the addressing and encapsulation issues path. It is a matter for
   mobility solutions that use virtual links or their equivalents need further
   analysis to decide how these exchanges could be specified combined or carried
   out in an implementation-neutral way.

   A type parallel.

   On the shared part of 'loose' integration the path, signaling is needed at least to have independent protocols, but
   to define how they trigger each other - in particular, how
   update the
   mobility protocol triggers sending of refresh/modify/tear messages. A
   pair of implementations could use these triggers packet classifiers to improve
   performance, primarily reducing latency. (Existing RSVP modifications
   consider include the closer interaction of making new flow, although if
   correlation with the RSVP implementation
   mobility routing aware, e.g. so it existing flow is able to localize refresh
   signaling; this would possible it should be a self contained aspect of NSIS.)

   An even tighter level possible
   to bypass any policy or admission control processing. State
   installation on the new path (and possibly release on the old one)
   are also required. Which entity (one of integration is the end hosts or the
   crossover router) controls all these procedures depends on which
   entities are authorised to consider a single protocol
   carrying both mobility and carry out network control state information.
   Logically, there are two cases:

   1.  Carry mobility routing information (a 'mobility object') in the
   signaling messages. (The prime purpose in manipulations, so
   this approach is to enable
   crossover router discovery.)
   2.  Carry signaling in the mobility messages, typically as a new
   extension header. In our framework, we could consider this therefore a special
   case matter of NSIS layering, with the mobility protocol playing signaling application and NSLP design.
   The approach may depend on the role sender/receiver orientation of the
   original signaling transport.

   Other modes of interaction might also (see section 3.3.1). In addition, in the mobility
   case, the old path may no longer be possible. The critical point
   with all these models is that directly accessible to the general solutions developed by NSIS
   should mobile
   node; inter-access-router communication may be independent of choice of mobility protocols. Tight
   integration would have major deployment issues especially required to release
   state in
   interdomain cases. Therefore, any tightly integrated solution is
   considered out of scope these circumstances.

   The frequency of initial development.

5.2.5 Interaction with Seamless Handover Protocols

   In handovers in some network types encourages the context
   consideration of mobility between different access routers, it is
   common to consider performance optimizations in two areas: fast handover support protocols, for selection of
   the optimal access router to handover to, hand over to (for example, [21]), 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
   is developing solutions for handover (for example, [22]). Both these protocols (CARD [22] and Context
   Transfer [23] respectively); alternative approaches
   procedures could have strong interactions with similar
   characteristics are also possible.

   As these solutions are still under development, it is premature to
   specify details signaling protocols,
   the former because a selection criterion might be what network
   control state could be supported on the interaction.  It is thought that Context
   Transfer transfers path through the new access
   router, the latter because signaling application state between access routers based upon changes
   caused by mobility.  NSIS or NTLP/NSLP
   protocol state may be a candidate for context transfer.  Such work, should it be undertaken, will be done
   in the Seamoby working group.

5.3 Interactions with NATs

   Because at least some messages will almost inevitably contain address
   addresses and possibly higher layer information as payload, we must
   consider the interaction with address translation devices (NATs). As well as
   These considerations apply both to 'traditional' NATs of various
   types (as defined in [24]) very similar
   considerations would apply to [23]) as well as some IPv4/v6 transition
   mechanisms such as SIIT [25]. [24].

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

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

   Note that all of this discussion is independent of the use of a
   specific NSLP for general control of NATs (and firewalls). This is
   considered in section 6.2.

5.4 Interactions with IP Tunneling

   Tunneling is used in the Internet for a number of reasons such as
   flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
   private networking, and so on. An NSIS solution must continue to work
   in the presence of these techniques, i.e. the presence of the tunnel
   should not cause problems for end-to-end signaling, and it should
   also be possible to use NSIS signaling to control the treatment of
   the packets carrying the tunneled data.

   It is assumed that the NSIS approach will be similar to that of [26],
   where the signaling for the end-to-end data flow is tunneled along
   with that data flow, and is invisible to nodes along the path of the
   tunnel (other than the endpoints). This provides backwards
   compatibility with networks where the tunnel endpoints do not support
   the NSIS protocols. We assume that NEs will not unwrap tunnel
   encapsulations to find and process tunneled signaling messages.

   To signal for the packets carrying the tunneled data, the tunnel is
   considered as a new data flow in its own right, and NSIS signaling is
   applied recursively to it. This requires signaling support in at
   least one tunnel endpoint. In some cases (where the signaling
   initiator is at the opposite end of the data flow from the tunnel
   initiator - i.e. in the case of receiver initiated signaling), there
   needs to be the ability to provide a binding between the original
   flow identification and that for the tunneled flow. It is left open
   here whether this should be an NTLP or an NSLP function.

6 Signaling Applications

   This section describes gives an overview of NSLPs for particular signaling
   applications. The assumption is that the NSLP uses the generic
   functionality of the NTLP given earlier; this section describes
   specific aspects of NSLP operation. It is intended to clarify by
   example how NSLPs fit into the framework; formal NSLP protocol
   designs will be contained in separate documents.

6.1 Signaling for Quality of Service

   In the case of signaling for QoS, all the basic NSIS concepts of
   section 3.1 apply. In addition, there is an assumed directionality of
   the signaling process, in that one end of the signaling flow takes
   responsibility for actually requesting the resource. This leads to
   the following definitions:
   *) QoS NSIS Initiator (NI): (QNI): the signaling entity which makes the
   resource request, usually as a result of user application request.
   *) QoS NSIS Responder (NR): (QNR): the signaling entity that acts as the
   endpoint for the signaling and can optionally interact with
   applications as well.
   *) QoS NSIS Forwarder (NF): (QNF): the signaling entity between an NI a QNI and NR
   QNR which propagates NSIS signaling further through the 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 the signaling flow
   should take the NSIS Initiator QNI role: with respect to the data flow direction it
   could be at the sending or receiving end.

   Note the continued assumption is that the NTLP works with standard
   (i.e. best-effort) layer 3 routing. There are, however, several
   proposals for the introduction of QoS awareness in routing protocols.
   All of these essentially lead to the existence of multiple paths
   (with different QoS) towards the same destination. As such, they also
   contain an 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 routing, although, provided
   the NTLP continues to deliver signaling messages correctly, the
   impact on the QoS NSLP protocol design itself should be limited.

6.1.1  Protocol Messages Message Semantics

   The QoS NSLP will include a set of messages to carry out resource
   reservations along the signaling path. A message possible set of message
   semantics for the QoS NSLP is shown below (a very similar set of messages was generated in
   [27]). below. Note that the 'direction'
   column in the table below only indicates the 'orientation' of the
   message. The messages Messages can be originated and absorbed at NF QNF nodes as well
   as the NI QNI or NR; QNR; an example might be NFs QNFs at the edge of a domain
   exchanging messages to set up resources for a flow across a it. Note the working assumption
   that responder as well as the initiator
   can release a reservation (comparable to rejecting it in the first
   place). It is left open if the responder can release or modify a
   reservation, during or after setup. This seems mainly a matter of
   assumptions about authorization, and the possibilities might depend
   on resource type specifics.

      +-------+---------+---------------------------------------------+

   The table also explicitly includes a refresh operation. This does
   nothing to a reservation except extend its lifetime, and is one
   possible state management mechanism (see next section).

    +-----------+---------+--------------------------------------------+
    | Name Operation |Direction|                  Semantics                 |
      +-------+---------+---------------------------------------------+
      |Request|
    +-----------+---------+--------------------------------------------+
    |  Request  | I-->R   |    Create a new reservation for a flow     |
      +-------+---------+---------------------------------------------+
      |Modify
    +-----------+---------+--------------------------------------------+
    |  Modify   | I-->R   |       Modify an existing reservation       |
    |           |(&R-->I?)|                                            |
      +-------+---------+---------------------------------------------+
      |Release|
    +-----------+---------+--------------------------------------------+
    |  Release  | I-->R &   | Delete (tear down) an existing reservation |
    |           |(&R-->I?)|                                            |  R-->I
    +-----------+---------+--------------------------------------------+
    |  Accept/  |
      +-------+---------+---------------------------------------------+
      |Accept/| R-->I   |  Confirm (possibly modified?) or reject a  |
    | Reject|  Reject   |         |             reservation request            |
      +-------+---------+---------------------------------------------+
      |Notify
    +-----------+---------+--------------------------------------------+
    |  Notify   | I-->R & |     Report an event detected within the    |
    |           |  R-->I  |                    network                  |
      +-------+---------+---------------------------------------------+
      |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, and is one
   possible state                 |
    +-----------+---------+--------------------------------------------+
    |  Refresh  | I-->R   |    State management mechanism (see next section). section 6.1.2)    |
    +-----------+---------+--------------------------------------------+

6.1.2  State Management

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

   There two critical issues to be considered in building a robust NSLP
   to handle this problem:

   *) The protocol must be scalable. It should allow minimization of the
   resource reservation state storage demands that it implies for
   intermediate nodes; in particular, storage of state per 'micro' flow
   is likely to be impossible except at the very edge of the network. A
   QoS signaling application might require per flow or lower granularity
   state; examples of each for the case of QoS would be IntServ [28] [27] or
   RMD [29] [28] (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, soft state management is typically used as
   a general robustness mechanism. According to the discussion of
   section 3.2.4, the soft state protocol mechanisms are built into the
   NSLP for the specific signaling application that needs them; the NTLP
   sees this simply as a sequence of (presumably identical) messages.

6.1.3 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 QoS awareness in the routing protocols. All of
   these essentially lead to the existence of multiple paths (with
   different QoS) towards the same destination. As such, they also
   contain an 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 routing.

   For intra-domain data flows, the 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 BGP, several
   techniques for including QoS information in the routing decision are
   currently proposed. A first proposal is based on a newly defined BGP-
   4 attribute, the QoS_NLRI attribute [16]. The QoS_NLRI attribute is
   an optional transitive attribute that can be used to advertise a QoS
   route to a peer or to provide QoS information along with the Network
   Layer Reachability Information (NLRI) in a single BGP update. A
   second proposal is based on controlled redistribution 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 of redistribution communities may result in a
   specific route not being announced robustness mechanism. According to a specified set the discussion of eBGP
   speakers, that it should not be exported or
   section 3.2.5, the soft state protocol mechanisms are built into the
   NSLP for the specific signaling application that needs them; the route should be
   prepended n times.

6.1.4 NTLP
   sees this simply as a sequence of (presumably identical) messages.

6.1.3  Route Changes and QoS Reservations

   In this section, we will explore the expected interworking interaction between a
   signaling for
   resource BGP signaling and routing updates, although the same applies
   for any updates (the precise source of routing updates.
   updates does not matter). The normal operation of the NSIS protocol
   will lead to the situation depicted in Figure 7, where the reserved
   resources match the data path.

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

                 Figure 7: Normal NSIS protocol operation

   A route change (triggered by a BGP routing update for instance) can occur while such a reservation is in place. In case of RSVP, the The
   route change will be installed immediately and any data that is sent will be
   forwarded on the new path. This situation is depicted Figure 8.

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

                          Figure 8: Route Change

   Resource reservation on the new path will only be started once the
   next control message is routed along the new path. This means that
   there is a certain time interval during which resources are not
   reserved on (part of) the data path. To minimize this time interval
   several techniques could be considered. As an example, RSVP [2] [1] has
   the concept of local repair, where the router may be triggered by a
   route change. In that case the RSVP node can start sending PATH
   messages directly after the route has been changed. Note that this
   option may not be available if no per-flow state is kept in the 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
   more desirable scenario, the NF QNF 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 QNF receives a 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 sent
   along the new path that was announced,
   4. When the NF QNF has been acknowledged about the reservations on the
   new path, the route will be installed and data will flow along it.

   Another example related to route changes is denoted as severe
   congestion and is explained in [29]. [28]. This solution adapts to a route
   change, when a route change creates a congestion on the new routed
   path.

6.1.5

6.1.4  Resource Management Interactions

   The QoS NSLP itself is not involved in any specific resource
   allocation or management techniques. The definition of an NSLP for
   resource reservation with Quality-of-Service, Quality of Service, however, implies the
   notion of admission control. For a QoS NSLP, the measure of signaling
   success will be the ability to reserve resources from the total
   resource pool that is provisioned in the network. We define the
   function responsible for allocating this resource pool as the
   Resource Management Function (RMF). The RMF is responsible for all
   resource provisioning, monitoring and assurance functions in the
   network.

   A QoS NSLP will rely on the RMF to do resource management and to
   provide inputs for admission control. In this model, the RMF acts as
   a server towards client NSLP(s). It is noted, however, that the RMF
   may in turn use another NSLP instance to do the actual resource
   provisioning in the network. In this case, the RMF acts as the
   initiator (client) of an NSLP.

   This essentially corresponds to a multi-level signaling paradigm,
   with an 'upper' level handling internetworking QoS signaling,
   possibly running end-to-end, and a 'lower' level handling the more
   specialised
   specialized intradomain QoS signaling, running between just the edges
   of the network (see [30], [31], [10], [29], and [32] [30] for a discussion of similar
   architectures). Given that NSIS signaling is already supposed to be
   able to support multiple instances of NSLPs for a given flow, and
   limited scope (e.g. edge-to-edge) operation, it is not currently
   clear that supporting the multi-level model leads to any new protocol
   requirements for the QoS NSLP.

   The RMF may or may not be co-located with an NF a QNF (note that co-
   location with an NI/NR a QNI/QNR can be handled logically as a combination
   between NF QNF and NI/NR). QNI/QNR). To cater for both cases, we define a
   (possibly logical) NF-RMF interface. Over this interface, information
   may be provided from the RMF about monitoring, resource availability,
   topology, and configuration. In the other direction, the interface
   may be used to trigger requests for resource provisioning. One way to
   formalize the interface between the NF QNF and the RMF is via a Service
   Level Agreement (SLA). The SLA may be static or it may be dynamically
   updated by means of a negotiation protocol. Such a protocol is
   outside the scope of NSIS.

   There is no assumed restriction on the placement of the RMF. It may
   be a centralized RMF per domain, several off-path distributed RMFs,
   or an on-path RMF per router. The advantages and disadvantages of
   both approaches are well-known. Centralization typically allows
   decisions to be taken on using more global information with more
   efficient resource utilization as a result. It also facilitates
   deployment or upgrade of policies. Distribution allows local decision
   processes and rapid response to data path changes.

6.2 Other Signaling Applications

   As well as the use for 'traditional' QoS signaling, it should be
   possible to use develop NSLPs for other signaling applications which
   operate on different types of network control state. One specific
   case is setting up flow-related state in middleboxes (firewalls,
   NATs, and so on). Requirements for such communication are given in
   [6],
   [5], and initial discussions of NSIS-like solutions are contained in
   [33]
   [31] and [34]. [32]. 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 framework for signaling protocols which
   assumes a two-layer decomposition, with a common lower layer (NTLP)
   supporting a family of signaling application specific upper layer
   protocols (NSLPs). The overall security considerations for the
   signaling therefore depend on the joint security properties assumed
   or demanded for each layer.

   Security for the NTLP is discussed in section 4.7. We have assumed
   that the role of the NTLP will be to provide message protection over
   the scope of a single peer relationship (between relationship, between adjacent signaling
   entities), and that this
   application entities (see section 3.2.3 for a discussion of the case
   where these entities are separated by more than one NTLP hop). These
   functions can 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 resilient
   against denial of service attacks on the protocol itself.

   Security for the NSLPs is entirely dependent on signaling application
   requirements. In some cases, no additional protection may be required
   compared to what is provided by the NTLP. In other cases, more
   sophisticated object-level protection and the use of public key based
   solutions may be required. In addition, the NSLP needs to consider
   the authorisation requirements of the signaling application.
   Authorisation is a complex topic, for which a very brief overview is
   provided in section 3.3.7.

   Another factor is that NTLP security mechanisms operate only locally,
   whereas NSLP mechanisms may also need to operate over larger regions
   (not just between adjacent peers) especially for authorisation
   aspects; this complicates the analysis analysis of basing signaling
   application security on NTLP protection.

   An additional concern for signaling applications is the session
   identifier security issue (sections 4.6.2 and 5.2). The purpose of
   this identifier is to decouple session identification (as a handle
   for network control state) from session "location" (i.e. the data
   flow endpoints). The identifier/locator distinction has been
   extensively discussed in the user plane for end to end data flows,
   and is known to lead to non-trivial security issues in binding the
   two together again; our problem is the analogue in the control plane,
   and is at least similarly complex, because of the need to involve
   nodes in the interior of basing signaling
   application security on NTLP protection. the network as well.

   Further work on this and other security design will depend on a
   refinement of the NSIS threats work begun in [4]. [3].

8 Change History

   [Editor's note: this section to be removed in final published
   version.]

8.1 Changes from draft-ietf-nsis-fw-03.txt

   1. Added new general section (using part of old content of 3.2.1)
      about how to handle intermediate nodes which don't really want to
      process some signaling application messages fully (new section
      3.2.3).
   2. Added a new section outlining where responsibility for
      aggregation is placed within the layer split (section 3.3.4).
   3. Closed the issue about reliability by saying that the NTLP must
      provide the ability to deliver a message reliably but that this
      doesn't mean the same thing as hard state or guaranteed execution
      at the receiver - essentially the conclusions from draft-hancock-
      nsis-reliability-00.txt (section 4.3).
   4. Removed the issue about summary refreshes (section 4.3), allowing
      the NSLP to do it by choice and leaving open extension of the
      NTLP to do more general lower layer compression.
   5. Included small notes on route change interactions and layer split
      assumption, including merging in of VRRP considerations; also
      some general text tidying (section 5.1.2).
   6. Radically shortened and updated the mobility discussion (section
      5.2), outlining the layer split assumption but removing most of
      the analysis and justification, in the hope that a separate
      document will eventually cover this area.
   7. Included new section on tunnel handling (section 5.4).
   8. Removed most of the detailed discussion of QoS routing and BGP
      from section 6.1. Updated terminology in line with current QoS-
      NSLP design work, and clarified that this is not actually the
      official protocol design.
   9. Updated references and fixed a number of minor typos.

8.2 Changes from draft-ietf-nsis-fw-02.txt

   1. Re-instated 'long' definition of path-coupled from -01 version
      (section 3.1.2).
   2. Moved NTLP open issues (transport and state management
      functionality) to section 3.2.4 3.2.5 and 4.3, and closed several of
      them: NTLP does bundling and fragmentation, but is ignorant of
      NSLP state and vice versa. However, added a new open issue on
      message summarization.
   3. Updated section 5.2 and elsewhere to refer to the WG draft on
      mobility/RSVP analysis and an external review paper. Updated
      section 6.2 with references to more recent work on path-coupled
      signaling to middleboxes. General tidying of other references.

8.2

8.3 Changes from draft-ietf-nsis-fw-01.txt

   This -02 version has been very significantly restructured compared to
   the previous version, and a section 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 introduced much earlier, and the rest of the framework
      restructured around it. In general, the content is supposed to be
      signaling application independent: possibilities for application
      dependent behavior are described in section 3.3, and the specific
      case of QoS/resource management is restricted to section 6.1.
   2. Sender and receiver orientation is now assumed to be a signaling
      application protocol property (section 3.3.1), with the NTLP by
      default operating bidirectionally (section 3.2.3). 3.2.4). 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 reserve/tear messages), and so
      the possible inter-layer coupling with the NSLP is much reduced.
      However, the option of the NTLP providing some kind of generic
      state management service is still an open issue.
   4. In general, authorisation issues are still handled by the NSLP,
      including the question of which network entities are allowed to
      modify network state. In particular, the issue of 'session'
      (previously 'reservation') ownership (section 3.1.5) is assumed
      to be handled by the NSLP level, although session identification
      is still visible to the NTLP (section 4.6.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 NTLP, and any choice between them is a protocol
      design issue (not visible externally).

References

   [Editor's note: in a future version, these will be split as Normative
   and Informative.]

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

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

   3

   2  Brunner, M., "Requirements for Signaling Protocols", draft-ietf-
      nsis-req-08.txt
      nsis-req-09.txt (work in progress), June August 2003

   4

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

   5

   4  Chaskar, H. (editor), "Requirements " Requirements of a QoS Quality of Service (QoS)
      Solution for Mobile IP", draft-ietf-nsis-qos-requirements-01.txt (work in progress),
      June RFC 3583, September 2003

   6

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

   7

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

   8

   7  Tschofenig, H., "RSVP Security Properties", draft-ietf-nsis-rsvp-
      sec-properties-01.txt
      sec-properties-02.txt (work in progress), March, June 2003

   8  Katz, D., "IP Router Alert Option", RFC2113, February 1997

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

   10 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
      RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001

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

   10

   12 Tschofenig, H., M. Buechli, S. Van den Bosch, H. Schulzrinne,
      "NSIS Authentication, Authorization and Accounting Issues", draft-
      tschofenig-nsis-aaa-issues-01.txt (work in progress), March 2003
   11

   13 Berger, L., D. Gan, G. Swallow, P. Pan, F. Tommasi, S. Molendini,
      "RSVP Refresh Overhead Reduction Extensions", RFC2961, April 2001

   12 Hancock, R., E. Hepworth, A. McDonald, "Handling Overload
      Conditions in the NSIS Protocol Suite", draft-hancock-nsis-
      overload-00.txt (work in progress), June 2003

   13 Katz, D., "IP Router Alert Option", RFC2113, February 1997
   14 Partridge, C., A. Jackson, "IPv6 Router Alert Option", RFC 2711, Ji, P., Z. Ge, J. Kurose, D. Townsley, "A Comparison of Hard-State
      and Soft-State Signaling Protocols", Computer Communication
      Review, Volume 33, Number 4, October 1999 2003

   15 Floyd, S., "Congestion Control Principles", RFC 2914, September
      2000

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

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

   17 Rekhter, Y. T. Li, S.Hares, "A Border Gateway Protocol 4 (BGP-4)",
      draft-ietf-idr-bgp4-20.txt (work in progress), April 2003

   18 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

   19

   18 Heijenk, G., G. Karagiannis, V. Rexhepi, L. Westberg, "DiffServ
      Resource Management in IP-based Radio Access Networks",
      Proceedings of 4th International Symposium on Wireless Personal
      Multimedia Communications-WPMC'01, September 9 - 12, 2001

   20

   19 Manner, J., A. Lopez, A. Mihailovic, H. Velayos, E. Hepworth, Y.
      Khouaja, "Evaluation of Mobility and QoS Interaction", Computer
      Networks, Volume 38, Issue 2, 5 February 2002, pp 137-163

   21 Manner, J., et al., "Localized RSVP", draft-manner-lrsvp-01.txt

   20 Johnson, D., C. Perkins, J. Arkko, "Mobility Support in IPv6",
      draft-ietf-mobileip-ipv6-24.txt (work in progress), January June 2003

   22

   21 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

   23

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

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

   25

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

   26

   25 Rosenberg, J., J. Weinberger, C. Huitema, R. Mahy, "STUN - Simple
      Traversal of User Datagram Protocol (UDP) Through Network Address
      Translators (NATs)", RFC3489, March 2003
   26 Terzis, A., J. Krawczyk, J. Wroclawski, L. Zhang, "RSVP Operation
      Over IP Tunnels", RFC 2746, January 2000

   27 Westberg, L., et al., "Resource Management in Diffserv (RMD)
      Framework", draft-westberg-rmd-framework-03.txt (work in
      progress), June 2003

   28 Braden, R., D. Clark, S. Shenker, "Integrated Services in the
      Internet Architecture: an Overview", RFC 1633, June 1994

   29

   28 Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
      Partain, D., Pop, O., Rexhepi, V., Szabó, Szabo, R., Takács, Takacs, A.,
      "Resource Management in Diffserv (RMD): A Functionality and
      Performance Behavior Overview", Seventh International Workshop on
      Protocols for High-Speed networks - PfHSN 2002, 22 - 24 April 2002

   30

   29 Ferrari, D., A. Banerjea, H. Zhang, "Network Support for
      Multimedia - A Discussion of the Tenet Approach", Berkeley TR-92-
      072, November 1992

   31

   30 Nichols, K., V. Jacobson, L. Zhang, "A Two-bit Differentiated
      Services Architecture for the Internet", RFC 2638, July 1999

   32 Baker, F., C. Iturralde, F. Le Faucheur, B. Davie, "Aggregation of
      RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001

   33

   31 Brunner, M., M. Stiemerling, M. Martin, H. Tschofenig, H.
      Schulzrinne, "SIS "NSIS NAT/FW NSLP: Problem Statement and Framework",
      draft-brunner-nsis-midcom-ps-00.txt (work in progress), June 2003

   34

   32 Aoun, C., "NSIS Network Address Translator implications", draft-
      aoun-nsis-nat-imps-01.txt (work in progress), March 2003

Acknowledgments

   The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
   Hepworth, Andrew McDonald, Melinda Shore and Hannes Tschofenig for
   significant contributions in particular areas of this draft. In
   addition, the authors would like to acknowledge Cedric Aoun, Attila
   Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
   Xiaoming Fu, Ruediger Geib, Danny Goderis, Cornelia Kappler, Sung
   Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De Neve,
   Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne, Tom
   Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars Westberg,
   and Lixia Zhang for insights and inputs during this and previous
   framework activities.

Authors' Addresses

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

   Robert Hancock (editor)
   Roke Manor Research
   Old Salisbury Lane
   Romsey
   Hampshire
   SO51 0ZN
   United Kingdom
   email: robert.hancock@roke.co.uk

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

   Georgios Karagiannis
   University of Twente
   P.O. BOX 217
   7500 AE Enschede
   The Netherlands
   email: g.karagiannis@ewi.utwente.nl

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

   Copyright (C) The Internet Society (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.