[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-hancock-nsis-fw) 00 01 02 03 04 05 06 07 RFC 4080

   NSIS Working Group
   Internet Draft                               Robert Hancock (editor)
                                            Siemens/Roke Manor Research
                                                          Ilya Freytsis
                                                      Cetacean Networks
                                                   Georgios Karagiannis
                                                               Ericsson
                                                          John Loughney
                                                                  Nokia
                                                     Sven Van den Bosch
                                                                Alcatel
   Document: draft-ietf-nsis-fw-02.txt
   Expires: September 2003                                   March 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 [1].

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

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

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

Abstract

   The 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


Hancock et al.         Expires - September 2003               [Page 1]

                  Next Steps in Signaling: Framework        March 2003

   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 and
   mobility. The different routing and mobility 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 [2].
   [Editor's note: if - as is likely - we don't end up using these words
   in the framework, this paragraph will disappear.]

Table of Contents

   1. Introduction...................................................3
     1.1 Definition of the NSIS Signaling Problem ...................3
     1.2 Scope and Structure of the NSIS Framework ..................4
   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   Signaling to Hosts, Networks and Proxies ...............7
     3.1.3   Signaling Messages and Network Control State ...........9
     3.1.4   Data Flows and Sessions ...............................10
     3.2 Layer Model for the Protocol Suite ........................11
     3.2.1   Layer Model Overview ..................................11
     3.2.2   Layer Split Concept ...................................12
     3.2.3   Core NTLP Functionality ...............................13
     3.2.4   Path De-Coupled Operation .............................14
     3.3 Signaling Application Properties ..........................14
     3.3.1   Sender/Receiver Orientation ...........................15
     3.3.2   Uni- and Bi-Directional Operation .....................16
     3.3.3   Heterogeneous Operation ...............................16
     3.3.4   Peer-Peer and End-End Relationships ...................17
     3.3.5   Acknowledgements and Notifications ....................17
     3.3.6   Security and other AAA Issues .........................18
     3.4 Open Layer Model Issues ...................................19
     3.4.1   Classical Transport Functionality .....................19


Hancock et al.         Expires - September 2003               [Page 2]

                  Next Steps in Signaling: Framework        March 2003

     3.4.2   State Management ......................................20
   4. The NSIS Transport Layer Protocol.............................21
     4.1 Internal Protocol Components ..............................21
     4.2 Addressing ................................................22
     4.3 Lower Layer Interfaces ....................................22
     4.4 Upper Layer Services ......................................23
     4.5 Identity Elements .........................................24
     4.5.1   Flow Identification ...................................24
     4.5.2   Session Identification ................................24
     4.5.3   Signaling Application Identification ..................25
     4.6 Security Properties .......................................25
   5. Interactions with Other Protocols.............................26
     5.1 IP Routing Interactions ...................................26
     5.1.1   Load Sharing and Policy-Based Forwarding ..............26
     5.1.2   Route Changes .........................................28
     5.1.3   Router Redundancy .....................................29
     5.2 Mobility Interactions .....................................29
     5.2.1   Addressing and Encapsulation ..........................30
     5.2.2   Localized Path Repair .................................30
     5.2.3   Update on the Unchanged Path ..........................31
     5.2.4   Interaction with Mobility Signaling ...................31
     5.2.5   Interaction with Context Transfer .....................33
     5.3 Interactions with NATs ....................................33
   6. Signaling Applications........................................34
     6.1 Signaling for Quality of Service ..........................34
     6.1.1   Protocol Messages .....................................34
     6.1.2   State Management ......................................35
     6.1.3   QoS Forwarding ........................................36
     6.1.4   Route Changes and QoS Reservations ....................36
     6.1.5   Resource Management Interactions ......................38
     6.2 Other Signaling Applications ..............................39
   7. Security Considerations.......................................39
   8. Change History................................................40
     8.1 Changes from draft-ietf-nsis-fw-01.txt ....................40
   References.......................................................41
   Acknowledgments..................................................44
   Authors' Addresses...............................................44
   Intellectual Property Considerations.............................45
   Full Copyright Statement.........................................46


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.



Hancock et al.         Expires - September 2003               [Page 3]

                  Next Steps in Signaling: Framework        March 2003

   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; this is 'path-coupled' signaling in
   the sense described in [3], and that only unicast data flows are
   considered.

   The signaling problem in this sense is very similar to that addressed
   by RSVP [4]. However, there are two generalizations. Firstly, the
   intention is that NSIS designs protocols that can be used 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 is to define both the
   generic protocol, and initially an upper layer suitable for QoS
   signaling similar to the corresponding functionality in RSVP. Further
   signaling 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]; other related requirements can be found in [5] and
   [6]. This framework does not replace or update these requirements.
   Discussions about lessons to be learned from existing signaling and
   resource protocols are contained in a separate analysis document [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 the overall level. Therefore, it
   discusses important protocol considerations, such as routing,
   mobility, security, and interactions with network 'resource'
   management (in the broadest sense).

   The basic framework for NSIS is given in section 3. Section 3.1
   describes the fundamental elements of NSIS operation in comparison to
   RSVP; in particular, section 3.1.2 describes more general signaling
   scenarios, and 3.1.3 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


Hancock et al.         Expires - September 2003               [Page 4]

                  Next Steps in Signaling: Framework        March 2003

   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 or even design options, although some are
   described as examples. The emphasis is on defining the interfaces
   between this lower layer protocol and the IP layer and signaling
   application protocols, including the identity elements that appear on
   these interfaces. 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 described 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.5.1).

   Edge node - a (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.




Hancock et al.         Expires - September 2003               [Page 5]

                  Next Steps in Signaling: Framework        March 2003

   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.5.2).

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

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


Hancock et al.         Expires - September 2003               [Page 6]

                  Next Steps in Signaling: Framework        March 2003

   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|
   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    |
   |   |NE|====|======||NE||======||NE||==================|===|NE|    |
   |   +--+    |      |+--+|      |+--+|                  |   +--+    |
   +-----------+      +----+      +----+                  +-----------+

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

                 Figure 1: Simple Signaling and Data Flows

3.1.2  Signaling to Hosts, Networks and Proxies

   There are different possible triggers for the NSIS signaling. Amongst
   them are signaling applications (that are using NSIS signaling
   services), other instances of the signaling, network management
   actions, some network events, and so on. The variety of possible


Hancock et al.         Expires - September 2003               [Page 7]

                  Next Steps in Signaling: Framework        March 2003

   triggers requires that the signaling can be initiated and terminated
   in the different parts of the network - hosts, domain boundary nodes
   (edge nodes) or interior domain nodes.

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

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

   In some cases it is desired to be able to initiate and/or terminate
   NSIS signaling not from the end host that sends/receives the data
   flow, but from the some other entities on 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 "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 a set of specific challenges to the NSIS
   signaling:



Hancock et al.         Expires - September 2003               [Page 8]

                  Next Steps in Signaling: Framework        March 2003

   *) The 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.

   Another possible configuration, shown in Figure 3 is where an NE can
   send and receive signaling information off path for and from remote
   processing. The NSIS protocols may or may not be suitable for this
   remote processing 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.

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

            Appl = signaling         PA = Proxy for signaling
                   application            application

                      Figure 3: "Off path" NSIS proxy

3.1.3  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 corresponding to that signaling application. An example for
   the case of an RSVP-like QoS signaling application would be state


Hancock et al.         Expires - September 2003               [Page 9]

                  Next Steps in Signaling: Framework        March 2003

   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 state management is also possible.

3.1.4  Data Flows and Sessions

   Formally, a data flow is a (unidirectional) sequence of packets
   between the same endpoints which follow a unique path through the
   network (determined by IP routing and other network layer
   configuration). A flow is defined by a packet classifier (in the
   simple 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 distinct from 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 is network control
   state management at the flow level, as described in the previous
   subsection. In particular, it is 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-related
   ones, see [3] and [8]) it is desirable to update the flow:session
   relationship 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 can only be managed by the end systems (because
   of the packet classifier change). To enable this, it must be possible
   for end systems to relate signaling messages to sessions as well as
   data flows.



Hancock et al.         Expires - September 2003              [Page 10]

                  Next Steps in Signaling: Framework        March 2003

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, it
   is proposed to structure the NSIS protocol suite into 2 layers,
   similar to the original proposal in [9]:
    *) 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 component
   within the signaling application layer; in the end, there will be
   several NSLPs. These relationships are illustrated in Figure 4. Note
   that the NTLP may or may not have an interesting internal structure
   (e.g. based on the use of existing transport protocols) but that is
   not relevant at this level.

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

                    Figure 4: NSIS Protocol Components



Hancock et al.         Expires - September 2003              [Page 11]

                  Next Steps in Signaling: Framework        March 2003

   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.

   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.


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

               Figure 5: Signaling with Heterogeneous NSLPs

3.2.2  Layer Split Concept

   This section describes the basic concepts which underlie how the
   necessary functionality within the NTLP can be determined. 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.




Hancock et al.         Expires - September 2003              [Page 12]

                  Next Steps in Signaling: Framework        March 2003

   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 can be automatically
   achieved.

   This definition relates to NTLP operation. It is not intended to
   restrict the ability of an NSLP to send messages by other means. For
   example, an NE in the middle or end of the signaling path could send
   a message directly to the other end as a notification of or
   acknowledgement for some signaling application event. However, it
   appears that 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 scope of 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
   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.

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

3.2.3  Core NTLP Functionality

   This section describes the basic functionality to be supported by the
   NTLP. Note that the analysis has to be based on considering NSLP and
   NTLP operation jointly; 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 and so on).

   Therefore, NTLP functionality is essentially just efficient upstream
   and downstream peer-peer message delivery in a wide variety of
   network scenarios. Message delivery includes the act of locating
   and/or selecting which NTLP peer to carry out signaling exchanges
   with for a specific data flow. This discovery might be an active
   process (using specific signaling packets) or a passive process (a
   side effect of using a particular addressing mode). In addition, it
   appears that the NTLP can sensibly carry out most of the functions of
   enabling signaling messages to pass through middleboxes, since this
   is closely related to the problem of routing the signaling messages
   in the first place.



Hancock et al.         Expires - September 2003              [Page 13]

                  Next Steps in Signaling: Framework        March 2003

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

3.2.4  Path De-Coupled Operation

   Path-decoupled signaling is defined as signaling for state
   installation along the data path, without the restriction of passing
   only through nodes (NEs) that are located on the data path. Signaling
   messages can be routed to NEs off the data path, but which are
   (presumably) aware of it. This allows a looser coupling between NEs
   and data plane nodes, e.g. at the AS level.

   The main advantages of path-decoupled signaling are ease of
   deployment and support of additional functionality. The ease of
   deployment comes from a restriction of the number of impacted nodes
   in case of deployment and/or upgrade of an NSLP. It would allow, for
   instance, deploying a solution without upgrading any of the routers
   in the data plane. Additional functionality that can be supported
   includes the use of off-path proxies to support authorization or
   accounting architectures.

   There are potentially significant differences in the way that the two
   signaling paradigms should be analyzed. Using a single centralized
   off-path NE may increase the requirements in terms of message
   handling. This effect, however, is orthogonal to the NSIS charter,
   since 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 can
   no longer be assumed. Furthermore, the interpretation of
   sender/receiver orientation becomes less obvious. With the local
   operation of NTLP, the impact of path-decoupled signaling on the
   routing of signaling messages is presumably restricted to the problem
   of peer determination. The assumption that the off-path NEs are
   loosely tied to the data path suggests, however, that peer
   determination can still be based on L3 routing information.

3.3 Signaling Application Properties

   It is clear that many signaling applications will require specific
   protocol behavior in their NSLP. This section outlines some of the
   options for NSLP behavior; further work on selecting from these
   options would depend on detailed analysis of the application in
   question.



Hancock et al.         Expires - September 2003              [Page 14]

                  Next Steps in Signaling: Framework        March 2003

3.3.1  Sender/Receiver Orientation

   In some signaling applications, one end of the data flow takes
   responsibility for requesting special treatment - such as a resource
   reservation - from the network. The appropriate end may depend on the
   signaling application, or characteristics of the network deployment.

   A sender-initiated approach is when the sender of the data flow
   requests and maintains the resource reservation used for that flow.
   In a receiver-initiated approach the receiver of the data flow
   requests and maintains the resource reservation used for that flow.
   The NTLP has no freedom in this area: next peers have to be
   discovered in the sender to receiver direction, but after that time
   the default assumption is that signaling is possible both upstream
   and downstream (unless possibly an application specifically indicates
   this is not required). This implies that backward routing state must
   be maintained or that backward routing information must be available
   in the signaling packet.

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

   *) In a receiver-initiated approach, the signaling messages traveling
   from the receiver to the sender must be backward routed such that
   they follow exactly the same path as was followed by the signaling
   messages belonging to the same flow traveling from the sender to the
   receiver. This implies that a backward routing state per flow must be
   maintained. When using a sender-initiated approach, provided
   acknowledgements and notifications can be securely delivered to the
   sending node, backward routing is not necessary, and nodes do not
   have to maintain backward routing states.
   *) In a sender-initiated approach, a mobile node can initiate a
   reservation for its outgoing flows as soon as it has moved to another
   roaming subnetwork. In a receiver-initiated approach, a mobile node
   has to inform the receiver about its handover procedure, thus
   allowing the receiver to initiate a reservation 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 to carry
   out the operation. A mismatch between authorizing and initiating NEs
   will cause additional message exchanges either in the NSLP or in a
   protocol executed prior to NSIS invocation. Note that this may
   complicate modifications of network control state for existing flows.
   *) Where the signaling is looking for the last (nearest to receiver)
   NE on the data path, receiver oriented signaling is most efficient;
   sender orientation would be possible, but take more messages.
   *) In either case, the initiator can generally be informed faster
   about reservation failures than the remote end.


Hancock et al.         Expires - September 2003              [Page 15]

                  Next Steps in Signaling: Framework        March 2003


3.3.2  Uni- and Bi-Directional Operation

   For some signaling applications and scenarios, signaling may only be
   considered for one direction of the data flow. However, in other
   cases, there may be interesting relationships between the signaling
   for the two directions; an example is QoS for a voice call. In the
   basic case, bi-directional signaling can simply use a separate
   instance of the same signaling mechanism in each direction. Note that
   the path in the two directions may differ due to asymmetric routing.

   In constrained topologies where parts of the route are symmetric, it
   may be possible to use a more unified approach to bi-directional
   signaling, e.g. carrying the two signaling directions in common
   messages. This optimization might be used for example to make mobile
   QoS signaling more efficient.

   In either case, the correlation of the signaling for the two flow
   directions is carried out in the NSLP. The NTLP would simply be
   enabled to bundle the messages together.

3.3.3  Heterogeneous Operation

   It is likely that the appropriate way to describe the state NSIS is
   signaling for will vary from one part of the network to another
   (depending on signaling application). For example in the QoS case,
   resource descriptions that are valid for inter-domain links will
   probably be different from those useful for intra-domain operation
   (and the latter will differ from one NSIS domain to another).

   One way to address this issue is to consider the state description
   carried within the NSLP as divided in globally-understood objects
   ("global objects") and locally-understood objects ("local objects").
   The local objects are only applicable for intra-domain signaling,
   while the global objects are mainly used in inter-domain signaling.
   Note that such local objects are still part of the NSIS protocol and
   can be inserted, used and removed by one single domain.

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




Hancock et al.         Expires - September 2003              [Page 16]

                  Next Steps in Signaling: Framework        March 2003

3.3.4  Peer-Peer and End-End Relationships

   The assumption taken in this framework is that the NTLP will operate
   'locally', that is, just over the scope of a single peer
   relationship. End-to-end operation is built up by simply
   concatenating these relationships. Any non-local operation (if any)
   will take place only in particular NSLPs.

   The peering relations may also have an impact on the required amount
   of state at each NSIS entity. When direct interaction with remote
   peers is not allowed, it may be required to keep track of the path
   that a message has followed through the network. This can be achieved
   by keeping per-flow state at the NSIS entities or by maintaining a
   record route object in the messages.

   Note that, for the reasons discussed in section 3.2.1, NSLP peers are
   not inevitably NTLP peers. This has a number of implications for the
   relationship between the signaling layers, in that NSLP peers may
   depend on the service provided by a concatenation of NTLP peer
   relationships rather than a single one, which makes it harder to
   exploit fully some NTLP properties (e.g. channel security,
   reliability).

3.3.5  Acknowledgements and Notifications

   We are assuming that 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
   peer relationship).

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

   Acknowledgements can be sent along the sequence of NTLP peer
   relationships towards the signaling initiator, which relieves the
   requirements on the security associations that need to be maintained
   by NEs and can ensure NAT traversal in both directions. (If this
   direction is towards the flow sender, it implies maintaining reverse
   routing state in the NTLP). In certain circumstances (e.g. trusted
   domains), an optimization can be made by sending acknowledgements
   directly to the signaling initiator (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 have a more local meaning,


Hancock et al.         Expires - September 2003              [Page 17]

                  Next Steps in Signaling: Framework        March 2003

   indicating for instance that a certain failure or degradation
   occurred at 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 it may not be obvious to determine where the notification
   should be sent. Other than that, the same considerations apply as for
   acknowledgements. One useful distinction to make would be to
   differentiate between notifications that trigger a signaling action
   and others that don't. The security requirements for the latter are
   less stringent, which means they could be sent directly to the NE
   they are destined for (provided this NE can be determined).

3.3.6  Security and other AAA Issues

   In some cases it will be possible to achieve the necessary level of
   signaling security by using basic 'channel security' mechanisms [10]
   at the level of the NTLP, and the possibilities are described in
   section 4.6. 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 NSLP messages.

   In addition to authentication, authorisation (to manipulate network
   control state) has to be considered as functionality above the NTLP
   level, since it will be entirely application specific. Indeed,
   authorisation decisions may be handed off to a third party in the
   protocol (e.g. for QoS, the resource management function as described
   in section 6.1.5). Many different authorisation models are possible,
   and the variations impact
   *) what message flows take place - for example, whether authorisation
   information is carried along with a control state modification
   request, or is sent in the reverse direction 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 the direction or order in which signaling applications
   can send messages, these authorisation aspects are left open to be
   defined by each NSLP. Further background discussion of this issue is
   contained in [11].








Hancock et al.         Expires - September 2003              [Page 18]

                  Next Steps in Signaling: Framework        March 2003

3.4 Open Layer Model Issues

3.4.1  Classical Transport Functionality

   The first major issue is the extent to which the NTLP should include
   'traditional' transport like functions, or whether these should be
   seen as either fundamentally unnecessary or automatically handled by
   the upper layers. The following functions have been identified as
   candidates:

   1. Local retransmission to improve reliability. The argument in favor
   is that the NTLP can recover from congestive loss or corruption much
   more rapidly than end-to-end (NSLP) mechanisms; the argument against
   is that the additional complexity in the NTLP is not needed for all
   signaling applications. (It's assumed that 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.

   2. Congestion control. Here, the question is whether the NTLP should
   include a common mechanism which protects the local portion of the
   network from overload, or whether this can be derived from the
   behavior of each signaling application.

   3. Message fragmentation. For NSLPs that generate large messages, it
   will be necessary to fragment and re-assemble them efficiently within
   the network, where the use IP fragmentation may lead to reduced
   reliability and be incompatible with some addressing schemes. (It's
   assumed that the counterpart functionality, of bundling small
   messages together, can be provided locally by the NTLP as an option
   if desired; it doesn't affect the operation of the network
   elsewhere.)

   4. Flow control. Here, the question is how a receiving NSLP should be
   protected from overload - whether the NTLP should provide a flow
   controlled channel, or whether this should be managed using
   application layer acknowledgements, for example.

   It appears that all these issues don'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.




Hancock et al.         Expires - September 2003              [Page 19]

                  Next Steps in Signaling: Framework        March 2003

3.4.2  State Management

   It is clear that the NTLP may have to manage some per-flow state to
   carry out its message delivery functions (for example, state about
   the reverse route for signaling messages, or state needed for route
   change detection). How this state is stored and managed is an
   internal matter for the NTLP (see section 4), and the details (in
   particular, any connection model it might use) is in any case
   entirely invisible to the signaling applications.

   However, signaling applications are frequently managing network
   control state for their own purposes, and it is an open issue how
   much the NTLP should provide a common service to do this for them.

   The simplest case is that the NTLP simply delivers messages, and any
   state-related aspects (lifetimes, message semantics and so on) are
   entirely invisible to it, being part of the signaling application
   data. This provides the simplest interface between NTLP and NSLP.

   The other extreme is where the NTLP provides a complete state
   management service, including explicit commands for creation,
   modification and deletion of state with known lifetimes in remote
   nodes. This service could make it easy to write new signaling
   applications, at the cost of increasing the complexity of the
   NTLP/NSLP interface; in particular, there would be many more events
   and error conditions to generate within the NTLP, and there may be
   several different types of state management semantics required by
   different signaling applications. The commonality with other parts of
   NTLP functionality is not clear.

   An intermediate case is where there is particular support for the
   refresh messages used for soft-state maintenance. The characteristics
   of these messages are that they can be sent and processed without
   invoking signaling application specific logic, and that their timing
   can be manipulated to fit in with other NTLP requirements (e.g.
   jittering to avoid network synchronization, or to allow bundling with
   other messages). Therefore, provided this functionality can be
   defined simply and universally, there may be benefits in supporting
   it within the NTLP itself. The implication would be that some NTLP
   messages contain timing and other control information (to allow the
   refresh to be handled correctly at intermediate NSLP-unaware nodes).
   In addition, the automatic generation and reception of refreshes
   could be handled above or below the NSLP/NTLP boundary (this seems to
   be mainly an API issue).






Hancock et al.         Expires - September 2003              [Page 20]

                  Next Steps in Signaling: Framework        March 2003

4. The NSIS Transport Layer Protocol

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

   It is not the intention of this discussion to design the NTLP or even
   to discuss design options, although some are described as examples.
   The goal is to provide a general discussion of required functionality
   and to highlight some of the issues associated with this.

4.1 Internal Protocol Components

   The NTLP includes all functionality below the signaling application
   layer and above the IP layer. The functionality that is required
   within the NTLP is described in section 3.2.

   Some NTLP functionality could be provided via components existing as
   sublayers within the NTLP design.  For example, if specific transport
   capabilities are required, such as congestion avoidance,
   retransmission, security and so on, then existing protocols, such as
   TCP or TLS, could be incorporated into the NTLP. This possibility is
   not required or excluded by this framework.

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

                   Figure 6: Options for NTLP Structure

   If peer-peer addressing (section 4.2) is used for some messages, then
   active next-peer discovery functionality will be required within the
   NTLP to support the explicit addressing of these messages. (This
   could use message exchanges for dynamic peer discovery as a sublayer
   within the NTLP; there could also be an interface to external
   mechanisms to carry out this function.)




Hancock et al.         Expires - September 2003              [Page 21]

                  Next Steps in Signaling: Framework        March 2003

4.2 Addressing

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

   With peer-peer addressing, an NE will determine that 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 the information present in the payload.  This can be
   achieved through the availability of a local routing table or through
   participation in active peer discovery message exchanges.  Peer-peer
   addressing inherently supports tunneling of messages between NEs, and
   is equally applicable to the path-coupled and path-decoupled cases.

   In the case of end-to-end addressing, the message is addressed to the
   data flow receiver, and (some of) the NEs along the data path
   intercept the messages.  The routing of the messages should follow
   exactly the same path as the associated data flow (but see section
   5.1.1 on this point). Note that securing messages sent this way
   raises some interesting security issues (these are discussed in
   [12]).

   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.5.1) or locally stored
   NTLP state.

4.3 Lower Layer Interfaces

   The NTLP interacts with 'lower layers' of the protocol stack for the
   purposes of sending and receiving signaling messages. This framework
   places the lower boundary of the NTLP at the IP layer. The interface
   to the lower layer is therefore very simple:
    *) 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 the case of
   end-to-end addressing, this will be achieved by intercepting packets
   that have been marked in some special way (by special protocol number



Hancock et al.         Expires - September 2003              [Page 22]

                  Next Steps in Signaling: Framework        March 2003

   or by some option interpreted within the IP layer, such as the Router
   Alert option [13] and [14]).
    *) The NTLP receives indications from the IP layer regarding route
   changes and similar events (see section 5.1).

   For correct message routing, the NTLP needs to have some information
   about link and IP layer configuration of the local networking stack.
   For example, it needs to know:
    *) [in general] how to select the outgoing interface for a signaling
   message, in case this needs to match the interface that will be used
   by the corresponding flow. This might be as simple as just allowing
   the IP layer to handle the message using its own routing table. There
   is no intention to do something different from IP routing (for end-
   to-end addressed messages); however, some hosts allow applications to
   bypass routing for their data flows, and the NTLP processing must
   account for this.
    *) [in the case of IPv6] what address scopes are associated with the
   interface that messages are sent and received on (to interpret scoped
   addresses in flow identification, if these are to be allowed).

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

4.4 Upper Layer Services

   The NTLP offers transport layer services to higher layer signaling
   applications for two purposes: sending and receiving signaling
   messages, and exchanging control and feedback information.

   For sending and receiving messages, two basic control primitives are
   required:
    *) Send Message, to allow the signaling application to pass data to
   the NTLP for transport.
    *) Receive Message, to allow the NTLP to pass received data to the
   signaling application.

   The NTLP and signaling application may also want to exchange other
   control information, such as:
    *) Signaling application registration/de-registration, so that
   particular signaling application instances can register their
   presence with the transport layer. This may also require some
   identifier to be agreed between the NTLP and signaling application to
   allow support the exchange of further control information and to
   allow the de-multiplexing of incoming 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
   maintained.


Hancock et al.         Expires - September 2003              [Page 23]

                  Next Steps in Signaling: Framework        March 2003

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

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

4.5 Identity Elements

4.5.1  Flow Identification

   The flow identification is a method of identifying a flow in a unique
   way.  All packets associated with the same flow will be identified by
   the same flow identifier.  The key aspect of the flow identifier is
   to provide enough information such that the signaling flow receives
   the same treatment along the data path as that actual data itself,
   i.e. consistent behavior is applied to the signaling and data flows
   by a NAT or policy-based forwarding engine.

   Information that could be used in flow identification may include:
    *) source IP address;
    *) destination IP address;
    *) protocol identifier and higher layer (port) addressing;
    *) flow label (typical for IPv6);
    *) SPI field for IPSec encapsulated data;
    *) DSCP/TOS field
   It is assumed that wildcarding on these identifiers is not needed
   (further analysis may be required).

   We've assumed here that the flow identification is not hidden within
   the NSLP, but is explicitly part of the NTLP. The justification for
   this is that it might be valuable to be able to do NSIS processing
   even at a node which was unaware of the specific signaling
   application (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.5.2  Session Identification

   There are circumstances where it is important to be able to refer to
   signaling application state independently of the underlying flow.
   For example, if the address of one of the flow endpoints changes due
   to a mobility event, it is desirable to be able to change the flow
   identifier without having to install a completely new reservation.



Hancock et al.         Expires - September 2003              [Page 24]

                  Next Steps in Signaling: Framework        March 2003

   The session identifier provides a method to correlate the signaling
   about the different flows with 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 that
   it should be visible within the NTLP. This enables it to be used to
   control NTLP behavior, for example, by controlling how the transport
   layer should forward packets belonging to this session (as opposed to
   this signaling application).  In addition, the session identifier can
   be used by the NTLP to demultiplex received signaling messages
   between multiple instances of the same signaling application, if such
   an operational scenario is supported (see section 4.5.3 for more
   information on signaling application identification).

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

4.5.3  Signaling Application Identification

   Since the NTLP can be used to support several NSLP types, there is a
   need to identify which type a particular signaling message exchange
   is being used for.  This is to support:
    *) processing of incoming messages - the NTLP should be able to
   demultiplex these towards the appropriate signaling applications;
    *) processing of general messages at an NSIS aware intermediate node
   - if the node does not handle the specific signaling application, it
   should be able to make a forwarding decision without having to parse
   upper layer information.

   No position is taken on the form of the signaling application
   identifier, or even the structure of the signaling application
   'space' - free-standing applications, potentially overlapping groups
   of capabilities, etc. These details should not influence the rest of
   NTLP design.

4.6 Security Properties

   It is assumed that the only security service required within NTLP is
   channel security. Channel security requires a security association to
   be established between the signaling endpoints, which is carried out



Hancock et al.         Expires - September 2003              [Page 25]

                  Next Steps in Signaling: Framework        March 2003

   via some authentication and key management exchange. This
   functionality could be provided by reusing a standard protocol.

   In order to protect a particular signaling exchange, the NSIS entity
   needs to select the security association that it has in place with
   the next NSIS entity that will be receiving the signaling message.
   The ease of doing this depends on the addressing model in use by the
   NTLP (see section 4.2).

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

   Channel security can also be applied to the signaling messages with
   differing granularity, i.e. all or parts of the signaling message may
   be protected.  For example, if the flow is traversing a NAT, only the
   parts of the message that do not need to be processed by the NAT
   should be protected. It is an open question as to which parts of the
   NTLP messages need protecting, and what type of protection should be
   applied to each.

5. Interactions with Other Protocols

5.1 IP Routing Interactions

   The NSIS Transport Layer (NTLP) is responsible for discovering the
   next node to be visited by the signaling protocol. For path-coupled
   signaling, this next node should be the one that will be visited by
   the data flow. In practice, this peer discovery will be approximate,
   as any node could use any feature of the peer discovery packet to
   route it differently than the corresponding data flow packets.
   Divergence between data and signaling path can occur due to load
   sharing or load balancing (section 5.1.1). An example specific to the
   case of QoS is given in section 6.1.1. Route changes cause a
   temporary divergence between the data path and the path on which
   signaling state has been installed. The occurrence, detection and
   impact of route changes is described in section 5.1.2. A description
   of this issue in the context of QoS is given in section 6.1.2.

5.1.1  Load Sharing and Policy-Based Forwarding

   Load sharing or load balancing is a network optimization technique
   that exploits the existence of multiple paths to the same destination
   in order to obtain benefits in terms of protection, resource
   efficiency or network stability. The significance of load sharing in
   the context of NSIS is that, if the load sharing mechanism in use
   will forward packets on any basis other than the destination address,


Hancock et al.         Expires - September 2003              [Page 26]

                  Next Steps in Signaling: Framework        March 2003

   routing of 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
   policy information about fields additional to the packet destination
   address - has the same impact.

   Signaling and data flow packets may diverge because of these
   techniques. In OSPF, load balancing can be used between equal cost
   paths [15] or unequal cost paths. An example of the latter approach
   is Optimized Multi Path (OMP). OMP discovers multiple paths, not
   necessarily equal cost paths, to any destinations in the network, but
   based on the load reported from a particular path, it determines
   which fraction of the data to direct to the given path. Incoming
   packets are subject to a (source, destination address) hash
   computation, and effective load sharing is accomplished by means of
   adjusting the hash thresholds. BGP [16][17] advertises the routes
   chosen by the BGP decision process to other BGP speakers. In the
   basic specification, routes with the same Network Layer reachability
   information (NLRI) as previously advertised routes implicitly replace
   the original advertisement, which means that multiple paths for the
   same prefix cannot exist. Recently, however, a new mechanism was
   defined that will allow the advertisement of multiple paths for the
   same prefix without the new paths implicitly replacing any previous
   ones [18]. The essence of the mechanism is that each path is
   identified by an arbitrary identifier in addition to its prefix.

   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 TCP/UDP or port-based). Such
   techniques would, however, constrain the use of proxies. Proxies
   would cause ICMP errors to be misdirected to the source of the data
   because of source address spoofing.

   If the routing decision is based on the complete five-tuple,
   divergence may still occur because of the presence of router alert
   options. In this case, the same constraint on proxy use applies as
   above. Additionally, it becomes difficult for the end systems to
   distinguish between data and signaling packets. Finally, QoS routing
   techniques (section 6.1.3) may base the routing decision on any field
   in the packet header (e.g. DSCP, ...).

   Most load-balancing techniques use the first n bytes of the packet
   header (including SA, DA and protocol field) in the hashing function.
   In this case, the above considerations regarding source/destination
   address or five-tuple based forwarding apply.





Hancock et al.         Expires - September 2003              [Page 27]

                  Next Steps in Signaling: Framework        March 2003

5.1.2  Route Changes

   In a routed network, each packet is independently routed based on its
   header information. Whenever a better route towards the destination
   becomes available, this route is installed in the forwarding table
   and will be used for all subsequent (data and signaling) packets.
   This can cause a divergence between the path along which state has
   been installed and the path along which forwarding will actually take
   place.

   The 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. teardown 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 and the types of
   change they can detect. In rough order of increasing applicability,
   they can be summarized as:
   a) monitoring changes in local interface state
   b) monitoring network-wide topology changes in a link-state routing
   protocol
   c) inference from changes in data packet TTL
   d) inference from loss of packet stream in a downstream flow-aware
   router
   e) inference from changes in signalling packet TTL
   f) changed route of a PATH-like (end-to-end addressed) signaling
   packet
   g) changed route of a specific end-to-end addressed probe packet

   There are essentially three ways in which detection can happen: based
   on network monitoring (method a-b), based on data packet monitoring
   (method c-d) and based on monitoring signaling protocol messages
   (method e-g). Methods contingent on monitoring signaling messages
   become less effective as refresh reduction techniques are used.

   When a route change has been detected, it is important that state is
   installed as quickly as possible along the new path. It is not
   guaranteed that the new path will be able to provide the same
   characteristics that were available on the old path. In order to be
   able to avoid duplicate state installation or, worse, rejection of
   the signaling message because of previously installed state, it is
   important to be able to recognize the new signaling message as
   belonging to an existing session. In this respect, we distinguish
   between route changes with associated change of the flow
   specification (e.g. in case of a mobility event when the IP source


Hancock et al.         Expires - September 2003              [Page 28]

                  Next Steps in Signaling: Framework        March 2003

   might change) and route changes without change of the flow
   specification (e.g. in case of a link failure along the path). The
   former case requires an identifier independent from the flow
   specification.

   When state has been installed along the new path, the existing state
   on the old path needs to be removed. With the soft-state principle,
   this will happen automatically because of the lack of refresh
   messages. Depending on the refresh timer, however, it may be required
   to tear down this state much faster (e.g. because it is tied to an
   accounting record). In that case, the teardown message needs to be
   able to distinguish between the new path and the old path.

   The problem of route changes would not occur if there was a way to do
   route pinning. 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, 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 in the
   presence of route changes. This may involve interactions with the
   basic protocols which are used to manage the routing in this case,
   such as VRRP [19]. A future version of this document may consider
   interactions between NSIS and such protocols in support of high
   availability functionality.

5.2 Mobility Interactions

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

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



Hancock et al.         Expires - September 2003              [Page 29]

                  Next Steps in Signaling: Framework        March 2003

   reservations on both the old path and new path. Similar issues may
   apply to other types 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 NSIS may depend on end system addresses for
   forwarding signaling messages and defining flows (section 4.5.1), the
   special implications of mobility for addressing need to be
   considered. Examples of possible approaches that could be used to
   solve the addressing and encapsulation problem are as follows:

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

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

   In the first approach, to prevent double reservation, NSIS entities
   need to be able to recognize that a session with the new flow
   identifier is to be correlated with an existing one. A session
   identifier could be used for this purpose. This is why the session
   identifier as described in section 4.5.2 has to have end-to-end
   semantics.

   While the feasibility and performance of this first approach needs to
   be assessed, given the high impact of requiring more sophisticated
   packet classifiers, it still seems more plausible than the second
   approach. This implies that signaling applications should define
   flows in terms of real, routable (care of) addresses rather than
   virtual (home) addresses.

5.2.2  Localized Path Repair

   In any mobility approach, a handover will cause at least some changes
   in the path of upstream and downstream packets. At some point along
   the joined path, an NSIS entity should be able to recognize this
   situation, based upon session identification. New state needs to be
   installed on the new path, and removed from the old. Who triggers the
   new state may be constrained by which entities are allowed to carry


Hancock et al.         Expires - September 2003              [Page 30]

                  Next Steps in Signaling: Framework        March 2003

   out which state manipulations, which is then a signaling application
   question.

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

5.2.3  Update on the Unchanged Path

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

   *) Use a session state identification that does not change even if
   the flow definition changes (see Section 4.5.2). Signaling is still
   needed to update a changed flow identification, but it should be
   possible to avoid AAA and admission control processing.

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

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

5.2.4  Interaction with Mobility Signaling

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


Hancock et al.         Expires - September 2003              [Page 31]

                  Next Steps in Signaling: Framework        March 2003

   but simply to point out how they would fit into our framework and any
   major issues with them.

   We can consider that two signaling processes are active: mobility
   signaling and NSIS signaling. The discussion so far considered how
   NSIS signaling should operate. There is still a question of how the
   interactions between the NSIS and mobility signaling should be
   considered.

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

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

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

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

   2.  Carry signaling in the mobility messages, typically as a new
   extension header. This was proposed in [24] and followed up in [25];
   [26] also anticipates this approach. In our framework, we could
   consider this a special case of NSIS layering, with the mobility
   protocol playing the role of the signaling transport.

   Other modes of interaction might also be possible. The critical point
   with all these models is that the general solutions developed by NSIS
   should be independent of mobility protocols. Tight integration would
   have major deployment issues especially in interdomain cases.
   Therefore, any tightly integrated solution is considered out of scope
   of initial NSIS development.


Hancock et al.         Expires - September 2003              [Page 32]

                  Next Steps in Signaling: Framework        March 2003


5.2.5  Interaction with Context Transfer

   In the context of mobility between different access routers, it is
   common to consider performance optimizations in two areas: selection
   of the optimal access router to handover to, and transfer of state
   information between the access routers to avoid having to regenerate
   it in the new access router after handover. The Seamoby Working Group
   is developing solutions for these protocols (CARD [27] and Context
   Transfer [28] respectively); alternative approaches with similar
   characteristics are also possible.

   As these solutions are still underdevelopment, it is premature to
   specify details on the interaction.  It is thought that Context
   Transfer transfers state between access routers based upon changes
   caused by mobility.  NSIS 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
   and possibly higher layer information as payload, we must consider
   the interaction with address translation devices (NATs). As well as
   'traditional' NATs of various types (as defined in [29]) very similar
   considerations would apply to some IPv4/v6 transition mechanisms such
   as SIIT [30].

   In the simplest case of an NSIS unaware NAT in the signaling path,
   payloads will be uncorrected and the signaling will be for the
   incorrect flow. Applications could attempt to use STUN [31] 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 the more
   cautious low-end NAT devices.

   A simple 'NSIS-aware' NAT would require flow identification
   information to be in the clear and not integrity protected. An
   alternative conceptual approach is to consider the NAT functionality
   being part of 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.5.1).




Hancock et al.         Expires - September 2003              [Page 33]

                  Next Steps in Signaling: Framework        March 2003

   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.

6. Signaling Applications

   This section describes 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.

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:
   *) NSIS Initiator (NI): the signaling entity which makes the resource
   request, usually as a result of user application request.
   *) NSIS Responder (NR): the signaling entity that acts as the
   endpoint for the signaling and can optionally interact with
   applications as well.
   *) NSIS Forwarder (NF): the signaling entity an NI and NR 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 role: with respect to the data flow
   direction it could be at the sending or receiving end.

6.1.1  Protocol Messages

   The QoS NSLP will include a set of messages to carry out resource
   reservations along the signaling path. A message set for the QoS NSLP
   is shown below (a very similar set of messages was generated in
   [32]). Note that the 'direction' column in the table below only
   indicates the 'orientation' of the message. The messages can be
   originated and absorbed at NF nodes as well as the NI or NR; an
   example might be NFs 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 modify a reservation,
   during or after setup. This seems mainly a matter of assumptions


Hancock et al.         Expires - September 2003              [Page 34]

                  Next Steps in Signaling: Framework        March 2003

   about authorization, and the possibilities might depend on resource
   type specifics.

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

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 [33] or
   RMD [34] (per 'class' state) respectively.
   *) The protocol must be robust against failure and other conditions,
   which imply that the stored resource reservation state has to be
   moved or removed.



Hancock et al.         Expires - September 2003              [Page 35]

                  Next Steps in Signaling: Framework        March 2003

   For resource reservations, typically soft state management is
   considered for robustness reasons. It is currently open whether the
   soft state protocol aspects should be built into the NSLP for
   specific signaling applications, or provided as a generic service by
   the NTLP; this issue is discussed in section 3.4.2.

6.1.3  QoS Forwarding

   The assumption is that the NTLP works with standard (i.e. best-
   effort) layer 3 routing. There are, however, several proposals for
   the introduction of 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 to a specified set of eBGP
   speakers, that it should not be exported or that the route should be
   prepended n times.

6.1.4  Route Changes and QoS Reservations

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








Hancock et al.         Expires - September 2003              [Page 36]

                  Next Steps in Signaling: Framework        March 2003

                    reserved +----+  reserved  +----+
                     ------->| NF |----------->| NF |
                             +----+            +----+
                  =====================================
                                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
   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 |----------->| NF |
                                +----+            +----+
                        ========== |
                                || |           +----+
                                || +---------->| NF |
                                ||             +----+
                                ============================
                                  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 [4] 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 should wait until resources have been
   reserved on the new path before installing the route change (unless
   of course the old path no longer exists). The route change procedure
   then consists of the following steps:
   1. NF receives a route announcement,
   2. Refresh messages are forwarded along the current path,



Hancock et al.         Expires - September 2003              [Page 37]

                  Next Steps in Signaling: Framework        March 2003

   3. A copy of the refresh message is re-marked as a request and send
   along the new path that was announced,
   4. When the NF has been acknowledged about the reservations on the
   new path the route will be installed and the data will flow along the
   new path.

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

6.1.5  Resource Management Interactions

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

   A QoS NSLP will rely on the RMF to do resource management and to
   provide inputs for admission control. In this model, the RMF acts as
   a server towards client NSLP(s). 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 intradomain QoS signaling, running between just the edges
   of the network (see [35], [36], and [37] 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 (note that co-
   location with an NI/NR can be handled logically as a combination
   between NF and NI/NR). To cater for both cases, we define a (possibly
   logical) NF-RMF interface. Over this interface, information may be
   provided from the RMF about monitoring, resource availability,
   topology, and configuration. In the other direction, the interface


Hancock et al.         Expires - September 2003              [Page 38]

                  Next Steps in Signaling: Framework        March 2003

   may be used to trigger requests for resource provisioning. One way to
   formalize the interface between the NF 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 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], and initial discussions of NSIS-like solutions are contained in
   [38], [39] and [40]. Other examples include network monitoring and
   testing, and tunnel endpoint discovery.

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

7. Security Considerations

   This document describes a 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.6. We have assumed
   that the role of the NTLP will be to provide message protection over
   the scope of a single peer relationship (between adjacent signaling
   entities), and that this can most likely be provided by some kind of
   channel security mechanism using an external key management mechanism
   based on mutual authentication. In addition, the NTLP should be
   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


Hancock et al.         Expires - September 2003              [Page 39]

                  Next Steps in Signaling: Framework        March 2003

   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.

   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 of basing signaling
   application security on NTLP protection. Further work on this and
   other security design will depend on a refinement of the NSIS threats
   work begun in [12].

8. Change History

8.1 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). 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 (section 3.4.2).
   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.4) is assumed
      to be handled by the NSLP level, although session identification
      is still visible to the NTLP (section 4.5.2). The implication is
      that most key aspects of mobility support (section 5.2) are now
      NSLP responsibilities.




Hancock et al.         Expires - September 2003              [Page 40]

                  Next Steps in Signaling: Framework        March 2003

   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


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

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

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

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

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

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

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

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

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

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

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



Hancock et al.         Expires - September 2003              [Page 41]

                  Next Steps in Signaling: Framework        March 2003



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

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

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

   15 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. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
      draft-ietf-idr-bgp4-17.txt (work in progress), January 2002
      (expired)

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

   19 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

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

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

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

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

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




Hancock et al.         Expires - September 2003              [Page 42]

                  Next Steps in Signaling: Framework        March 2003


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

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

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

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

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

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

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

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

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

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

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

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



Hancock et al.         Expires - September 2003              [Page 43]

                  Next Steps in Signaling: Framework        March 2003



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

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

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

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


Acknowledgments

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

Authors' Addresses

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

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





Hancock et al.         Expires - September 2003              [Page 44]

                  Next Steps in Signaling: Framework        March 2003

   Georgios Karagiannis
   Ericsson EuroLab Netherlands B.V.
   Institutenweg 25
   P.O.Box 645
   7500 AP Enschede
   The Netherlands
   email: georgios.karagiannis@eln.ericsson.se

   John Loughney
   Nokia Research Center
   11-13 Italahdenkatu
   00180 Helsinki
   Finland
   email: john.loughney@nokia.com

   Sven Van den Bosch
   Alcatel
   Francis Wellesplein 1
   B-2018 Antwerpen
   Belgium
   email: sven.van_den_bosch@alcatel.be


Intellectual Property Considerations

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat.

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






Hancock et al.         Expires - September 2003              [Page 45]

                  Next Steps in Signaling: Framework        March 2003

Full Copyright Statement

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

























Hancock et al.         Expires - Septemb
                                        er 2003              [Page 46]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/