tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 4080

Pages: 49
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: NSIS

Next Steps in Signaling (NSIS): Framework

Part 1 of 2, p. 1 to 22
None       Next RFC Part


Top       ToC       Page 1 
Network Working Group                                         R. Hancock
Request for Comments: 4080                                   Siemens/RMR
Category: Informational                                   G. Karagiannis
                                           University of Twente/Ericsson
                                                             J. Loughney
                                                        S. Van den Bosch
                                                               June 2005

               Next Steps in Signaling (NSIS): Framework

Status of This Memo

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

Copyright Notice

   Copyright (C) The Internet Society (2005).


   The Next Steps in Signaling (NSIS) working group is considering
   protocols for signaling information about a data flow along its path
   in the network.  The NSIS suite of protocols is envisioned to support
   various signaling applications that need to install and/or manipulate
   such state in the network.  Based on existing work on signaling
   requirements, this document proposes an architectural framework for
   these signaling protocols.

   This document provides a model for the network entities that take
   part in such signaling, and for the relationship between signaling
   and the rest of network operation.  We decompose the overall
   signaling protocol suite into a generic (lower) layer, with separate
   upper layers for each specific signaling application.

Table of Contents

   1. Introduction ....................................................3
      1.1. Definition of the Signaling Problem ........................3
      1.2. Scope and Structure of the NSIS Framework ..................3
   2. Terminology .....................................................4
   3. Overview of Signaling Scenarios and Protocol Structure ..........6
      3.1. Fundamental Signaling Concepts .............................6
           3.1.1. Simple Network and Signaling Topology ...............6

Top      ToC       Page 2 
           3.1.2. Path-Coupled and Path-Decoupled Signaling ...........7
           3.1.3. Signaling to Hosts, Networks, and Proxies ...........8
           3.1.4. Signaling Messages and Network Control State .......10
           3.1.5. Data Flows and Sessions ............................10
      3.2. Layer Model for the Protocol Suite ........................11
           3.2.1. Layer Model Overview ...............................11
           3.2.2. Layer Split Concept ................................12
           3.2.3. Bypassing Intermediate Nodes .......................13
           3.2.4. Core NSIS Transport Layer Functionality ............15
           3.2.5. State Management Functionality .....................16
           3.2.6. Path-Decoupled Operation ...........................17
      3.3. Signaling Application Properties ..........................18
           3.3.1. Sender/Receiver Orientation ........................18
           3.3.2. Uni- and Bi-Directional Operation ..................19
           3.3.3. Heterogeneous Operation ............................19
           3.3.4. Aggregation ........................................20
           3.3.5. Peer-Peer and End-End Relationships ................21
           3.3.6. Acknowledgements and Notifications .................21
           3.3.7. Security and Other AAA Issues ......................22
   4. The NSIS Transport Layer Protocol ..............................23
      4.1. Internal Protocol Components ..............................23
      4.2. Addressing ................................................24
      4.3. Classical Transport Functions .............................24
      4.4. Lower Layer Interfaces ....................................26
      4.5. Upper Layer Services ......................................27
      4.6. Identity Elements .........................................28
           4.6.1. Flow Identification ................................28
           4.6.2. Session Identification .............................28
           4.6.3. Signaling Application Identification ...............29
      4.7. Security Properties .......................................30
   5. Interactions with Other Protocols ..............................30
      5.1. IP Routing Interactions ...................................30
           5.1.1. Load Sharing and Policy-Based Forwarding ...........31
           5.1.2. Route Changes ......................................31
      5.2. Mobility and Multihoming Interactions .....................33
      5.3. Interactions with NATs ....................................36
      5.4. Interactions with IP Tunneling ............................36
   6. Signaling Applications .........................................37
      6.1. Signaling for Quality of Service ..........................37
           6.1.1. Protocol Message Semantics .........................38
           6.1.2. State Management ...................................39
           6.1.3. Route Changes and QoS Reservations .................39
           6.1.4. Resource Management Interactions ...................41
      6.2. Other Signaling Applications ..............................42
   7. Security Considerations ........................................42
   8. References .....................................................43
      8.1. Normative References ......................................43
      8.2. Informative References ....................................44

Top      ToC       Page 3 
1.  Introduction

1.1.  Definition of the Signaling Problem

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

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

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

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

1.2.  Scope and Structure of the NSIS Framework

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

   The role of this framework is to explain how NSIS signaling should
   work within the broader networking context, and to describe the
   overall structure of the protocol suite itself.  Therefore, it

Top      ToC       Page 4 
   discusses important protocol considerations such as routing,
   mobility, security, and interactions with network 'resource'
   management (in the broadest sense).

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

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

   Section 6 describes particular signaling applications.  The example
   of signaling for QoS (comparable to core RSVP QoS signaling
   functionality) is given in detail in Section 6.1, which describes
   both the signaling application specific protocol and example modes of
   interaction with network resource management and other deployment
   aspects.  However, note that these examples are included only as
   background and for explanation; we do not intend to define an
   over-arching architecture for carrying out resource management in the
   Internet.  Further possible signaling applications are outlined in
   Section 6.2.

2.  Terminology

   Classifier: an entity that selects packets based on their contents
      according to defined rules.

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

Top      ToC       Page 5 
   Edge node: an (NSIS-capable) node on the boundary of some
      administrative domain.

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

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

   NSIS Signaling Layer Protocol (NSLP): generic term for an NSIS
      protocol component that supports a specific signaling application.
      See also Section 3.2.1.

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

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

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

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

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

   Receiver: the node in the network that is receiving the data packets
      in a flow.

   Sender: the node in the network that is sending the data packets in a

   Session: application layer flow of information for which some network
      control state information is to be manipulated or monitored (see
      Section 3.1.5).

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

Top      ToC       Page 6 
3.  Overview of Signaling Scenarios and Protocol Structure

3.1.  Fundamental Signaling Concepts

3.1.1.  Simple Network and Signaling Topology

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

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

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

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

Top      ToC       Page 7 
       Sender                                               Receiver
   +-----------+      +----+      +----+      +----+      +-----------+
   |Application|----->| R1 |----->| R2 |----->| R3 |----->|Application|
   |   +--+    |      |+--+|      |+--+|      +----+      |   +--+    |
   |   |NE|====|======||NE||======||NE||==================|===|NE|    |
   |   +--+    |      |+--+|      |+--+|                  |   +--+    |
   +-----------+      +----+      +----+                  +-----------+

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

                 Figure 1: Simple Signaling and Data Flows

3.1.2.  Path-Coupled and Path-Decoupled Signaling

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

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

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

Top      ToC       Page 8 
3.1.3.  Signaling to Hosts, Networks, and Proxies

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

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

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

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

Top      ToC       Page 9 
                 Proxy1                        Proxy2
   +------+      +----+    +----+    +----+    +----+      +--------+
   |Sender|-...->|Appl|--->| R  |--->| R  |--->|Appl|-...->|Receiver|
   |      |      |+--+|    |+--+|    |+--+|    |+--+|      |        |
   +------+      ||NE||====||NE||====||NE||====||NE||      +--------+
                 |+--+|    |+--+|    |+--+|    |+--+|
                 +----+    +----+    +----+    +----+

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

      Appl = signaling application

                      Figure 2: "On path" NSIS proxy

   This configuration presents two specific challenges for the

   o  A proxy that terminates signaling on behalf of the NSIS-unaware
      host (or part of the network) should be able to determine that it
      is the last NSIS-aware node along the path.

   o  Where a proxy initiates NSIS signaling on behalf of the NSIS-
      unaware host, interworking with some other "local" technology
      might be required (for example, to provide QoS reservation from
      proxy to the end host in the case of a QoS signaling application).

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

            Appl = signaling         PA = Proxy for signaling
                   application            application

                      Figure 3: "Off path" NSIS proxy

Top      ToC       Page 10 
   Another possible configuration, shown in Figure 3, is where an NE can
   send and receive signaling information to a remote processor.  The
   NSIS protocols may or may not be suitable for this remote
   interaction, but in any case it is not currently part of the NSIS
   problem.  This configuration is supported by considering the NE a
   proxy at the signaling application level.  This is a natural
   implementation approach for some policy control and centralized
   control architectures; see also Section 6.1.4.

3.1.4.  Signaling Messages and Network Control State

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

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

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

3.1.5.  Data Flows and Sessions

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

   A session is an application layer concept for an exchange of packets
   between two endpoints, for which some network state is to be
   allocated or monitored.  In simple cases, a session may map to a
   specific flow; however, signaling applications are allowed to create

Top      ToC       Page 11 
   more flexible flow:session relationships.  (Note that this concept of
   'session' is different from that of RSVP, which defines a session as
   a flow with a specific destination address and transport protocol.
   The NSIS usage is closer to the session concepts of higher-layer

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

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

3.2.  Layer Model for the Protocol Suite

3.2.1.  Layer Model Overview

   In order to achieve a modular solution for the NSIS requirements, the
   NSIS protocol suite will be structured in two layers:

   o  a 'signaling transport' layer, responsible for moving signaling
      messages around, which should be independent of any particular
      signaling application; and

   o  a 'signaling application' layer, which contains functionality such
      as message formats and sequences, specific to a particular
      signaling application.

   For the purpose of this document, we use the term 'NSIS Transport
   Layer Protocol' (NTLP) to refer to the component that will be used in
   the transport layer.  We also use the term 'NSIS Signaling Layer
   Protocol' (NSLP) to refer generically to any protocol within the
   signaling application layer; in the end, there will be several NSLPs,
   largely independent of each other.  These relationships are

Top      ToC       Page 12 
   illustrated in Figure 4.  Note that the NTLP may or may not have an
   interesting internal structure (e.g., including existing transport
   protocols), but that is not relevant at this level of description.

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

                    Figure 4: NSIS Protocol Components

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

3.2.2.  Layer Split Concept

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

   The way in which the NTLP works can be described as follows: When a
   signaling message is ready to be sent from one NE, it is given to the
   NTLP along with information about what flow it is for; it is then up
   to the NTLP to get it to the next NE along the path (upstream or
   downstream), where it is received and the responsibility of the NTLP
   ends.  Note that there is no assumption here about how the messages
   are actually addressed (this is a protocol design issue, and the

Top      ToC       Page 13 
   options are outlined in Section 4.2).  The key point is that the NTLP
   for a given NE does not use any knowledge about addresses,
   capabilities, or status of any NEs other than its direct peers.

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

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

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

3.2.3.  Bypassing Intermediate Nodes

   Because the NSIS problem includes multiple signaling applications, it
   is very likely that a particular NSLP will only be implemented on a
   subset of the NSIS-aware nodes on a path, as shown in Figure 5.  In
   addition, a node inside an aggregation region will still wish to
   ignore signaling messages that are per-flow, even if they are for a
   signaling application that the node is generally able to process.

Top      ToC       Page 14 
               +------+    +------+    +------+    +------+
               |  NE  |    |  NE  |    |  NE  |    |  NE  |
               |+----+|    |      |    |+----+|    |+----+|
               ||NSLP||    |      |    ||NSLP||    ||NSLP||
               || 1  ||    |      |    || 2  ||    || 1  ||
               |+----+|    |      |    |+----+|    |+----+|
               |  ||  |    |      |    |      |    |  ||  |
               |+----+|    |+----+|    |+----+|    |+----+|
               |+----+|    |+----+|    |+----+|    |+----+|
               +------+    +------+    +------+    +------+

               Figure 5: Signaling with Heterogeneous NSLPs

   Where signaling messages traverse such NSIS-aware intermediate nodes,
   it is desirable to process them at the lowest level possible (in
   particular, on the fastest path).  In order to offer a non-trivial
   message transfer service (in terms of security, reliability and so
   on) to the peer NSLP nodes, it is important that the NTLP at
   intermediate nodes is as transparent as possible; that is, it carries
   out minimal processing.  In addition, if intermediate nodes have to
   do slow-path processing of all NSIS messages, this eliminates many of
   the scaling benefits of aggregation, unless tunneling is used.

   Considering first the case of messages sent with the router alert
   option, there are two complementary methods to achieve this bypassing
   of intermediate NEs:

   o  At the IP layer, a set of protocol numbers or a range of values in
      the router alert option can be used.  In this way, messages can be
      marked with an implied granularity, and routers can choose to
      apply further slow-path processing only to configured subsets of
      messages.  This is the method used in [10] to distinguish per-flow
      and per-aggregate signaling.

   o  The NTLP could process the message but determine that there was no
      local signaling application it was relevant to.  At this stage,
      the message can be returned unchanged to the IP layer for normal
      forwarding; the intermediate NE has effectively chosen to be
      transparent to the message in question.

   In both cases, the existence of the intermediate NE is totally hidden
   from the NSLP nodes.  If later stages of the signaling use directly
   addressed messages (e.g., for reverse routing), they will not involve
   the intermediate NE at all, except perhaps as a normal router.

Top      ToC       Page 15 
   There may be cases where the intermediate NE would like to do some
   restricted protocol processing, such as the following:

   o  Translating addresses in message payloads (compare Section 4.6.1);
      note that this would have to be done to messages passing in both
      directions through a node.

   o  Updating signaling application payloads with local status
      information (e.g., path property measurement inside a domain).

   If this can be done without fully terminating the NSIS protocols, it
   would allow a more lightweight implementation of the intermediate NE,
   and a more direct 'end-to-end' NTLP association between the peer
   NSLPs where the signaling application is fully processed.  On the
   other hand, this is only possible with a limited class of possible
   NTLP designs, and makes it harder for the NTLP to offer a security
   service (since messages have to be partially protected).  The
   feasibility of this approach will be evaluated during the NTLP

3.2.4.  Core NSIS Transport Layer Functionality

   This section describes the basic functionality to be supported by the
   NTLP.  Note that the overall signaling solution will always be the
   result of joint operation of both the NTLP and the signaling layer
   protocols (NSLPs); for example, we can always assume that an NSLP is
   operating above the NTLP and taking care of end-to-end issues (e.g.,
   recovery of messages after restarts).

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

Top      ToC       Page 16 
3.2.5.  State Management Functionality

   Internet signaling requires the existence and management of state
   within the network for several reasons.  This section describes how
   state management functionality is split across the NSIS layers.
   (Note that how the NTLP internal state is managed is a matter for its
   design and indeed implementation.)

   1.  Conceptually, the NTLP provides a uniform message delivery
       service.  It is unaware of the difference in state semantics
       between different types of signaling application messages (e.g.,
       whether a message changes, just refreshes signaling application
       state, or even has nothing to with signaling application state at

   2.  An NTLP instance processes and, if necessary, forwards all
       signaling application messages "immediately".  (It might offer
       different service classes, but these would be distinguished by,
       for example, reliability or priority, not by state aspects.)
       This means that the NTLP does not know explicit timer or message
       sequence information for the signaling application; and that
       signaling application messages pass immediately through an
       NSLP-unaware node.  (Their timing cannot be jittered there, nor
       can messages be stored up to be re-sent on a new path in case of
       a later re-routing event.)

   3.  Within any node, it is an implementation decision whether to
       generate/jitter/filter refreshes separately within each signaling
       application that needs this functionality, or to integrate it
       with the NTLP implementation as a generic "soft-state management
       toolbox".  The choice doesn't affect the NTLP specification at
       all.  Implementations might piggyback NTLP soft-state refresh
       information (if the NTLP works this way) on signaling application
       messages, or they might even combine soft-state management
       between layers.  The state machines of the NTLP and NSLPs remain
       logically independent, but an implementation is free to allow
       them to interact to reduce the load on the network to the same
       level that would be achieved by a monolithic model.

   4.  It may be helpful for signaling applications to receive
       state-management related 'triggers' from the NTLP indicating that
       a peer has failed or become available ("down/up notifications").
       These triggers would be about adjacent NTLP peers, rather than
       signaling application peers.  We can consider this another case
       of route change detection/notification (which the NTLP is also
       allowed to do anyway).  However, apart from generating such

Top      ToC       Page 17 
       triggers, the NTLP takes no action itself on such events, other
       than to ensure that subsequent signaling messages are routed

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

3.2.6.  Path-Decoupled Operation

   Path-decoupled signaling is defined as signaling for state
   installation along the data path, without the restriction of passing
   only through nodes that are located on the data path.  Signaling
   messages can be routed to nodes that are off the data path, but that
   are (presumably) aware of it.  This allows a looser coupling between
   signaling and data plane nodes (e.g., at the autonomous system
   level).  Although support for path-decoupled operation is not one of
   the initial goals of the NSIS work, this section is included for
   completeness and to capture some initial considerations for future

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

   There are potentially significant differences in the way that the two
   signaling paradigms should be analyzed.  Using a single centralized
   off-path NE may increase the requirements in terms of message
   handling; on the other hand, path-decoupled signaling is equally
   applicable to distributed off-path entities.  Failure recovery
   scenarios need to be analyzed differently because fate-sharing
   between data and control planes can no longer be assumed.
   Furthermore, the interpretation of sender/receiver orientation
   becomes less natural.  With the local operation of the NTLP, the
   impact of path-decoupled signaling on the routing of signaling
   messages is presumably restricted to the problem of peer
   determination.  The assumption that the off-path NSIS nodes are
   loosely tied to the data path suggests, however, that peer
   determination can still be based on L3 routing information.  This

Top      ToC       Page 18 
   means that a path-decoupled signaling solution could be implemented
   using a lower-layer protocol presenting the same service interface to
   NSLPs as the path-coupled NTLP.  A new message transport protocol
   (possibly derived from the path-coupled NTLP) would be needed, but
   NSLP specifications and the inter-layer interaction would be
   unchanged from the path-coupled case.

3.3.  Signaling Application Properties

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

3.3.1.  Sender/Receiver Orientation

   In some signaling applications, a node at one end of the data flow
   takes responsibility for requesting special treatment (such as a
   resource reservation) from the network.  Which end may depend on the
   signaling application, or on characteristics of the network

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

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

   o  In a receiver-initiated approach, the signaling messages traveling
      from the receiver to the sender must be backward routed such that
      they follow exactly the same path as was followed by the signaling
      messages belonging to the same flow traveling from the sender to
      the receiver.  In a sender-initiated approach, provided that
      acknowledgements and notifications can be delivered securely to
      the sending node, backward routing is not necessary, and nodes do
      not have to maintain backward routing state.

Top      ToC       Page 19 
   o  In a sender-initiated approach, a mobile node can initiate a
      reservation for its outgoing flows as soon as it has moved to
      another roaming subnetwork.  In a receiver-initiated approach, a
      mobile node has to inform the receiver about its handover, thus
      allowing the receiver to initiate a reservation for these flows.
      For incoming flows, the reverse argument applies.

   o  In general, setup and modification will be fastest if the node
      responsible for authorizing these actions can initiate them
      directly within the NSLP.  A mismatch between authorizing and
      initiating NEs will cause additional message exchanges, either in
      the NSLP or in a protocol executed prior to NSIS invocation.
      Depending on how the authorization for a particular signaling
      application is done, this may favor either sender- or receiver-
      initiated signaling.  Note that this may complicate modification
      of network control state for existing flows.

3.3.2.  Uni- and Bi-Directional Operation

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

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

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

3.3.3.  Heterogeneous Operation

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

Top      ToC       Page 20 
   One way to address this issue is to consider the state description
   used within the NSLP as carried in globally-understood objects and
   locally-understood objects.  The local objects are only applicable
   for intra-domain signaling, while the global objects are mainly used
   in inter-domain signaling.  Note that the local objects are still
   part of the protocol but are inserted, used, and removed by one
   single domain.

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

3.3.4.  Aggregation

   It is a well-known problem that per-flow signaling in large-scale
   networks presents scaling challenges because of the large number of
   flows that may traverse individual nodes.

   The possibilities for aggregation at the level of the NTLP are quite
   limited; the primary scaling approach for path-coupled signaling is
   for a signaling application to group flows together and to perform
   signaling for the aggregate, rather than for the flows individually.
   The aggregate may be created in a number of ways; for example, the
   individual flows may be sent down a tunnel, or given a common
   Differentiated Services Code Point (DSCP) marking.  The aggregation
   and de-aggregation points perform per flow signaling, but nodes
   within the aggregation region should only be forced to process
   signaling messages for the aggregate.  This depends on the ability of
   the interior nodes to ignore the per-flow signaling as discussed in
   Section 3.2.3.

   Individual NSLPs will need to specify what aggregation means in their
   context, and how it should be performed.  For example, in the QoS
   context it is possible to add together the resources specified in a
   number of separate reservations.  In the case of other applications,
   such as signaling to NATs and firewalls, the feasibility (and even
   the meaning) of aggregation is less clear.

Top      ToC       Page 21 
3.3.5.  Peer-Peer and End-End Relationships

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

   The peering relations may also have an impact on the required amount
   of state at each NSIS entity.  When direct interaction with remote
   peers is not allowed, it may be required to keep track of the path
   that a message has followed through the network.  This could be
   achieved by keeping per-flow state at the NSIS entities, as is done
   in RSVP.  Another approach would be to maintain a record route object
   in the messages; this object would be carried within the NSIS
   protocols, rather than depend on the route-recording functionality
   provided by the IP layer.

3.3.6.  Acknowledgements and Notifications

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

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

   Acknowledgements can be sent along the sequence of NTLP peer
   relationships towards the signaling initiator, which relieves the
   requirements on the security associations that need to be maintained
   by NEs and that can allow NAT traversal in both directions.  (If this
   direction is towards the sender, it implies maintaining reverse
   routing state in the NTLP.)  In certain circumstances (e.g., trusted
   domains), an optimization could be to send acknowledgements directly
   to the signaling initiator outside the NTLP (see Section 3.2.2),
   although any such approach would have to take into account the
   necessity of handling denial of service attacks launched from outside
   the network.

   The semantics of the acknowledgement messages are of particular
   importance.  An NE sending a message could assume responsibility for
   the entire downstream chain of NEs, indicating (for instance) the
   availability of reserved resources for the entire downstream path.
   Alternatively, the message could have a more local meaning,
   indicating (for instance) that a certain failure or degradation
   occurred at a particular point in the network.

Top      ToC       Page 22 
   Notifications differ from acknowledgements because they are not
   (necessarily) generated in response to other signaling messages.
   This means that it may not be obvious how to determine where the
   notification should be sent.  Other than that, the same
   considerations apply as for acknowledgements.  One useful distinction
   to make would be to differentiate between notifications that trigger
   a signaling action and others that don't.  The security requirements
   for the latter are less stringent, which means they could be sent
   directly to the NE they are destined for (provided that this NE can
   be determined).

3.3.7.  Security and Other AAA Issues

   In some cases, it will be possible to achieve the necessary level of
   signaling security by using basic 'channel security' mechanisms [11]
   at the level of the NTLP, and the possibilities are described in
   Section 4.7.  In other cases, signaling applications may have
   specific security requirements, in which case they are free to invoke
   their own authentication and key exchange mechanisms and to apply
   'object security' to specific fields within the NSLP messages.

   In addition to authentication, the authorization (to manipulate
   network control state) has to be considered as functionality above
   the NTLP level, since it will be entirely application specific.
   Indeed, authorization decisions may be handed off to a third party in
   the protocol (e.g., for QoS, the resource management function as
   described in Section 6.1.4).  Many different authorization models are
   possible, and the variations impact:

   o  what message flows take place -- for example, whether
      authorization information is carried along with a control state
      modification request or is sent in the reverse direction in
      response to it;

   o  what administrative relationships are required -- for example,
      whether authorization takes place only between peer signaling
      applications, or over longer distances.

   Because the NTLP operates only between adjacent peers and places no
   constraints on the direction or order in which signaling applications
   can send messages, these authorization aspects are left open to be
   defined by each NSLP.  Further background discussion of this issue is
   contained in [12].

Next RFC Part