Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: NSIS

RFC 4080

Next Steps in Signaling (NSIS): Framework

Pages: 49
Part 2 of 2 – Pages 23 to 49
First   Prev   None

Top   ToC   RFC4080 - Page 23   prevText
4.  The NSIS Transport Layer Protocol

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

   This discussion is not intended to design the NTLP or even to
   enumerate design options, although some are included as examples.
   The goal is to provide a general discussion of required functionality
   and to highlight some of the issues associated with this.

4.1.  Internal Protocol Components

   The NTLP includes all functionality below the signaling application
   layer and above the IP layer.  The functionality that is required
   within the NTLP is outlined in Section 3.2.4, with some more details
   in Sections 3.2.5 and 4.3.

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

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

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

                   Figure 6: Options for NTLP Structure
Top   ToC   RFC4080 - Page 24
4.2.  Addressing

   There are two ways to address a signaling message being transmitted
   between NTLP peers:

   o  peer-peer, where the message is addressed to a neighboring NSIS
      entity that is known to be closer to the destination NE.

   o  end-to-end, where the message is addressed to the flow destination
      directly and intercepted by an intervening NE.

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

   In the case of end-to-end addressing, the message is addressed to the
   data flow receiver, and (some of) the NEs along the data path
   intercept the messages.  The routing of the messages should follow
   exactly the same path as the associated data flow (but see
   Section 5.1.1 on this point).  Note that securing messages sent this
   way raises some interesting security issues (these are discussed in
   [2]).  In addition, it is a matter of the protocol design what should
   be used as the source address of the message (the flow source or
   signaling source).

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

4.3.  Classical Transport Functions

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

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

   The following functionality is assumed to lie within the NTLP:

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

   2.  When needed, message fragmentation should be provided by the
       NTLP.  The use of IP fragmentation for large messages may lead to
       reduced reliability and may be incompatible with some addressing
       schemes.  Therefore, this functionality should be provided within
       the NTLP as a service for NSLPs that generate large messages.
       How the NTLP determines and accommodates Maximum Transmission
       Unit (MTU) constraints is left as a matter of protocol design.
       To avoid imposing the cost of reassembly on intermediate nodes,
       the fragmentation scheme used should allow for the independent
       forwarding of individual fragments towards a node hosting an
       interested NSLP.

   3.  There can be significant benefits for signaling applications if
       state-changing messages are delivered reliably (as introduced in
       [13] for RSVP; see also the more general analysis of [14]).  This
       does not change any assumption about the use of soft-state by
       NSLPs to manage signaling application state, and it leaves the
       responsibility for detecting and recovering from application
       layer error conditions in the NSLP.  However, it means that such
       functionality does not need to be tuned to handle fast recovery
       from message loss due to congestion or corruption in the lower
       layers, and it also means that the NTLP can prevent the
Top   ToC   RFC4080 - Page 26
       amplification of message loss rates caused by fragmentation.
       Reliable delivery functionality is invoked by the NSLP on a
       message-by-message basis and is always optional to use.

   4.  The NTLP should not allow signaling messages to cause congestion
       in the network (i.e., at the IP layer).  Congestion could be
       caused by retransmission of lost signaling packets or by upper
       layer actions (e.g., a flood of signaling updates to recover from
       a route change).  In some cases, it may be possible to engineer
       the network to ensure that signaling cannot overload it; in
       others, the NTLP would have to detect congestion and to adapt the
       rate at which it allows signaling messages to be transmitted.
       Principles of congestion control in Internet protocols are given
       in [15].  The NTLP may or may not be able to detect overload in
       the control plane itself (e.g., an NSLP-aware node several
       NTLP-hops away that cannot keep up with the incoming message
       rate) and indicate this as a flow-control condition to local
       signaling applications.  However, for both the congestion and
       overload cases, it is up to the signaling applications themselves
       to adapt their behavior accordingly.

4.4.  Lower Layer Interfaces

   The NTLP interacts with 'lower layers' of the protocol stack for the
   purposes of sending and receiving signaling messages.  This framework
   places the lower boundary of the NTLP at the IP layer.  The interface
   to the lower layer is therefore very simple:

   o  The NTLP sends raw IP packets

   o  The NTLP receives raw IP packets.  In the case of peer-peer
      addressing, they have been addressed directly to it.  In the case
      of end-to-end addressing, this will be achieved by intercepting
      packets that have been marked in some special way (by special
      protocol number or by some option interpreted within the IP layer,
      such as the router alert option).

   o  The NTLP receives indications from the IP layer (including local
      forwarding tables and routing protocol state) that provide some
      information about route changes and similar events (see
      Section 5.1).

   For correct message routing, the NTLP needs to have some information
   about link and IP layer configuration of the local networking stack.
   In general, it needs to know how to select the outgoing interface for
   a signaling message and where this must match the interface that will
   be used by the corresponding flow.  This might be as simple as just
   allowing the IP layer to handle the message using its own routing
Top   ToC   RFC4080 - Page 27
   table.  There is no intention to do something different from IP
   routing (for end-to-end addressed messages); however, some hosts
   allow applications to bypass routing for their data flows, and the
   NTLP processing must account for this.  Further network layer
   information would be needed to handle scoped addresses (if such
   things ever exist).

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

4.5.  Upper Layer Services

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

   For sending and receiving messages, two basic control primitives are

   o  Send Message, to allow the signaling application to pass data to
      the NTLP for transport.

   o  Receive Message, to allow the NTLP to pass received data to the
      signaling application.

   The NTLP and signaling application may also want to exchange other
   control information, such as the following:

   o  Signaling application registration/de-registration, so that
      particular signaling application instances can register their
      presence with the transport layer.  This may also require some
      identifier to be agreed upon between the NTLP and signaling
      application to support the exchange of further control information
      and to allow the de-multiplexing of incoming data.

   o  NTLP configuration, allowing signaling applications to indicate
      what optional NTLP features they want to use, and to configure
      NTLP operation, such as controlling what transport layer state
      should be maintained.

   o  Error messages, to allow the NTLP to indicate error conditions to
      the signaling application, and vice versa.

   o  Feedback information, such as route change indications so that the
      signaling application can decide what action to take.
Top   ToC   RFC4080 - Page 28
4.6.  Identity Elements

4.6.1.  Flow Identification

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

   Information that could be used in flow identification may include:

   o  source IP address;

   o  destination IP address;

   o  protocol identifier and higher layer (port) addressing;

   o  flow label (typical for IPv6);

   o  SPI field for IPsec encapsulated data; and

   o  DSCP/TOS field.

   It is assumed that at most limited wildcarding on these identifiers
   is needed.

   We assume here that the flow identification is not hidden within the
   NSLP, but is explicitly part of the NTLP.  The justification for this
   is that being able to do NSIS processing, even at a node which was
   unaware of the specific signaling application (see Section 3.2.3)
   might be valuable.  An example scenario would be messages passing
   through an addressing boundary where the flow identification had to
   be re-written.

4.6.2.  Session Identification

   There are circumstances in which being able to refer to signaling
   application state independently of the underlying flow is important.
   For example, if the address of one of the flow endpoints changes due
   to a mobility event, it is desirable to be able to change the flow
   identifier without having to install a completely new reservation.
   The session identifier provides a method to correlate the signaling
   about the different flows with the same network control state.
Top   ToC   RFC4080 - Page 29
   The session identifier is essentially a signaling application
   concept, since it is only used in non-trivial state management
   actions that are application specific.  However, we assume here that
   it should be visible within the NTLP.  This enables it to be used to
   control NTLP behavior; for example, by controlling how the transport
   layer should forward packets belonging to this session (as opposed to
   this signaling application).  In addition, the session identifier can
   be used by the NTLP to demultiplex received signaling messages
   between multiple instances of the same signaling application, if such
   an operational scenario is supported (see Section 4.6.3 for more
   information on signaling application identification).

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

4.6.3.  Signaling Application Identification

   Because the NTLP can be used to support several NSLP types, there is
   a need to identify which type a particular signaling message exchange
   is being used for.  This is to support:

   o  processing of incoming messages -- the NTLP should be able to
      demultiplex these towards the appropriate signaling applications;

   o  processing of general messages at an NSIS-aware intermediate node
      -- if the node does not handle the specific signaling application,
      it should be able to make a forwarding decision without having to
      parse upper-layer information.

   No position is taken on the form of the signaling application
   identifier, or even the structure of the signaling application
   'space': free-standing applications, potentially overlapping groups
   of capabilities, etc.  These details should not influence the rest of
   the NTLP design.
Top   ToC   RFC4080 - Page 30
4.7.  Security Properties

   It is assumed that the only security service required within the NTLP
   is channel security.  Channel security requires a security
   association to be established between the signaling endpoints, which
   is carried out via some authentication and key management exchange.
   This functionality could be provided by reusing a standard protocol.

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

   Channel security can provide many different types of protection to
   signaling exchanges, including integrity and replay protection and
   encryption.  It is not clear which of these is required at the NTLP
   layer, although most channel security mechanisms support them all.
   It is also not clear how tightly an NSLP can 'bind' to the channel
   security service provided by the NTLP.

   Channel security can also be applied to the signaling messages with
   differing granularity; i.e., all or parts of the signaling message
   may be protected.  For example, if the flow is traversing a NAT, only
   the parts of the message that do not need to be processed by the NAT
   should be protected.  (Alternatively, if the NAT takes part in NTLP
   security procedures, it only needs to be given access to the message
   fields containing addresses, often just the flow id.)  Which parts of
   the NTLP messages need protecting is an open question, as is what
   type of protection should be applied to each.

5.  Interactions with Other Protocols

5.1.  IP Routing Interactions

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

   Load sharing or load balancing is a network optimization technique
   that exploits the existence of multiple paths to the same destination
   in order to obtain benefits in terms of protection, resource
   efficiency, or network stability.  It has been proposed for a number
   of routing protocols, such as OSPF [16] and others.  In general, load
   sharing means that packet forwarding will take into account header
   fields in addition to the destination address; a general discussion
   of such techniques and the problems they cause is provided in [17].

   The significance of load sharing in the context of NSIS is that
   routing of signaling messages using end-to-end addressing does not
   guarantee that these messages will follow the data path.  Policy-
   based forwarding for data packets -- where the outgoing link is
   selected based on policy information about fields additional to the
   packet destination address -- has the same impact.  Signaling and
   data packets may diverge because of both of these techniques.

   If signaling packets are given source and destination addresses
   identical to data packets, signaling and data may still diverge
   because of layer-4 load balancing (based on protocol or port).  Such
   techniques would also cause ICMP errors to be misdirected to the
   source of the data because of source address spoofing.  If signaling
   packets are made identical in the complete 5-tuple, divergence may
   still occur because of the presence of router alert options.  The
   same ICMP misdirection applies, and it becomes difficult for the end
   systems to distinguish between data and signaling packets.  Finally,
   QoS routing techniques may base the routing decision on any field in
   the packet header (e.g., DSCP).

5.1.2.  Route Changes

   In a connectionless network, each packet is independently routed
   based on its header information.  Whenever a better route towards the
   destination becomes available, this route is installed in the
   forwarding table and will be used for all subsequent (data and
   signaling) packets.  This can cause a divergence between the path
   along which state has been installed and the path along which
   forwarding will actually take place.  The problem of route changes is
   reduced if route pinning is performed.  Route pinning refers to the
   independence of the path taken by certain data packets from
   reachability changes caused by routing updates from an Interior
   Gateway Protocol (OSPF, IS-IS) or an Exterior Gateway Protocol (BGP).
   Nothing about NSIS signaling prevents route pinning from being used
   as a network engineering technique, provided that it is done in a way
Top   ToC   RFC4080 - Page 32
   that preserves the common routing of signaling and data.  However,
   even if route pinning is used, it cannot be depended on to prevent
   all route changes (for example, in the case of link failures).

   Handling route changes requires the presence of three processes in
   the signaling protocol:

   1.  route change detection

   2.  installation of state on the new path

   3.  removal of state on the old path

   Many route change detection methods can be used, some needing
   explicit protocol support, and some of which are implementation-
   internal.  They differ in their speed of reaction and in the types of
   change they can detect.  In rough order of increasing applicability,
   they can be summarized as follows:

   1.  monitoring changes in local forwarding table state

   2.  monitoring topology changes in a link-state routing protocol

   3.  inference from changes in data packet TTL

   4.  inference from loss of packet stream in a flow-aware router

   5.  inference from changes in signaling packet TTL

   6.  changed route of an end-to-end addressed signaling packet

   7.  changed route of a specific end-to-end addressed probe packet

   These methods can be categorized as being based on network monitoring
   (methods 1-2), on data packet monitoring (methods 3-4) and on
   monitoring signaling protocol messages (methods 5-7); method 6 is the
   baseline method of RSVP.  The network monitoring methods can only
   detect local changes; in particular, method 1 can only detect an
   event that changes the immediate next downstream hop, and method 2
   can only detect changes within the scope of the link-state protocol.
   Methods 5-7, which are contingent on monitoring signaling messages,
   become less effective as soft-state refresh rates are reduced.

   When a route change has been detected, it is important that state is
   installed as quickly as possible along the new path.  It is not
   guaranteed that the new path will be able to provide the same
   characteristics that were available on the old path.  To avoid
   duplicate state installation or, worse, rejection of the signaling
Top   ToC   RFC4080 - Page 33
   message because of previously installed state, it is important to be
   able to recognize the new signaling message as belonging to an
   existing session.  In this respect, we distinguish between route
   changes with associated change of the flow identification (e.g., in
   case of a mobility event when the IP source might change) and route
   changes without change of the flow identification (e.g., in case of a
   link failure along the path).  The former case requires an identifier
   independent from the flow identification; i.e., the session
   identifier (Section 4.6.2).  Mobility issues are discussed in more
   detail in Section 5.2.

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

   In some environments, it is desirable to provide connectivity and
   per-flow or per-class state management with high-availability
   characteristics; i.e., with rapid transparent recovery, even in the
   presence of route changes.  This may require interactions with
   protocols that are used to manage the routing in this case, such as
   Virtual Router Redundancy Protocol (VRRP) [18].

   Our basic assumption about such interactions is that the NTLP would
   be responsible for detecting the route change and ensuring that
   signaling messages were re-routed consistently (in the same way as
   the data traffic).  However, further state re-synchronization
   (including failover between 'main' and 'standby' nodes in the high
   availability case) would be the responsibility of the signaling
   application and its NSLP, and would possibly be triggered by the

5.2.  Mobility and Multihoming Interactions

   The issues associated with mobility and multihoming are a
   generalization of the basic route change case of the previous
   section.  As well as the fact that packets for a given session are no
   longer traveling over a single topological path, the following extra
   considerations arise:

   1.  The use of IP-layer mobility and multihoming means that more than
       one IP source or destination address will be associated with a
       single session.  The same applies if application-layer solutions
       (e.g., SIP-based approaches) are used.
Top   ToC   RFC4080 - Page 34
   2.  Mobile IP and associated protocols use some special
       encapsulations for some segments of the data path.

   3.  The double route may persist for some time in the network (e.g.,
       in the case of a 'make-before-break' handover being done by a
       multihomed host).

   4.  Conversely, the re-routing may be rapid and routine (unlike
       network-internal route changes), increasing the importance of
       rapid state release on old paths.

   The interactions between mobility and signaling have been extensively
   analyzed in recent years, primarily in the context of RSVP and Mobile
   IP interaction (e.g., the mobility discussion of [5]), but also in
   that of other types of network (e.g., [19]).  A general review of the
   fundamental interactions is given in [20], which provides further
   details on many of the subjects considered in this section.

   We assume that the signaling will refer to 'outer' IP headers when
   defining the flows it is controlling.  There are two main reasons for
   this.  The first is that the data plane will usually be unable to
   work in terms of anything else when implementing per-flow treatment
   (e.g., we cannot expect that a router will analyze inner headers to
   decide how to schedule packets).  The second reason is that we are
   implicitly relying on the security provided by the network
   infrastructure to ensure that the correct packets are given the
   special treatment being signaled for, and this is built on the
   relationship between packet source and destination addresses and
   network topology.  (This is essentially the same approach that is
   used as the basis of route optimization security in Mobile IPv6
   [21].)  The consequence of this assumption is that we see the packet
   streams to (or from) different addresses as different flows.  Where a
   flow is carried inside a tunnel, it is seen as a different flow
   again.  The encapsulation issues (point (2) above) are therefore to
   be handled the same way as other tunneling cases (Section 5.4).

   Therefore, the most critical aspect is that multiple flows are being
   used, and the signaling for them needs to be correlated.  This is the
   intended role of the session identifier (see Section 4.6.2, which
   also describes some of the security requirements for such an
   identifier).  Although the session identifier is visible at the NTLP,
   the signaling application is responsible for performing the
   correlation (and for doing so securely).  The NTLP responsibility is
   limited to delivering the signaling messages for each flow between
   the correct signaling application peers.  The locations at which the
   correlation takes place are the end system and the signaling-
Top   ToC   RFC4080 - Page 35
   application-aware node in the network where the flows meet.  (This
   node is generally referred to as the "crossover router"; it can be
   anywhere in the network.)

   Although much work has been done in the past on finding the crossover
   router directly from information held in particular mobility
   signaling protocols, the initial focus of NSIS work should be a
   solution that is not tightly bound to any single mobility approach.
   In other words, it should be possible to determine the crossover
   router based on NSIS signaling.  (This doesn't rule out the
   possibility that some implementations may be able to do this
   discovery faster; e.g., by being tightly integrated with local
   mobility management protocols.  This is directly comparable to
   spotting route changes in fixed networks by being routing aware.)

   Note that the crossover router discovery may involve end-to-end
   signaling exchanges (especially for flows towards the mobile or
   multihomed node), which raises a latency concern.  On the other hand,
   end-to-end signaling will have been necessary in any case, at the
   application level not only to communicate changed addresses, but also
   to update packet classifiers along the path.  It is a matter for
   further analysis to decide how these exchanges could be combined or
   carried out in parallel.

   On the shared part of the path, signaling is needed at least to
   update the packet classifiers to include the new flow, although if
   correlation with the existing flow is possible it should be possible
   to bypass any policy or admission control processing.  State
   installation on the new path (and possibly release on the old one)
   are also required.  Which entity (one of the end hosts or the
   crossover router) controls all these procedures depends on which
   entities are authorized to carry out network state manipulations, so
   this is therefore a matter of signaling application and NSLP design.
   The approach may depend on the sender/receiver orientation of the
   original signaling (see Section 3.3.1).  In addition, in the mobility
   case, the old path may no longer be directly accessible to the mobile
   node; inter-access-router communication may be required to release
   state in these circumstances.

   The frequency of handovers in some network types makes fast handover
   support protocols desirable, for selecting the optimal access router
   for handover (for example, [22]), and for transferring state
   information to avoid having to regenerate it in the new access router
   after handover (for example, [23]).  Both of these procedures could
   have strong interactions with signaling protocols.  The access router
   selection might depend on the network control state that could be
Top   ToC   RFC4080 - Page 36
   supported on the path through the new access router.  Transfer of
   signaling application state or NTLP/NSLP protocol state may be a
   candidate for context transfer.

5.3.  Interactions with NATs

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

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

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

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

5.4.  Interactions with IP Tunneling

   Tunneling is used in the Internet for a number of reasons, such as
   flow aggregation, IPv4/6 transition mechanisms, mobile IP, virtual
   private networking, and so on.  An NSIS solution must continue to
   work in the presence of these techniques.  The presence of the tunnel
   should not cause problems for end-to-end signaling, and it should
   also be possible to use NSIS signaling to control the treatment of
   the packets carrying the tunneled data.
Top   ToC   RFC4080 - Page 37
   It is assumed that the NSIS approach will be similar to that of [27],
   where the signaling for the end-to-end data flow is tunneled along
   with that data flow and is invisible to nodes along the path of the
   tunnel (other than the endpoints).  This provides backwards
   compatibility with networks where the tunnel endpoints do not support
   the NSIS protocols.  We assume that NEs will not unwrap tunnel
   encapsulations to find and process tunneled signaling messages.

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

6.  Signaling Applications

   This section gives an overview of NSLPs for particular signaling
   applications.  The assumption is that the NSLP uses the generic
   functionality of the NTLP given earlier; this section describes
   specific aspects of NSLP operation.  It includes simple examples that
   are intended to clarify how NSLPs fit into the framework.  It does
   not replace or even form part of the formal NSLP protocol
   specifications; in particular, initial designs are being developed
   for NSLPs for resource reservation [28] and middlebox communication

6.1.  Signaling for Quality of Service

   In the case of signaling for QoS, all the basic NSIS concepts of
   Section 3.1 apply.  In addition, there is an assumed directionality
   of the signaling process, in that one end of the signaling flow takes
   responsibility for actually requesting the resource.  This leads to
   the following definitions:

   o  QoS NSIS Initiator (QNI): the signaling entity that makes the
      resource request, usually as a result of user application request.

   o  QoS NSIS Responder (QNR): the signaling entity that acts as the
      endpoint for the signaling and that can optionally interact with
      applications as well.

   o  QoS NSIS Forwarder (QNF): a signaling entity between a QNI and QNR
      that propagates NSIS signaling further through the network.
Top   ToC   RFC4080 - Page 38
   Each of these entities will interact with a resource management
   function (RMF) that actually allocates network resources (router
   buffers, interface bandwidth, and so on).

   Note that there is no constraint on which end of the signaling flow
   should take the QNI role: With respect to the data flow direction, it
   could be at the sending or receiving end.

6.1.1.  Protocol Message Semantics

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

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

   | Operation | Direction |                 Operation                 |
   |  Request  |   I-->R   |    Create a new reservation for a flow    |
   |           |           |                                           |
   |   Modify  |   I-->R   |       Modify an existing reservation      |
   |           | (&R-->I?) |                                           |
   |           |           |                                           |
   |  Release  |   I-->R   |       Delete (tear down) an existing      |
   |           | (&R-->I?) |                reservation                |
   |           |           |                                           |
   |  Accept/  |   R-->I   |  Confirm (possibly modified?) or reject a |
   |   Reject  |           |            reservation request            |
   |           |           |                                           |
   |   Notify  |  I-->R &  |    Report an event detected within the    |
   |           |   R-->I   |                  network                  |
   |           |           |                                           |
   |  Refresh  |   I-->R   |    State management (see Section 6.1.2)   |
Top   ToC   RFC4080 - Page 39
6.1.2.  State Management

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

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

   o  The protocol must be scalable.  It should allow minimization of
      the resource reservation state-storage demands that it implies for
      intermediate nodes; in particular, storage of state per 'micro'
      flow is likely to be impossible except at the very edge of the
      network.  A QoS signaling application might require per-flow or
      lower granularity state; examples of each for the case of QoS
      would be IntServ [30] or RMD [31] (per 'class' state),

   o  The protocol must be robust against failure and other conditions
      that imply that the stored resource reservation state has to be
      moved or removed.

   For resource reservations, soft-state management is typically used as
   a general robustness mechanism.  According to the discussion of
   Section 3.2.5, the soft-state protocol mechanisms are built into the
   NSLP for the specific signaling application that needs them; the NTLP
   sees this simply as a sequence of (presumably identical) messages.

6.1.3.  Route Changes and QoS Reservations

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

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

                 Figure 7: Normal NSIS Protocol Operation
Top   ToC   RFC4080 - Page 40
   A route change can occur while such a reservation is in place.  The
   route change will be installed immediately, and any data will be
   forwarded on the new path.  This situation is depicted Figure 8.

   Resource reservation on the new path will only be started once the
   next control message is routed along the new path.  This means that
   there is a certain time interval during which resources are not
   reserved on (part of) the data path, and certain delay or
   drop-sensitive applications will require that this time interval be
   minimized.  Several techniques to achieve this could be considered.
   As an example, RSVP [7] has the concept of local repair, whereby the
   router may be triggered by a route change.  In that case, the RSVP
   node can start sending PATH messages directly after the route has
   been changed.  Note that this option may not be available if no
   per-flow state is kept in the QNF.  Another approach would be to
   pre-install backup state, and it would be the responsibility of the
   QoS-NSLP to do this.  However, mechanisms for identifying backup
   paths and routing the necessary signaling messages along them are not
   currently considered in the NSIS requirements and framework.

                              Route update
                       reserved +-----+  reserved  +-----+
                      =========>| QNF |===========>| QNF |
                                +-----+            +-----+
                       --------   ||
                               \  ||           +-----+
                                |  ===========>| QNF |
                                |              +-----+
                                  data path

                          Figure 8: Route Change

   The new path might not be able to provide the same guarantees that
   were available on the old path.  Therefore, it might be desirable for
   the QNF to wait until resources have been reserved on the new path
   before allowing the route change to be installed (unless, of course,
   the old path no longer exists).  However, delaying the route change
   installation while waiting for reservation setup needs careful
   analysis of the interaction with the routing protocol being used, in
   order to avoid routing loops.

   Another example related to route changes is denoted as severe
   congestion and is explained in [31].  This solution adapts to a route
   change when a route change creates congestion on the new routed path.
Top   ToC   RFC4080 - Page 41
6.1.4.  Resource Management Interactions

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

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

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

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

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

6.2.  Other Signaling Applications

   As well as the use for 'traditional' QoS signaling, it should be
   possible to develop NSLPs for other signaling applications that
   operate on different types of network control state.  One specific
   case is setting up flow-related state in middleboxes (firewalls,
   NATs, and so on).  Requirements for such communication are given in
   [4].  Other examples include network monitoring and testing, and
   tunnel endpoint discovery.

7.  Security Considerations

   This document describes a framework for signaling protocols that
   assumes a two-layer decomposition, with a common lower layer (NTLP)
   supporting a family of signaling-application-specific upper-layer
   protocols (NSLPs).  The overall security considerations for the
   signaling therefore depend on the joint security properties assumed
   or demanded for each layer.

   Security for the NTLP is discussed in Section 4.7.  We have assumed
   that, apart from being resistant to denial of service attacks against
   itself, the main role of the NTLP will be to provide message
   protection over the scope of a single peer relationship, between
   adjacent signaling application entities.  (See Section 3.2.3 for a
   discussion of the case where these entities are separated by more
   than one NTLP hop.)  These functions can ideally be provided by an
   existing channel security mechanism, preferably using an external key
   management mechanism based on mutual authentication.  Examples of
   possible mechanisms are TLS, IPsec and SSH.  However, there are
   interactions between the actual choice of security protocol and the
   rest of the NTLP design.  Primarily, most existing channel security
   mechanisms require explicit identification of the peers involved at
   the network and/or transport level.  This conflicts with those
   aspects of path-coupled signaling operation (e.g., discovery) where
   this information is not even implicitly available because peer
   identities are unknown; the impact of this 'next-hop problem' on RSVP
   design is discussed in the security properties document [6] and also
   influences many parts of the threat analysis [2].  Therefore, this
   framework does not mandate the use of any specific channel security
   protocol; instead, this has to be integrated with the design of the
   NTLP as a whole.
Top   ToC   RFC4080 - Page 43
   Security for the NSLPs is entirely dependent on signaling application
   requirements.  In some cases, no additional protection may be
   required compared to what is provided by the NTLP.  In other cases,
   more sophisticated object-level protection and the use of public-
   key-based solutions may be required.  In addition, the NSLP needs to
   consider the authorization requirements of the signaling application.
   Authorization is a complex topic, for which a very brief overview is
   provided in Section 3.3.7.

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

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

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

8.  References

8.1.  Normative References

   [1]   Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
         April 2004.

   [2]   Tschofenig, H. and D. Kroeselberg, "Security Threats for Next
         Steps in Signaling (NSIS)", RFC 4081, June 2005.

   [3]   Chaskar, H., "Requirements of a Quality of Service (QoS)
         Solution for Mobile IP", RFC 3583, September 2003.

   [4]   Swale, R., Mart, P., Sijben, P., Brim, S., and M. Shore,
         "Middlebox Communications (midcom) Protocol Requirements",
         RFC 3304, August 2002.
Top   ToC   RFC4080 - Page 44
8.2.  Informative References

   [5]   Manner, J. and X. Fu, "Analysis of Existing Quality of Service
         Signaling Protocols", Work in Progress, December 2004.

   [6]   Tschofenig, H., "RSVP Security Properties", Work in Progress,
         February 2005.

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

   [8]   Katz, D., "IP Router Alert Option", RFC 2113, February 1997.

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

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

   [11]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on
         Security Considerations", BCP 72, RFC 3552, July 2003.

   [12]  Tschofenig, H., "NSIS Authentication, Authorization and
         Accounting Issues", Work in Progress, March 2003.

   [13]  Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F., and S.
         Molendini, "RSVP Refresh Overhead Reduction Extensions",
         RFC 2961, April 2001.

   [14]  Ji, P., Ge, Z., Kurose, J., and D. Townsley, "A Comparison of
         Hard-State and Soft-State Signaling Protocols", Computer
         Communication Review, Volume 33, Number 4, October 2003.

   [15]  Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
         September 2000.

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

   [17]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
         Multicast Next-Hop Selection", RFC 2991, November 2000.

   [18]  Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC
         3768, April 2004.
Top   ToC   RFC4080 - Page 45
   [19]  Heijenk, G., Karagiannis, G., Rexhepi, V., and L. Westberg,
         "DiffServ Resource Management in IP-based Radio Access
         Networks", Proceedings of 4th International Symposium on
         Wireless Personal Multimedia Communications WPMC'01, September
         9 - 12 2001.

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

   [21]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
         IPv6", RFC 3775, June 2004.

   [22]  Liebsch, M., Ed., Singh, A., Ed., Chaskar, H., Funato, D., and
         E. Shim, "Candidate Access Router Discovery (CARD)", Work in
         Progress, May 2005.

   [23]  Kempf, J., "Problem Description: Reasons For Performing Context
         Transfers Between Nodes in an IP Access Network", RFC 3374,
         September 2002.

   [24]  Srisuresh, P. and M. Holdrege, "IP Network Address Translator
         (NAT) Terminology and Considerations", RFC 2663, August 1999.

   [25]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
         RFC 2765, February 2000.

   [26]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [27]  Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP
         Operation Over IP Tunnels", RFC 2746, January 2000.

   [28]  Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for
         Quality-of-Service signaling", Work in Progress, February 2005.

   [29]  Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol
         (NSLP)", Work in Progress, February 2005.

   [30]  Braden, R., Clark, D., and S. Shenker, "Integrated Services in
         the Internet Architecture: an Overview", RFC 1633, June 1994.
Top   ToC   RFC4080 - Page 46
   [31]  Westberg, L., Csaszar, A., Karagiannis, G., Marquetant, A.,
         Partain, D., Pop, O., Rexhepi, V., Szabo, R., and A. Takacs,
         "Resource Management in Diffserv (RMD): A Functionality and
         Performance Behavior Overview", Seventh International Workshop
         on Protocols for High-Speed networks PfHSN 2002, 22 - 24
         April 2002.

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

   [33]  Nichols, K., Jacobson, V., and L. Zhang, "A Two-bit
         Differentiated Services Architecture for the Internet",
         RFC 2638, July 1999.
Top   ToC   RFC4080 - Page 47
Appendix A.  Contributors

   Several parts of the introductory sections of this document (in
   particular, in Sections 3.1 and 3.3) are based on contributions from
   Ilya Freytsis, then of Cetacean Networks, Inc.

   Bob Braden originally proposed "A Two-Level Architecture for Internet
   Signalling" as an Internet-Draft in November 2001.  This document
   served as an important starting point for the framework discussed
   herein, and the authors owe a debt of gratitude to Bob for this

Appendix B.  Acknowledgements

   The authors would like to thank Bob Braden, Maarten Buchli, Eleanor
   Hepworth, Andrew McDonald, Melinda Shore, and Hannes Tschofenig for
   significant contributions in particular areas of this document.  In
   addition, the authors would like to acknowledge Cedric Aoun, Attila
   Bader, Anders Bergsten, Roland Bless, Marcus Brunner, Louise Burness,
   Xiaoming Fu, Ruediger Geib, Danny Goderis, Kim Hui, Cornelia Kappler,
   Sung Hycuk Lee, Thanh Tra Luu, Mac McTiffin, Paulo Mendes, Hans De
   Neve, Ping Pan, David Partain, Vlora Rexhepi, Henning Schulzrinne,
   Tom Taylor, Michael Thomas, Daniel Warren, Michael Welzl, Lars
   Westberg, and Lixia Zhang for insights and inputs during this and
   previous framework activities.  Dave Oran, Michael Richardson, and
   Alex Zinin provided valuable comments during the final review stages.
Top   ToC   RFC4080 - Page 48
Authors' Addresses

   Robert Hancock
   Siemens/Roke Manor Research
   Old Salisbury Lane
   Romsey, Hampshire  SO51 0ZN


   Georgios Karagiannis
   University of Twente
   P.O. BOX 217
   7500 AE Enschede
   The Netherlands


   John Loughney
   Nokia Research Center
   11-13 Itamerenkatu
   Helsinki  00180


   Sven Van den Bosch
   Francis Wellesplein 1
   B-2018 Antwerpen

Top   ToC   RFC4080 - Page 49
Full Copyright Statement

   Copyright (C) The Internet Society (2005).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.