Internet Draft          Proposal for RSVPv2-NSLP              April 2003


Internet Engineering Task Force                             L. Westberg
INTERNET-DRAFT                                                 A. Bader
Expires October 2003                                         D. Partain
                                                             V. Rexhepi

                                                               Ericsson

                                                         G. Karagiannis

                                                   University of Twente

                                                             April 2003


                       A Proposal for RSVPv2-NSLP
             draft-westberg-proposal-for-rsvpv2-nslp-00.txt
                   Document Version: $Revision: 2.1 $




Status of this memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.  Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts as
   reference material or to cite them other than as "work in progress."

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

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this memo is unlimited.



Copyright Notice





Westberg, et al.          Expires October 2003                  [Page 1]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






      Copyright (C) The Internet Society (2002). All Rights Reserved.




Abstract

   The Resource ReSerVation Protocol (RSVPv1) has been on the standards
   track within the IETF for a number of years. During that time, the
   level of vendor support and deployment has been relatively slow,
   despite the demand for technologies offering services with different
   levels of quality of service to their customers. This memo seeks to
   initiate a dialog about the design of a new version of RSVPv1, called
   RSVPv2, that meet the requirements formulated by IETF NSIS working
   group. It also outlines the motivation for using RSVP2 as "next step
   in signaling".

   The RSVPv2 framework uses the layer-split architecture separating
   signaling application and transport functions. This concept was
   adopted by NSIS WG and the two layers are called NSLP NSIS Signaling
   Layer Protocol (NSLP) and NSIS Transport Layer Protocol (NTLP). This
   draft provides design guidelines and specifications for the
   development of the RSVPv2 NSLP part.

   RSVP2-NSLP offers increased modularity and contains less mandatory
   objects compared to RSVPv1, which allow lightweight implementation
   and flexible application. The new protocol is extended with PHR and
   PDR objects that makes it possible to use the protocol in different
   part of multi-domain networks and use the protocol in DiffServ
   environment.




















Westberg, et al.          Expires October 2003                  [Page 2]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003




Table of Contents

   1 Introduction .................................................    5
   1.1 Definitions/Terminology ....................................    6
   2 Motivation for RSVPv2 ........................................   10
   2.1 Limitation of RSVPv1 design ................................   11
   2.1.1 Designed for Multicast Applications ......................   11
   2.1.2 Least Common Denominator Not Small Enough ................   11
   2.1.3 Sender-initiated versus  Receiver-initiated  Signalling
        ...........................................................   12
   2.1.4 Designed for End-host to End-host Communication ..........   13
   2.2  Different Network Signalling Requirements/Needs and RSVP
        ...........................................................   13
   3 Design Goals and General Features for RSVPv2-NSLP ............   14
   3.1 Increased Layer Modularity and Extendibility ...............   14
   3.2 Increased Object Modularity ................................   15
   3.3 Hierarchical Object Structure ..............................   15
   3.4 Global and Local Objects ...................................   16
   3.5 Local information exchange .................................   16
   3.6 Object Re-use ..............................................   17
   3.7 Reduced Focus on Multicast .................................   17
   3.8 Primarily Sender-initiated Signalling ......................   17
   3.9 Low latency in setup .......................................   17
   3.10 Highest possible network utilization ......................   18
   3.11 Uni / bi-directional reservation ..........................   18
   3.12 End-to-end ................................................   18
   3.13 Edge-to-edge ..............................................   18
   3.14 End-to-edge ...............................................   19
   4 Overview of the RSVPv2-NSLP Framework ........................   19
   4.1 RSVPv2 NSLP protocol features provided by  the  intra-do-
        main level
             ......................................................   22
   4.1.1 PDR protocol part functions ..............................   23
   4.1.2 PHR protocol part functions ..............................   23
   4.2 RSVPv2 NSLP protocol features provided by the e2e service
        level .....................................................   25
   5 RSVPv2 NSLP specification ....................................   26
   5.1 RSVPv2 NSLP Object Classes structure .......................   26
   5.1.1 RSVPv2 NSLP Message Structure ............................   29
   5.2 RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes ..........   29
   5.2.1 Example of mapping of RSVPv1 [RFC2205] objects in ........   30
   5.2.2 PDR/PHR objects ..........................................   33
   5.3 RSVPv2-NSLP functionality on nodes used for  inter-domain
        signaling .................................................   33
   5.3.1 NI (NSIS Initiator) functionality ........................   33
   5.3.1.1 Unidirectional functionality ...........................   33
   5.3.1.2 Bidirectional functionality ............................   35





Westberg, et al.          Expires October 2003                  [Page 3]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   5.3.2 NF (NSIS Forwarder) functionality ........................   36
   5.3.2.1 Unidirectional functionality ...........................   36
   5.3.2.2 Bidirectional functionality ............................   38
   5.3.3 NR (NSIS Responder) functionality ........................   39
   5.3.3.1 Bidirectional functionality ............................   40
   5.4  RSVPv2-NSLP functionality on nodes used for intra-domain
        signaling .................................................   41
   5.4.1 NI (NSIS Initiator) functionality ........................   41
   5.4.1.1 Unidirectional functionality ...........................   42
   5.4.1.2 Bidirectional functionality ............................   42
   5.4.2 Functionality of NF (NSIS  Forwarder)  located  outside
        NSIS intra-domain .........................................   42
   5.4.2.1 Unidirectional functionality ...........................   42
   5.4.2.2 Bidirectional functionality ............................   42
   5.4.3 NF (ingress) functionality ...............................   42
   5.4.3.1 Unidirectional functionality ...........................   43
   5.4.3.2 Bidirectional functionality ............................   48
   5.4.4 NF (interior) functionality ..............................   49
   5.4.4.1 Unidirectional functionality ...........................   49
   5.4.4.2 Bidirectional functionality ............................   51
   5.4.5 NF (egress) functionality ................................   51
   5.4.5.1 Unidirectional functionality ...........................   52
   5.4.5.2 Bidirectional functionality ............................   55
   5.4.6 NR (NSIS Responder) functionality ........................   56
   5.4.6.1 Unidirectional functionality ...........................   56
   5.4.6.2 Bidirectional functionality ............................   56
   6 Example of RSVPv2-NSLP Inter-domain signaling procedures .....   57
   6.1 Normal operation for uni-directional reservation ...........   57
   6.2 Normal operation for bi-directional reservation ............   62
   7 Example of RSVPv2-NSLP Intra-domain signaling procedures .....   65
   7.1 Normal operation for uni-directional reservation ...........   65
   7.2 Example of Fault Handling Operation ........................   80
   7.2.1 Loss of NTLP signalling messages .........................   81
   7.2.2 Severe Congestion Handling operation .....................   81
   7.2.2.1 Proportional marking ...................................   82
   7.3 Example of Adaptation to load sharing operation ............   84
   7.4 Normal operation for bi-directional reservation ............   84
   8  Appendix   - Examples of PHR and PDR object specifications
        ...........................................................   90
   8.1 PHR objects ................................................   90
   8.2 PDR objects ................................................   93
   9 References ...................................................   98
   10 Authors' Addresses ..........................................  101







Westberg, et al.          Expires October 2003                  [Page 4]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






1.  Introduction

   A number of different QoS solutions have been developed by the IETF,
   amongst them IntServ and its signaling protocol, RSVPv1, defined in
   [RFC2205].  RSVPv1 [RFC2205] is a resource reservation signaling
   protocol that was designed to be applied in an end-to-end
   communication path.  It can be used by an application to make its QoS
   requirements known and reserve resources in all the network nodes in
   the path.

   RSVPv1 has not enjoyed the level of deployment that might have been
   expected.  This is due to issues such as design constraints as it is
   optimized for multicast, etc. [RFC2475, RFC3175, etc].  This memo
   seeks to initiate a dialog about the design of a new version of
   RSVPv1, which we call RSVPv2.  The goal of the RSVPv2 framework would
   be to rectify the issues that have been identified with RSVPv1 and
   provide an evolutionary path forward.

   The RSVPv2 framework uses the concept introduced in [BrLi01] that
   splits signaling protocol into two layers:

       (1) a common lower level protocol that performs transport-layer
           and soft-state functions. This common lower level is called
           CSTP ("Common Signaling Transport Protocol").

       (2) a set of upper-level signaling functions that are specific
           to particular signaling applications. These upper-level
           signaling tasks and functions are accomplished by a set of
           ULSPs ("User Layer Signaling Protocols).

   The CSTP together with the set of ULSPs will implement the Internet
   Signaling Protocol Suite (ISPS). The NSIS working group adopted this
   concept denoting the two protocols as NSIS Transport Layer Protocol
   (NTLP) and NSIS Signaling Layer Protocol (NSLP), respectively
   [Hanc03].

   This memo outlines the motivation for using RSVPv2-NSLP as NSIS
   Signaling Layer Protocol. It provides a design guideline and
   specification for RSVPv2-NSLP. Note that in order to be able to
   communicate with NTLP, RSVPv2-NSLP needs to use an NSLP Identifier
   that has to be assigned by the NSIS WG. RSVPv2-NSLP specified in this
   draft is able to interwork with NTLP specified in [WeKa03].








Westberg, et al.          Expires October 2003                  [Page 5]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






1.1.  Definitions/Terminology


      Interdomain traffic:

        Traffic that passes from one NSIS domain to
        another ([identical to [Hanc03]).

      Intra-domain NSIS signaling is where the NSIS signaling messages are
         originated, processed and terminated within the same NSIS domain.

      NSIS Domain (ND) (identical to [Hanc03]):

        Administrative domain where an NSIS protocol
        signals for a resource or set of resources.

      NSIS Entity (NE) (identical to [Hanc03]):

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

      NSIS Forwarder (NF) (identical to [Hanc03]):

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

      NF Edge nodes:

        NF Nodes that are located at the boundary of an administrative
        domain, e.g., Diffserv. This node is a NTLP stateful node.

      NF Interior node:

        All the nodes that are part of an administrative domain, e.g.,
        Diffserv, and are not NF edge nodes. An interior node can be
        either a NTLP stateful node or a NTLP stateless node.

      NF Ingress node:

        An NF edge node that handles the traffic as it enters the
        domain. This node is a NTLP stateful node.

      NF Egress node:





Westberg, et al.          Expires October 2003                  [Page 6]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






        An NF edge node that handles the traffic as it leaves the
        domain. This node is a NTLP stateful node.

      NSIS Initiator (NI) (identical to [Hanc03]):

        NSIS Entity that initiates NSIS signaling for a
        network resource.

      NSIS Responder (NR) (identical to [Hanc03]):

        NSIS Entity that terminates NSIS signaling and
        can optionally interact with applications as well.

      NSIS Signaling Layer Protocol (NSLP) (identical to [Hanc03]):

        generic term for an NSIS protocol component that supports a specific
        signaling application.

      NSIS Transport Layer Protocol (NTLP) (identical to [Hanc03]):
        placeholder name for the NSIS protocol component that will support
        lower layer (signaling application independent) functions.

      NTLP aware node:

         a node that implements and supports the NTLP protocol.

      NTLP stateful node:

         a NTLP aware node that maintains a NTLP transport layer state.

      NTLP stateless node:

         a NTLP aware node that does not maintain a NTLP transport layer
         state.

      NE NTLP stateful

        NE entity that is NTLP stateful.

      NE NTLP stateless

        NE entity that is NTLP stateless.

      NF NTLP stateful






Westberg, et al.          Expires October 2003                  [Page 7]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






        NF entity that is NTLP stateful.

      NF NTLP stateless

        NF entity that is NTLP stateless.

      Resource Management Function (RMF) (identical to [Hanc03]):

         an abstract concept,
         representing the management of resources in a domain or a node.

      End Host:

        QoS-aware end terminal, either fixed or mobile, i.e. running
        QoS-aware applications. This node is a NTLP stateful node and it
        can be considered as a NI or a NR.

   RSVPv2 NSLP:

      an NSLP type that can be a part of the RSVPv2 framework.

   NSLP intra-domain:

      a domain that supports NSIS intra-domain signaling.

   Classifier - an entity which selects packets based on the content of
      packet headers according to defined rules.

   DS behavior aggregate (identical to [RFC2475]):

     A collection of packets with the same DS codepoint crossing
     a link in a particular direction.

   DS-compliant (identical to [RFC2475]):

     Enabled to support differentiated services functions and
     behaviors as defined in [RFC2474], this document, and other
     differentiated services documents; usually used in reference
     to a node or device.

   Interdomain traffic - Traffic that passes from one NSIS domain to
      another

   Intra-domain NSIS signaling is where the NSIS signaling messages are
      originated, processed and terminated within the same NSIS domain.





Westberg, et al.          Expires October 2003                  [Page 8]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR
      which may interact with local resource management function (RMF)
      The NSIS Forwarder also propagates NSIS signaling further through the
      network (identical to [Hanc03]). Note that NF can be also
      considered as a RSVPv2 forwarder.

   NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
      network resource (identical to [Hanc03]). Note that NI can be also
      considered as a RSVPv2 initiator.

   NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
      can optionally interact with applications as well
      (identical to [Hanc03]). Note that NR can be also considered as a
      RSVPv2 responder.

   Path-coupled signaling - a mode of signaling where the signaling
      messages follow a path that is tied to the data messages
      (see [Hanc03]).

   Path-decoupled signaling - signaling with independent data and
      signaling paths (see [Hanc03]).

   Per Hop Behavior (PHB) (identical to [RFC2475]):

     The externally observable forwarding behavior applied at
     a DS-compliant node to a DS behavior aggregate.

   Per Hop Reservation (PHR):

     The per-hop resource reservation in a Diffserv domain,
     extending the Diffserv PHB, e.g., the bandwidth allocated to
     an AF PHB (see RFC2597]), with resource reservation.  It is
     implemented at both the interior nodes and the edge nodes.

   Per Hop Reservation (PHR) protocol:

     A type of protocol that is used to perform a per hop
     reservation.  A PHR protocol part is used in all nodes in the
     Diffserv domain (both edge and interior nodes) on a hop by
     hop basis.

   Per Domain Behavior (PDB)(similar to [NiKa01]):

     Describes the behavior experienced by a particular set of
     packets as they cross a DS domain. A PDB is characterized





Westberg, et al.          Expires October 2003                  [Page 9]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






     by specific metrics that quantify the treatment that a set
     of packets with a particular DSCP (or set of DSCPs) will
     receive as it crosses a DS domain.

   Per Domain Reservation (PDR):

     The resource reservation functionality in the complete Diffserv domain.

   Per Domain Reservation (PDR) protocol:

     A type of signaling protocol used to perform a per domain
     reservation signaling.
     A PDR protocol part is used by NF(edge) nodes (NF(ingress)
     and NF(egress)),
     but not by the NF(interior) nodes.

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



   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].




2.  Motivation for RSVPv2


   Embarking on the adventure of creating RSVPv2 is not to be done
   lightly.  A great deal of effort was put into the design of the
   IntServ model and its signaling protocol, RSVPv1.  As such, there
   must be a clear need for the evolution of the QoS signaling part of
   RSVPv1. This section tries to provide that motivation.

   We believe that this work can be accomplished by examining the design
   constraints placed upon the development of RSVPv1 and eliminate these
   constraints in RSVPv2 design.








Westberg, et al.          Expires October 2003                 [Page 10]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






2.1.  Limitation of RSVPv1 design

   RSVPv1 is well-designed for the applications for which it was
   intended and worked hard to provide a modular protocol within the
   constraints of its intended use.  We see value in questioning the
   applications chosen, thereby improving the protocol.

   This section outlines some of the design considerations that went
   into the design of RSVPv1, which in turn led to decisions that make
   it difficult to use RSVPv1 beyond its originally-intended scope.


2.1.1.  Designed for Multicast Applications

    One of the most important design requirement for RSVPv1 was support
    for multicast applications.  RFC 1633 [RFC1633] states, "There are a
    number of requirements to be met by the design of a reservation
    setup protocol.  It should be fundamentally designed for a multicast
    environment...."

    Multicast support introduces a level of complexity into the protocol
    that is not needed in support of unicast applications.  For example,
    RSVPv1's state maintenance is complex as it needs to support dynamic
    membership changes in the multicast groups, such as reservation
   state
    merging and maintenance.

    Our working assumption is that RSVPv2 should be optimized for
   unicast
    rather than multicast and that relaxing this design constraint will
    in turn greatly simplify the protocol.


2.1.2.  Least Common Denominator Not Small Enough

   Rightfully so, RSVPv1 put a great deal of effort into creating a
   modular protocol with the ability to use those pieces that apply in a
   particular setting.  However, this modularity was created with the
   backdrop of multicast applications.  This means that, while modular
   to some degree, even the "least common denominator" of objects that
   must be carried is too heavy in some networking contexts.  That is,
   while flexible, RSVPv1 does not allow for more lightweight
   implementations if fewer features are needed in certain parts of the
   network.






Westberg, et al.          Expires October 2003                 [Page 11]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   The fact that the least common denominator is too heavy means that:

     * Some objects are always carried in RSVPv1 messages that are
       not applicable in some settings.

     * There is an expectation of the same level of protocol
       functionality throughout the network(s).  Clearly, different
       parts of the network need different levels of functionality,
       a differentiation not supported by RSVPv1.

    On May 20, 2002, Bob Braden, one of the creators of RSVPv1, wrote
   the
    following on the NSIS working group's mailing list [NSIS-ML1]:

       "...RSVP may have had the modularity wrong....  RSVP design and
         specification may have talked too much about int-serv specific
         things like Tspecs.  We should instead have defined RSVP strictly
         in terms of transporting opaque QoS objects upstream and
         downstream...."

   Our working assumption is that RSVPv2 can be created with even more
   modularity to enable its use in most (if not all) networking
   contexts.  In particular, we believe that RSVPv2 can be made more
   suitable for use in the different parts of the network where
   requirements on the signaling protocol differ greatly.



2.1.3.  Sender-initiated versus Receiver-initiated Signalling

   RSVPv1 is receiver-oriented, which is to say that the receiver of a
   data flow initiates and maintains the resource reservation used for
   that flow.  This choice was made despite the fact that sender-
   initiated reservations are "perhaps the most obvious choice" since
   sender-initiated reservations "scale poorly for large, dynamic
   multicast delivery trees and for heterogeneous receivers" (Section
   5.1.3, RFC 1633 [RFC1633]).  These two problems were solved by using
   receiver-initiated reservations.

   Our working assumption is that relaxation of the requirement for
   multicast support will also allow for sender-initiated reservations
   without introducing scalability problems.








Westberg, et al.          Expires October 2003                 [Page 12]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






2.1.4.  Designed for End-host to End-host Communication

   RSVPv1 was primarily designed with signaling between end-host systems
   in mind.  This communication implies a certain set of requirements on
   the entities involved and on the kinds of information that they need
   to signal.

   In recent work (particularly in NSIS), it has become clear that there
   are in fact several different kinds of signaling conversations that
   may be needed in different parts of the network.  Each of these kinds
   of signaling implies a different -- and potentially conflicting --
   set of requirements on the signaling protocol.  For example, the
   signaling requirements for the conversation between the end-host and
   the network may indeed need more complexity than RSVPv1 whereas the
   signaling needs in a DiffServ-capable access network would require
   significantly less.

   Our working assumption is that RSVPv2 must be designed to allow an
   appropriate set of objects to be defined for the various "interfaces"
   (e.g., host-to-network, edge-to-edge, end-to-end) used in various
   parts of the network while not including any mandatory objects that
   are not applicable in all parts of the network.


2.2.  Different Network Signalling Requirements/Needs and RSVP

    As previously mentioned, RSVPv1 put a great deal of effort into
    creating a modular protocol with the ability to use those pieces
   that
    apply in a particular setting.  However, while flexible, RSVPv1 does
    not allow for more lightweight implementations if fewer features are
    needed in certain network scenarios.

   This section provides a (non-exhaustive) list of scenarios where
   there seems to be a need for new tools, either because the need for
   optimization is sufficiently strong or the scenario was not
   considered in the design of RSVPv1.


     * Networks with semi-permanent trunk aggregation: In such
       networks the transmission links are not expensive and
       semi-permanent trunk aggregation can be applied.

     * Networks with trusted end hosts: In these networks the
       security requirements are less important. Such networks are





Westberg, et al.          Expires October 2003                 [Page 13]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






       the networks used between PSTN (Public Switched Telephone
       Networks) gateways and backbone routers [PAN-SSP].

     * Networks with untrusted mobile end hosts: In these networks
       the security requirements between the first hop access router
       and the untrusted mobile end host are very significant. Such
       networks are the networks that use wireless LAN (WLAN)
       access [RFC2002].

     * Networks that have to support fast and frequent mobility
       procedures (e.g., handover), where the transmission links
       are expensive, and the majority of the traffic is unicast.
       Cellular radio access networks are examples of such networks.
       [RAN-ISSUE].



3.  Design Goals and General Features for RSVPv2-NSLP

   This section briefly outlines some of the guiding principles behind
   the design of RSVPv2-NSLP. Moreover, the RSVPv2 NSLP general features
   are described. These design goals and features are in line with some
   of the NSIS requirements described in [Bru03] and [Hanc03].


3.1.  Increased Layer Modularity and Extendibility

   The essential design goal for RSVPv2 framework is to preserve the
   flexibility of RSVPv1 while at the same time further expanding its
   modularity. It can be fulfilled by using the NTLP-NSLP layer-split
   architecture.

   The RSVPv2-NSLP protocol can be considered as an NSLP that will use a
   subset of the transport layer functions provided by the NTLP (see for
   example [WeKa03]) such as:


     * Support of Path-Coupled (Path-Directed) Signaling;

     * Soft state support: This feature ensures that a state
       will be removed if it is not periodically refreshed or
       explicitly removed.

     * Adaptation to load sharing. Load sharing allows NF interior
       nodes to take advantage of multiple routes to the same





Westberg, et al.          Expires October 2003                 [Page 14]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






       destination by sending via some or all of these available
       routes. The NTLP protocol level has to adapt to load sharing
       once it is used.

     * The NTLP signaling protocol should be able to exchange local
       information between NSIS Forwarders located within one single
       administrative domain. Local information might, for example,
       be IP addresses, severe congestion notification, notification
       of successful or erroneous processing of signaling messages.



3.2.  Increased Object Modularity

   The purpose of the object modularity is to increase processing
   efficiency of RSVPv2 NTLP messages by only including those objects
   relevant in a particular part of the network.

   RSVPv1 uses flexible object definitions that are opaque to RSVPv1 for
   transporting and maintaining traffic and policy control parameters.
   This type of object definition has certain advantages in terms of
   flexibility, but one of its main disadvantages is that each RSVPv1
   message may contain up to fourteen classes of attribute objects. Even
   if some of the RSVPv1 objects are not needed in a scenario they will
   have to be included in RSVPv1 messages and considered as mandatory
   objects.

   In order to achieve modularity, the RSVPv2-NSLP object structure will
   need to have less (possibly no) "mandatory" functionality and allow a
   more open object structure.

   This open object structure can be solved by enhancing the RSVPv1
   object structure and by introducing a concept of "profiles".  A
   profile is a specification of which RSVPv1 objects are needed for a
   certain network scenario (see Section 2.2 above). In this way, the
   RSVPv1 messages will only carry the RSVPv1 objects that are required
   and specified by each profile.  The profile concept makes use of
   profile identifiers to separate different profiles used in RSVP aware
   nodes.


3.3.  Hierarchical Object Structure

   RSVPv1, even in its simplest form, still uses objects and features
   that are not needed in all routers (nodes) used in a network





Westberg, et al.          Expires October 2003                 [Page 15]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   scenario.  For example, in a network scenario with WLAN access, the
   QoS signaling protocol used between the access router and the
   untrusted mobile end host requires strong security procedures.
   However, the QoS signaling protocol used in the same network scenario
   between the same access router and another router will not require
   the same security procedures.  Another example is a network with
   semi-permanent trunk aggregation, where the edges of such a network
   have to provide aggregator/deaggregator features, e.g., maintenance
   of both per micro-flow and per aggregated flow reservation states,
   while the interior nodes require only simpler functionality, e.g.,
   maintenance of per aggregated flow reservation states.

   The RSVPv2 framework will endeavor to improve this by providing a
   hierarchical structure and positioning of the RSVPv2 NSLP objects
   within RSVPv2 messages for each networking scenario. Each profile
   used for a network scenario will have to specify how the objects are
   structured into the RSVPv2 NSLP message and how they should be
   processed by a router.  The objects that will be processed by all
   routers used in a network scenario will be placed as the first ones
   in the object sequence of the RSVPv2 NSLP message.  Objects that will
   be processed only in specific routers can be placed later in the
   sequence.


3.4.  Global and Local Objects

   NSLP RSVPv2's object space will consist of globally-understood
   objects ("global objects") and locally-understood objects ("local
   objects").  The purpose of this division is to provide additional
   flexibility in defining the objects carried by the RSVPv2 protocol
   such that only those objects that are applicable in a particular
   setting are used.

   The appropriate fora for defining these objects and how to manage the
   object space is obviously still a very open question.


3.5.  Local information exchange

   The signaling protocol MUST be able to exchange local information
   between NSIS Forwarders located within one single administrative
   domain. Local information might, for example, be IP addresses, severe
   congestion notification, notification of successful or erroneous
   processing of signaling messages.






Westberg, et al.          Expires October 2003                 [Page 16]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   In some cases, the NSIS signaling protocol MAY carry identification
   of the NSIS Forwarders located at the boundaries of a domain.
   However, the identification of edge should not be visible to the end
   host (NSIS Initiator) and only applies within one administrative
   domain.


3.6.  Object Re-use

   Obviously, whenever it is appropriate, RSVPv2 will re-use objects
   that are defined for RSVPv1.


3.7.  Reduced Focus on Multicast

   Given the complexity that multicast support introduces to QoS
   signalling and the fact that the vast majority of the traffic in
   typical IP networks is point-to-point unicast transport, RSVPv2 will
   be optimized to operate as a sender-initiated protocol for unicast
   data flows.

   This should not be interpreted to mean that multicast support is not
   important and should not be supported.  Given the increased
   modularity of RSVPv2 framework, it is entirely possible that
   appropriate objects will be defined in support of multicast.


3.8.  Primarily Sender-initiated Signalling

   Given a reduced focus on multicast, the "obvious" choice of sender-
   initiated signalling seems to be applicable to the NSLP RSVPv2.  The
   receiver-initiated reservations will undoubtedly still be needed in
   some network scenarios, so the RSVPv2 framework will need to handle
   such reservations as well. However, this feature will be optional.


3.9.  Low latency in setup

   The RSVPv2 framework SHOULD allow for low latency setup of
   reservations in scenarios, where reservations are in a short time
   scale (e.g. handover in mobile environments), or where human
   interaction is immediately concerned (e.g., voice communication setup
   delay).







Westberg, et al.          Expires October 2003                 [Page 17]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






3.10.  Highest possible network utilization

   There are networking environments that require high network
   utilization for various reasons, and the signaling protocol SHOULD do
   its best ability support high resource utilization while maintaining
   appropriate QoS.

   In networks where resources are very expensive (as is the case for
   many wireless networks), efficient network utilization is of critical
   financial importance.  On the other hand there are other parts of the
   network where high utilization is not required.


3.11.  Uni / bi-directional reservation

   Both unidirectional as well as bi-direction reservations SHOULD be
   possible. With bi-directional reservations we mean here reservations
   having the same end-points.  But the path in the two directions does
   not need to be the same.  The goal of a bi-directional reservation is
   mainly an optimization in terms of setup delay. There is no
   requirements on constrains such as use the same data path etc.


3.12.  End-to-end

   When used end-to-end (see also [Hanc03]), the RSVPv2 NSLP protocol is
   initiated by an end host and is terminated by another end host.  In
   this context, RSVPv2 NSLP can be applied as needed within all of the
   RSVPv2 NSLP domains between the end hosts. In the end-to-end path,
   RSVPv2 NSLP may be used both for intra-domain RSVPv2 NSLP signaling,
   as well as for inter-domain signaling.


3.13.  Edge-to-edge

   In this scenario (see also [Hanc03]) the RSVPv2 NSLP protocol is
   initiated by an edge node of a RSVPv2 NSLP domain and is terminated
   by another edge node of the same (or possibly different) RSVPv2 NSIS
   domain. RSVPv2 NSLP can be applied either within one single RSVPv2
   NSLP domain, which is denoted as edge-to-edge in a single domain, or
   within a concatenated number of RSVPv2 NSLP domains, which is denoted
   as edge-to-edge in a multi-domain. When an appropriate security trust
   relation exists between two or more concatenated RSVPv2 NSLP domains,
   these concatenated  RSVPv2 NSLP domains are considered, in terms of
   RSVPv2 NSLP, to be a single, larger RSVPv2 NSLP domain.





Westberg, et al.          Expires October 2003                 [Page 18]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






3.14.  End-to-edge

   In this scenario (see also [Hanc03]) the RSVPv2 NSLP protocol is
   either initiated by an end host and is terminated by an edge node or
   is initiated by an edge node and is terminated by an end host. In the
   path-coupled case, the edge node may be a proxy that is located on a
   boundary node of a RSVPv2 NSLP domain.


4.  Overview of the RSVPv2-NSLP Framework

   The RSVPv2 protocol can be considered as an NSLP that will use a
   subset of the transport layer functions provided by the NTLP protocol
   level (see for example, [WeKa03]).  The RSVPv2 protocol can be used
   for End-to-End, Edge-to-Edge, and End-to-Edge scenarios.  In the End-
   to-End scenario the both NSIS end nodes are functioning as NSIS
   Initiators (NI) and NSIS Responders (NR).  In the Edge-to-Edge
   scenario, both NSIS edge nodes are functioning as NI, NR and NSIS
   Forwarders (NF).  In the End-to-Edge scenario the NSIS end host is
   functioning as a NI or NR and the edge node is functioning as a NI,
   NR and NF.

   The NSLP can consist of one protocol level or it can be separated
   into more than one hierarchical levels.

   Figure 1 shows the NSIS protocol that consists of one NTLP level and
   one NSLP level.


      |-----|   |-------|   |-------|   |-------|   |-------|   |-----|
      |NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP|
      |     |<->|       |<->|       |<->|       |<->|       |<->|     |
      |     |   |       |   |       |   |       |   |       |   |     |
       -----     -------     -------     -------     -------     -----
      |NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP|
      |     |<->|       |<->|       |<->|       |<->|       |<->|     |
      |-----|   |-------|   |-------|   |-------|   |-------|   |-----|
        NI         NF          NF          NF          NF         NR


             Figure 1: One level used for RSVPv2 NSLP signaling


   The NSLP depicted in Figure 1 includes a set of upper-level signaling
   functions that are specific to particular signaling applications.





Westberg, et al.          Expires October 2003                 [Page 19]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Such functions could, for example, be end to end resource reservation
   signaling, security, policy, billing, etc.


   In Figure 2 the NSIS protocol is shown, which consists of one NTLP
   level and two NSLP hierarchical levels. However, the approach is
   quite general to more NSLP hierarchical levels: the important issue
   is the use of NSLP at more than one level at all.

   This type of hierarchical level separation can for example, be
   applied for intra-domain signaling in order to maximize the
   scalability in an NSIS intra-domain.

   The lowest hierarchical level in Figure 2 represents the NTLP level
   protocol. Note that in this the NF nodes are usually considered to be
   NTLP stateful nodes. This holds also for the NF nodes used at the
   boundary of a domain, i.e., the NF edge nodes.  However, as described
   in [WeKa03], the NF interior nodes of a domain can be considered to
   be NF stateful nodes (see Figure 1) or, when processing optimization
   is required, the NF interior nodes can be NF stateless nodes (see
   Figure 2).  The NF stateful nodes are NF NTLP aware nodes that
   maintain a NTLP state by using the NTLP soft state principle and are
   able to process and modify the application level information (NSLP)
   that is transported by the NTLP protocol.  The NF NTLP stateless
   nodes are NF NTLP aware nodes that do not maintain a NTLP state, but
   they are able to process and modify the application level information
   (NSLP) that is transported by the NSLP protocol.  The RSVPv2 NSLP
   framework depicted in Figure 2 is separated in two levels:

    * the intra-domain level (located above the NTLP level), that is
      composed by two protocol parts the Per Domain Reservation (PDR)
      protocol part and the Per Hop Reservation (PHR) level. Note that these
      two protocol parts are simialr to the two protocols (PDR and PHR) that
      are described in the Resource management in Diffserv (RMD)
      scheme [RMD-frame].

      In order to maximize the scalability in the RSVPv2 intra-domain
      the complexity imposed by the combination of the RSVPv2 NSLP and NTLP
      has to be moved as much as possible away from the interior nodes.
      Therefore, the RSVPv2 NTLP separates the problem of a
      complex reservation within a domain from a simple reservation
      within a node. This is accomplished by specifying two types
      of resource reservation protocol parts into the RSVPv2 NSLP
      intra-doamin.
      The first resource reservation protocol part type is denoted as Per





Westberg, et al.          Expires October 2003                 [Page 20]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






      Hop Reservation (PHR) that enables the signaling of the resources
      to be reserved per traffic class (e.g., Diffserv Per Hop Behavior
      (PHB) class) in each node within a domain. This protocol type is
      optimized to reduce the requirements placed on the functionality
      of the NF interior nodes of the domain.  For example, the nodes
      that implement this protocol type do not have per flow
      responsibilities. This protocol can be either reservation-based or
      measurement-based. In the reservation-based PHR, each node keeps
      only one reservation state per each supported traffic class. In the
      measurement-based PHR no reservation states are installed and the
      resource availability is checked by measuring traffic (user) data
      load. In the NF interior nodes there is no NTLP state
      and there is no PDR functionality. Note that these NF interior
      nodes are NTLP stateless nodes.


      The second protocol type is denoted as Per Domain Reservation
      (PDR) and is responsible for the resource reservation signaling
      on the NF edge nodes. The PDR is used by NF edge nodes
      (ingress and egress) but not by the interior nodes. This
      protocol introduces strict and complex requirements on the
      functionality implemented on the edge nodes. An example of such
      functionality is the mapping of the "global" traffic parameters
      signalled by the e2e service level (see Figure 2) to "local"
      parameters that are useful to the intra-domain scheme.
      Note that in the NF edge nodes (NF ingress and NF egress) a
      NTLP state is maintained and both PDR and PHR functionalities
      are active.

    * the e2e service level is located above the PDR/PHR level and
      includes a set of upper-level signaling functions that are specific
      to particular signaling applications. Such functions could, for
      example, be end to end resource reservation signaling, security,
      policy, billing, etc.

   The interface between the RSVPv2 NSLP and NTLP can be based on an API
   (Application Program Interface) and for the time being, is out of
   scope of this memo.


   As shown in Figure 2, the two NSLP hierarchical levels might be
   applied on different NSIS entities.

   This architecture for NSIS (e.g., RSVPv2) signaling can be provided
   by using:





Westberg, et al.          Expires October 2003                 [Page 21]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    *) a single end-to-end NSIS (e.g., RSVPv2) protocol that supports both
       NLSP hierarchical levels
    *) two independent NSIS (e.g., RSVPv2) protocols:  the e2e service
       level is supported by an end-to-end NSIS protocol, and the PDR/PHR
       level is supported by another edge-to-edge NSIS (e.g., RSVPv2)
       protocol.



   |------|   |-------|                           |-------|   |------|
   | e2e  |<--| e2e   |<------------------------->| e2e   |<->|  e2e |
   service|<->|service|                           |service|<->|service
   |      |   |-------|                           |-------|   |------|
   |      |   |       |                           |       |   |      |
   |      |   |-------|   |-------|   |-------|   |-------|   |      |
   |      |   |PDR/PHR|<->|  PHR  |<->|  PHR  |<->|PDR/PHR|   |      |NSLP
   |      |   |       |   |       |   |       |   |       |   |      | ^
   |      |   |-------|   |-------|   |-------|   |-------|   |      | |
   ---------------------------------------------------------------------
   |      |   |       |                           |       |   |      | |
   |------|   |-------|   |-------|   |-------|   |-------|   |------| V
   | level|<->| level |<->| level |<->| level |<->| level |<->|level |NTLP
   | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->|NTLP  |
   |st.ful|   |st.ful |   |st.less|   |st.less|   |st.full|   |st.ful|
   |------|   |-------|   |-------|   |-------|   |-------|   |------|
      NI         NF          NF          NF          NF         NR
               (edge)     (interior)  (interior)   (edge)

   NTLP st.ful  : NTLP stateful
   NTLP st.less : NTLP stateless

          Figure 2: Two levels used for the RSVPv2 NSLP

   The hierarchical level separation can be provided by supporting a
   hierarchical object structure. In other words, the NSIS protocol
   objects should be structured and positioned within the NSIS messages
   in a hierarchical way, i.e., first the "NTLP level" objects, then the
   "PDR/PHR" objects and finally the "e2e service" objects.


4.1.  RSVPv2 NSLP protocol features provided by the intra-domain level

   The RSVPv2 NSLP protocol functions provided by the intra-domain level
   are composed by the protocol functions provided by the PDR and PHR
   protocol parts (similar to [RMD-frame], [RODA], [RIMA]).





Westberg, et al.          Expires October 2003                 [Page 22]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






4.1.1.  PDR protocol part functions

   The RSVPv2 NSLP PHR and PDR protocol parts that implement the RSVPv2
   NSLP intra-domain level are listed below.

   A PDR protocol part implements all or a subset of the following
   functions:

    * Admission control and/or resource reservation signaling within
      a domain (i.e., on the edge nodes).

   * Mapping of external QoS request provided by the e2e service level
     to a traffic class identifier, e.g., Diffserv Code Point
     (DSCP).

   *  Modification of an already installed RSVPv2-NSLP reservation state.

    * Notification of the NF ingress node IP address to the NF egress
      node.

    * Notification of resource availability in all the nodes
      located in the communication path from the NF ingress to the
      NF egress nodes.

    * Severe congestion handling.  Due to a route change or a
      link failure, a severe congestion situation may occur.
      The NF egress node is notified by PHR when such a severe
      congestion situation occurs.  Using PDR, the egress node
      notifies the NF ingress node about this severe congestion
      situation. The NF ingress node resolves this situation by using
      a predefined policy, e.g., refusing new incoming flows and
      terminating a portion of the affected flows.

    * Uni / bi-directional reservation. Both unidirectional as well
      as bi-direction reservations SHOULD be possible

   * Notification that lost signalling messages (containing PHR and PDR
     information) occurred in the communication path from the ingress
     to the egress nodes.


4.1.2.  PHR protocol part functions

   A RSVPv2-NSLP PHR protocol part implements all or a subset of the
   following functions:





Westberg, et al.          Expires October 2003                 [Page 23]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    * Admission control and/or resource reservation signaling within a
      node.

    * Management of one reservation state (i.e., PHR state) per traffic
      class by using a combination of the reservation soft state and
      explicit release signaling principles (see e.g., [RODA]). Note that
      the PHR state is maintained by using the NTLP soft state principle.

      Each NF node in the communication path from an NF ingress node to an
      NF egress node keeps only one reservation state per traffic class.

      The reservation signaling is done in terms of resource units,
      which may be based on a single parameter, such as bandwidth,
      or on more sophisticated parameters. These resources are
      requested dynamically per traffic class (e.g., per DSCP) and
      reserved on demand on all nodes in the communication path from an
      NF ingress node to an NF egress node. This concept is denoted as
      reservation based "PHR".


    * Measurement of the user traffic load (see e.g., [RIMA]). This
      PHR function is used to check the availability of resources before
      flows are admitted and without installing any reservation state.
      That is, the resource management function that is used is actually
      a Measurement Based Admission Control (MBAC) algorithm, which
      performs measurements on the traffic (user) data load. The main
      advantage of this PHR group is that the PHR functionality
      that is executed at the edge and interior nodes will not
      have to maintain any reservation states. This concept is denoted
      as measurement based "PHR".


    * Stores a pre-configured threshold value on maximal allowable
      traffic load (or resource units) per traffic class, e.g., PHB.
      When the resource management function (RMF) that is used
      in combination with this PHR protocol function maintains a
      reservation state per traffic class it also has to maintain a
      threshold for each traffic class (e.g., PHB) that specifies the
      maximum number of reservable resource units. This threshold could,
      for example, be statically configured.
      When the resource management function (RMF) that is used
      in combination with this PHR protocol function is an MBAC algorithm
      it also has to maintain one state per traffic class that stores the
      measured user traffic load associated to the traffic class, e.g., PHB
      and another state per traffic class, e.g., PHB that stores the





Westberg, et al.          Expires October 2003                 [Page 24]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






      maximum allowable traffic load per traffic class, e.g., PHB.


    * Severe congestion notification. This situation occurs as
      a result of route changes or a link failure. The PHR
      has to notify the NF edges about the occurrence of this
      situation.

      Once detected the severe congestion should be signalled to the
      NF(edges).
      As previously mentioned, the NF(egress) node will first be notified,
      after which the NF(egress) will notify the NF(ingress) node using the
      NSLP PDR functionality.

      Below is a list of several notification methods that can be used:

       * Greedy marking: all user data packets which pass through
         a severe congested interior node and are associated with a
         certain traffic class, e.g., DSCP, will be remarked into a
         another traffic class, e.g., a domain specific (DSCP)

       * Proportional marking: this method is similar to the previous
         method, with the difference that the number of the remarked
         packets is proportional to the detected overload

       * PHR message marking: only PHR objects that
         pass through a severely congested interior node will be
         marked.  The marking is done by setting a special flag in
         the "PHR" object, i.e., "S" (see [RODA]).

   The last method can only be applied on the reservation-based "PHR"
   concept, while the other two can be applied on both "PHR" concept
   types. A comparison between different severe congestion solutions is
   given in [CsTa02].  Note that in the RMD NSLP the PHR and PDR
   protocol parts have to be generated and discarded at the edge nodes
   (ingress and egress nodes) and not at the end hosts.



4.2.  RSVPv2 NSLP protocol features provided by the e2e service level

   The e2e service level protocol features that are used by this NSLP
   should satisfy all or a subset of the application signaling
   requirements provided in [Bru03].  The detailed description of these
   features will be included in the next updated versions of this draft.





Westberg, et al.          Expires October 2003                 [Page 25]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






5.  RSVPv2 NSLP specification

   RSVPv2 NSLP is considered in this draft to be primarily optimised for
   unicast and sender initiated signaling. This section provides a first
   step in the RSVPv2 NSLP specification.


5.1.  RSVPv2 NSLP Object Classes structure

   As described in [WeKa03] the NTLP message format consists of a common
   header, followed by a body consisting of a number of variable-length,
   typed transport layer "objects". The application layer (NSLP)
   "objects" are placed always after the transport layer "objects". Note
   that the application layer (NSLP) "objects" are opaque and
   transparent to NTLP. The NTLP message format is depicted in Figure 3.

                      0             1              2             3
               +-------------+-------------+-------------+-------------+
               |                                                       |
               +                   Common Header                       +
               |                                                       |
               +-------------+-------------+-------------+-------------+
               |                                                       |
               //       (Transport layer objects content)              //
               |                                                       |
               +-------------+-------------+-------------+-------------+
               |                                                       |
               //   Application layer (RSVPv2 NSLP) objects content)   //
               |                                                       |
               +-------------+-------------+-------------+-------------+

                        Figure 3: NTLP message format


   The Application layer (RSVPv2 NSLP) depicted in Figure 3 contains
   RSVPv2 NSLP messages. The RSVPv2 NSLP messages and their meaning is
   introduced in Table 1. Furthermore, the same table identifies the
   NTLP message that will transport a NSLP message.












Westberg, et al.          Expires October 2003                 [Page 26]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Table 1: NSLP messages

   Meaning of the NSLP message  NSLP Message Type  NTLP Message Type
   __________________________      _____________   _________________


     Initiation                    NslpPathInit     PATH
     Initiation                    NslpResvInit     RESV
     Modification                  NslpPathMod      PATH
     Modification                  NslpResvMod      RESV
     Refresh                       NslpPathRef      PATH
     Refresh                       NslpResvRef      RESV
     Path Tear down                NslpPathTear     PATHTEAR
     Resv Tear down                NslpResvTear     RESVTEAR
     Path Error report             NslpPathErr      PATHERROR
     Resv Error report             NslpResvErr      RESVERROR
     Resv Confirm                  NslpResvConfirm  RESVCONFIRM


   In order to have a flexible and modular RSVPv2 NSLP object class
   structure, we propose a grouping of signalling information into
   RSVPv2 NSLP object classes, called RSVPv2 NSLP Object_Classes.  These
   will contain objects that are defined globally and/or locally.  A
   locally defined object will allow signalling of information relevant
   to nodes belonging to a certain domain, while the globally defined
   objects will be used anywhere on the Internet.  The globally defined
   objects are denoted as "e2e service objects" and the locally defined
   objects are denoted as ""PDR/PHR" objects.

   In the RSVPv2 NSLP structure the following RSVPv2 NSLP Object_Classes
   are defined:


    * Service_Class

      This object class carries the information related to the
      service desired from the network, i.e. QoS.  This class
      includes all information related to the requested/expected
      network service.  The resource reservation is related
      to the QoS request as well as to the response on this
      QoS request.  This object class is flexible in order to
      support different kinds of QoS requests for different kinds
      of networking scenarios such as a end-to-edge (proxy) scenario,
      bi-directional reservations, receiver-initiated, etc.






Westberg, et al.          Expires October 2003                 [Page 27]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    * Session_ID_Class

      This object class is common for the NTLP and NSLP. In [Weka03]
      this object class is denoted as Session object.
      This class includes information related to the
      identification of NTLP states. This object will contain
      a session identifier.

      The session identifier has to identify a NTLP state
      and has to remain unchanged for the complete duration of a
      data flow.  Moreover, the Session_ID_Class identifier has to
      be associated with the flow ID information included in the
      Flow_Specification_Class object.  In other words, for the
      duration of a data flow, the session identifier
      remains the same while the flow ID information associated
      with the same data flow might change.  For example, in a
      mobile IP scenario, during handover the IP address of a
      mobile node might change, causing a change in the flow ID
      of an ongoing data flow. However, the session
      identifier associated with that data flow should not change.

    * Flow_Specification_Class

      This object class specifies the relation of the addressing
      (IP address/mask/port) to the reservation and if/how the
      reservation is shared between many addresses.  In general,
      Flow_Specification contains information that identifies
      a particular data flow for which the specific service
      is requested from the network.  For example, a flow
      ID consisting of a combination of source IP address,
      destination IP address, Source port, Destination port,
      Protocol number will be typical information belonging to
      the Flow_Specification_Class. This class should also contain
      an NSLP identifier, which identifies the NSLP type.


    * Security_class

      This object class includes information related to the
      protection, authorization and authentication of the
      information in the message.  This object class is optional.

    * Error_message_class

      This class includes information related to the errors that





Westberg, et al.          Expires October 2003                 [Page 28]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






      occur during reservation state processing. This object class
      can be considered as common for the NTLP and NSLP. In [Weka03]
      this object class is denoted as Error_Spec object.




5.1.1.  RSVPv2 NSLP Message Structure

   The exact object structure and the object sequence will have to be
   defined for each network scenario by a pre-defined "profile" (see
   Section 3.2).  A profile can be either standardized or it could be an
   agreement between two or more participants.

   Based on the above defined RSVPv2 object-class structure the format
   of the RSVPv2 NSLP messages may be as follows:



   <NslpPathInit> | <NslpPathMod> | <NslpResvInit> | <NslpResvMod> |
   <NslpPathTear> | <NslpResvTear> | <NslpResvConfirm> ::=
                                       <Service_Class>
                                       <Session_ID_Class>
                                       <Flow_Specification_Class>
                                       [<Security_class>]


    <NslpPathErr> | <NslpResvErr> ::=
                               <Service_Class>
                               <Session_ID_Class>
                               <Flow_Specification_Class>
                               [<Security_class>]
                               <Error_message_class>




5.2.  RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes

   This section presents a generic method of mapping globally and
   locally defined RSVPv2 NSLP objects into RSVPv2 NSLP classes.  Based
   on the definitions of the RSVPv2 NSLP object classes, an RSVPv2 NSLP
   Object_Class might contain globally and locally defined objects.
   Below is shown a possible way of mapping globally and locally defined
   objects into the RSVPv2 NSLP Object_Classes.  The locally defined





Westberg, et al.          Expires October 2003                 [Page 29]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   objects are the "PHR" (Per Hop Reservation) and "PDR" (Per Domain
   Reservation). These objects are used for intra-domain signaling and
   are described in more detail in the Appendix.

    Service_Class:
               [<PHR>]
               [<PDR>]
               <any globally defined e2e service objects>

    Flow_Specification_Class:
      <any globally defined e2e service Flow_Specification objects>

    Session_ID_Class:
      <any globally defined e2e service session ID objects>

    Security_Class:
      <any globally defined e2e service Security objects>

    Error_Message_Class:
      <any globally defined e2e service Error_Message objects>

   where:


     [] is optional for unicast and multicast support and
        sender-initiated and receiver-initiated approach



5.2.1.  Example of mapping of RSVPv1 [RFC2205] objects in
       RSVPv2 object_classes"

   This section gives an example of mapping the RSVPv1 objects into the
   RSVPv2 object_classes when RSVPv1 is optimized for unicast and sender
   initiated signaling.

   If RSVPv1 is to be optimized for unicast and sender initiated
   signaling certain changes in the mandatory usage of RSVPv1 objects
   have to be provided.  Based on the RSVPv2 object-class structure an
   example of a possible mapping of current RSVPv1 objects in RSVPv2
   NSLP object structure is given.


   The mandatory objects that will be needed in an sender-initiated NSLP
   RSVPv2 optimized for unicast are:





Westberg, et al.          Expires October 2003                 [Page 30]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    * SESSION

      It contains the IP destination address (DestAddress), the
      IP protocol id, and some form of generalized destination
      port, to define a specific session for the other objects
      that follow.  This object contains information that is used
      to define the flow ID.

    * SENDER_TSPEC

      Defines the traffic characteristics of a sender's data
      flow. Required in a Path message. This object is used to
      specify the QoS service required by the sender.

    * SENDER_TEMPLATE

      Contains a sender IP address and perhaps some additional
      de-multiplexing information to identify a sender. Required
      in a Path message.  This object contains information that
      is used to define the flow ID.

    * TIME_VALUES

      Contains the value for the refresh period R used by the
      creator of the message. Required in every Path and Resv
      message.

    * ERROR_SPEC

      Specifies an error in a PathErr, ResvErr, or a confirmation
      in a ResvConf message.

    * POLICY_DATA

      Carries information that will allow a local policy module to
      decide whether an associated reservation is administratively
      permitted.  May appear in Path, Resv, PathErr, or ResvErr
      message. The use of POLICY_DATA objects is not fully
      specified at this time; a future document will fill this gap.

    * INTEGRITY

      Carries cryptographic data to authenticate the originating
      node and to verify the contents of this RSVPv1 message. The
      use of the INTEGRITY object is described in [RFC2747].





Westberg, et al.          Expires October 2003                 [Page 31]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Based on the definitions of the RSVPv2 object classes, some of the
   RSVPv1 objects (see [RFC2205]) can be re-used in a RSVPv2 NSLP
   object-class structure.  During the RSVPv2 NSLP design phase the
   RSVPv1 objects may be changed or removed completely and also some
   other objects may be defined as well.  The goal is to reuse as much
   as possible of RSVPv1 objects.  Based on the description of RSVPv2
   NSLP object classes and the current RSVPv1 objects the mapping of
   RSVPv1 objects into the RSVPv2 NSLP object-class structure is rather
   simple. This mapping is given below and it is done for all RSVPv1
   objects.  Note that the Service_Class contains the PHR and PDR
   objects that are locally defined objects and are used for intra-
   domain signaling.

    Service_Class:
               [<PHR>]
               [<PDR>]
               <SENDER_TSPEC>
               {<ADSPEC>}
               [FLOWSPEC]
               {<RESV_CONFIRM>}
               [<POLICY_DATA>]

    Flow_Specification_Class:
               <SESSION>
               <SENDER_TEMPLATE>
               <TIME_VALUES>
               <NSLP_ID>
               {<FILTER_SPEC>}
               {<STYLE>}
               {<SCOPE>}

    Session_ID_Class:
               <SESSION>
               <NSLP_ID>

    Security_Class:
               [<INTEGRITY>]

    Error_Message_Class:
               <ERROR_SPEC>

   where:

     {} is mandatory only for multicast support and
        receiver-initiated approach





Westberg, et al.          Expires October 2003                 [Page 32]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






     [] is optional for unicast and multicast support and
        sender-initiated and receiver-initiated approach
     <NSLP_ID> is a new object that identifies the ID of the NSLP
     protocol level.


5.2.2.  PDR/PHR objects

   The PHR and PDR objects are locally defined objects that are used for
   intra-domain signaling.  The information contained in these objects
   is similar to the information contained in the PHR and PDR messages
   described in [RMD-frame] and [RODA].

   The PDR and PHR information is encapsulated into two different NSLP
   RSVPv2 object. The Appendix provides an example of PHR and PDR object
   specifications


5.3.  RSVPv2-NSLP functionality on nodes used for inter-domain
signaling

   This section describes the RSVPV2-NSLP functionality on the different
   nodes used for inter-domain signaling. These nodes are NI (NSIS
   Initiator), NF (NSIS Forwarder) and NR (NSIS Responder).  Note that
   this functionality is used in the examples provided in Section 6.


5.3.1.  NI (NSIS Initiator) functionality

   The NI (NSIS Initiator) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.


5.3.1.1.  Unidirectional functionality

   The "e2e service" functionality of the NI(sender), after creating an
   NSLP reservation state, it generates an NslpPathInit message (see
   Section 5.1.1).  The flow ID, the ID of the NSLP protocol and the
   time values can be included in the Flow_Specificaton_Class (e.g.,
   <Session>, <Sender_template>, <Time_Values>, <NSLP_ID> objects). The
   session ID and the ID of the NSLP protocol can be included in the
   Session_ID_Class (e.g.,<Session> and <NSLP_ID> objects).  The
   information that is related tothe service desired from the network,
   i.e., requested QoS, can be included into the Service_Class object
   class (e.g., <Sender_Tspec> and <Flowspec> objects). Moreover, the





Westberg, et al.          Expires October 2003                 [Page 33]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Service_Class object specifies the directionality of the reservation,
   i.e., in this case uni-directional.  The NslpPathInit is encapsulated
   into a NTLP PATH message (see [RFC2205]) and sent towards the
   NR(receiver).

   The NI(sender) can receive a NslpResvInit message that is
   encapsulated into a RESV message. This message is associated with a
   NslpPathInit message that is sent earlier and that is used for a uni-
   directional reservation.  The "e2e service" functionality of the
   NslpResvInit message specifies that the reservation initiated by the
   NslpPathInit message was successful.  In this case the NI(sender),
   after processing the NslpResvInit message, it can start transmitting
   traffic user data.  The "e2e service" functionality of the NI(sender)
   can receive a NslpPathErr message that is encapsulated into a
   PATHERROR message, that is associated with a NslpPathInit message
   sent earlier, and which is used for a uni-directional reservation.
   The NslpPathErr message can specify that the reservation initiated by
   the NslpPathInit message was unsuccessful.  In this case the
   NI(sender), after processing the NslpPathError message, it has to
   delete the reservation state.

   The RSVPv2-NSLP refresh procedure is a pure NTLP refresh procedure,
   meaning that a refresh NTLP PATH message that is periodically sent
   through all the NTLP stateful nodes located between NI (sender) and
   NR (receiver).  If a NTLP state in a NTLP stateful is not refreshed
   on time then the NTLP functionality at this node informs the
   RSVPv2-NSLP state that the refresh procedure is unsuccessful.  Note
   that the refresh NTLP PATH message may optionally carry a NslpPathRef
   message.  In this case the information carried by the NslpPathRef
   message is similar to the information carried by the NslpPathInit
   message, (see Section 5.1.1).

   The NI(sender) can receive a NslpResvRef message that is encapsulated
   into a RESV message. This message is associated with a NslpPathRef
   message that is sent earlier and that is used for a uni-directional
   reservation.  The "e2e service" functionality of the NslpResvRef
   message specifies that the reservation initiated by the NslpPathRef
   message was successful.


   The RSVPv2-NSLP "e2e service" functionality of the NI(sender) can
   inform the NTLP functionality of the same node to start a tear down
   procedure for the specific flow. A NTLP PATHTEAR message is created
   that is sent towards  the NR (receiver). This message will tear down
   all the NTLP and RSVPv2-NSLP states that are associated with the





Westberg, et al.          Expires October 2003                 [Page 34]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Session_ID_Class of all NTLP stateful nodes that process the NTLP
   PATHTEAR message.  Note that the NTLP PATHTEAR message may optionally
   carry a NSLPPathTear message. In this case the information carried by
   the NslpPathTear message is similar to the information carried by the
   NslpPathInit message, (see Section 5.1.1).

   The RSVPv2-NSLp protocol supports the modification of a reservation
   procedure. The "e2e service" functionality includes the request for
   modification of the reservation into a NslpPathMod message. This NSLP
   message is encapsulated into a NTLP PATH message and it is sent hop-
   by-hop towards the NR(receiver).  The flow ID of the flow that has to
   be modified is included in the Flow_Specificaton_Class. The
   information that has to be modified is included into the
   Service_Class object class. (e.g., <Sender_Tspec> and <Flowspec>
   objects).

   The NI(sender) receives a NslpResvMod message that is encapsulated
   into a NTLP RESV message (see Section 5.1.1). This message is
   associated with a NslpPathMod message that is sent earlier and that
   is used for a uni-directional reservation.  The "e2e service"
   functionality of the NslpResvMod message specifies that the
   modification of the reservation requested by the NslpPathMod message
   was successful.  In this case the NI(sender), after processing the
   NslpResvMod message, it can adjust the transmitted traffic user data
   to the modified reservation.

   The "e2e service" functionality of the NI(sender) can receive a
   NslpPathErr message that is associated with a NslpPathMod message
   sent earlier.  The NslpPathErr message can specify that the
   modification procedure initiated by the NslpPathMod message was not
   successful.  In this case the "e2e functionality" of the NI (sender)
   will identify the modification type of the NslpPathErr message.  If
   the modification procedure required a higher amount of reservation,
   then the reservation asociated to the modified flow will have to be
   reset to the reservation or to the amount (or type) of reservation
   that was stored before the modification procedure started.



5.3.1.2.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NI(sender) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is





Westberg, et al.          Expires October 2003                 [Page 35]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   described in Section 5.3.1.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NI(sender) does not receive the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)


5.3.2.  NF (NSIS Forwarder) functionality

   The NF (NSIS Forwarder) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.


5.3.2.1.  Unidirectional functionality

   The NslpPathInit is encapsulated into a NTLP PATH message (see
   [RFC2205]).  The NTLP PATH message is processed by all NTLP stateful
   NF nodes that is passing through, up to the NR (receiver).  Each node
   that processes the NTLP PATH message will create a NTLP state and
   will activate the RSVPv2-NSLP "e2e service" functionality by using
   the transported NslpPathInit information and it will create an
   RSVPv2-NSLP reservation state. This RSVPv2-NSLP reservation state
   will be associated to a flow ID. Note that the NTLP states have to
   store back-ward routing information, which are used by NTLP messages
   that are transported hop-by-hop in the backward direction towards the
   NI(sender).  The NslpResvInit which is encapsulated into a RESV
   message will only be processed by the RSVPv2-NSLP "e2e service"
   functionality at each NF hop that is passing by and that is
   supporting the "e2e service" functionality.

   The used RSVPv2-NSLP refresh procedure is a pure NTLP refresh





Westberg, et al.          Expires October 2003                 [Page 36]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   procedure, meaning that a refresh NTLP PATH message is periodically
   sent through all the NTLP stateful nodes located between NI (sender)
   and NR (receiver).  If a NTLP state in a NTLP stateful is not
   refreshed on time then the NTLP functionality at this node informs
   the RSVPv2-NSLP state that the refresh procedure is unsuccessful.
   Note that the refresh NTLP PATH message may optionally carry a
   NSLPPathRef message.


   The NTLP RESV message used during the refresh procedure is processed
   at each NF hop towards the NI (sender). This message will be used to
   report information related to how the NTLP PATH message has been
   processed along the path.  Note that the refresh NTLP RESV message
   may optionally carry a NSLPResvRef message.  The NslpPathRef and
   NslpResvRef messages are processed by the RSVPv2-NSLP "e2e service"
   functionality at each NF hop that are passing by and that is
   supporting the "e2e service" functionality.

   The NF node processes a NTLP PATHTEAR message that is tearing down
   all the NTLP and RSVPv2-NSLP states that are associated with the
   Session_ID_Class of all NTLP stateful nodes that process the NTLP
   PATHTEAR message.  Note that the NTLP PATHTEAR message may optionally
   carry a NslpPathTear message. The NslpPathTear message will be
   processed by the "e2e service" functionality.

   When one of the NF nodes is not able to satisfy a NslpPathInit
   request the RSVPv2-NSLP "e2e service" functionality of this
   particular NF(router) will generate an NslpPathErr to report to
   NI(sender) that the NslpPathInit request could not be satisfied.
   This NslpPathErr message will be encapsulated into a NTLP PATHERROR
   message and it will be sent hop-by-hop towards the NI(sender). This
   message will be processed hop-by-hop by the RSVPv2-NSLP  "e2e
   service" functionality.  Each NF (router) that processes this
   NslpPathError message will have to to delete its associated
   reservation state.  Note that similar to [RFC2205] the NslpPathErr
   could be created due to other errors in the router. The type of this
   error must be included into the Error_Message_Class (see Section
   5.1.1). Note that the reservation state is only deleted when the
   NSlpPathErr message is associated to a NslpPathInit message.

   When one of the NF nodes is not able to satisfy a NslpPathMod request
   the RSVPv2-NSLP "e2e service" functionality of this particular
   NF(router) will generate an NslpPathErr to report to NI(sender) that
   the NslpPathMod request could not be satisfied. This message will be
   encapsulated into a NTLP PATHERROR message and it will be sent





Westberg, et al.          Expires October 2003                 [Page 37]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   towards the NI(sender). The NslpPathMod message will not be forwarded
   further. The "e2e functionality" of the NF intermediate nodes will
   identify the modification type of the NslpPathErr message. If the
   modification procedure required a higher amount of reservation, then
   the nodes that modified the reservation will have to reset the
   reservation to the amount (or type) of reservation that was stored
   before the modification procedure started.

   Each NTLP stateful node can process a NslpPathMod message that is
   carried by a modification NTLP PATH message.  The RSVPv2-NSLP
   functionality identifies the flow that has to be modified by using
   its flow ID information carried by the NslpPathMod message.  By using
   the information contained in the Service_Class, the RSVPv2-NSLP
   functionality is modifying the service information stored into the
   RSVPv2-NSLP state.  The "e2e service" functionality of each NF node
   has to process a NslpResvMod message which is used to report
   information related to how the NslpPathMod message has been processed
   along the path.  This NslpResvMod message is encapsulated into a NTLP
   RESV message and sent towards the NI(sender).


5.3.2.2.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NF(router) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is
   described in Section 5.3.2.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NF(router) does not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)





Westberg, et al.          Expires October 2003                 [Page 38]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






       towards the NI(sender)


5.3.3.  NR (NSIS Responder) functionality

   The NR (NSIS Responder) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.

   The NR(receiver) can receive a NslpPathInit message that is
   encapsulated into a NTLP PATH message.  The NR (receiver) processes
   the NTLP PATH message, creates a NTLP state and activates the
   RSVPv2-NSLP "e2e service" functionality by using the transported
   NslpPathInit information and it will create an RSVPv2-NSLP
   reservation state. This RSVPv2-NSLP reservation state will be
   associated to a flow ID. Note that the NTLP states have to store
   back-ward routing information. The "e2e service" functionality
   creates a NslpResvInit message that is used to report information
   related to how the NslpPathInit has been processed along the path.
   This NslpResvInit will be encapsulated into a RESV message and it
   will be sent on a hop-by-hop basis in the backward direction towards
   the NI(sender).

   The RSVPv2-NSLP refresh procedure supported by the NR(receiver) is a
   pure NTLP refresh procedure, meaning that a refresh NTLP PATH message
   is periodically sent through all the NTLP stateful nodes located
   between NI (sender) and NR (receiver).  If a NTLP state in a NTLP
   stateful is not refreshed on time then the NTLP functionality at this
   node informs the RSVPv2-NSLP state that the refresh procedure is
   unsuccesful.  Note that the refresh NTLP PATH message may optionally
   carry a NSLPPathRef message.  The NR (receiver) that receives a
   refresh NTLP PATH message will create a refresh NTLP RESV message
   that will be sent towards the NI (sender). This message will be used
   to report information related to how the NTLP PATH message has been
   processed along the path.  Note that the refresh NTLP RESV message
   may optionally carry a NSLPResvRef message.

   A NTLP PATHTEAR message can be received by the NR (receiver). This
   message will tear down all the NTLP and RSVPv2-NSLP states that are
   associated with the Session_ID_Class of the NR (receiver) that
   process the NTLP PATHTEAR message.  Note that the NTLP PATHTEAR
   message may optionally carry a NSLPPathTear message.

   When the NR(receiver) is not able to satisfy a NslpPathInit request
   the RSVPv2-NSLP "e2e service" functionality of the NR(receiver) will
   generate an NslpPathErr to report to NI(sender) that the NslpPathInit





Westberg, et al.          Expires October 2003                 [Page 39]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   request could not be satisfied.  This NslpPathErr message will be
   encapsulated into a NTLP PATHERROR message and it will be sent hop-
   by-hop towards the NI(sender).  Note that similar to [RFC2205] the
   NslpPathErr could be created due to other errors in the router. The
   type of this error must be included into the Error_Message_Class (see
   Section 5.1.1). When the NSlpPathErr message is associated to a
   NslpPathInit message then its associated reservation state will be
   deleted.

   The NR (receiver) can receive the NslpPathMod message which is
   carried by the modification NTLP PATH message.  The RSVPv2-NSLP
   functionality identifies the flow that has to be modified by using
   its flow ID information carried by the NslpPathMod message.  By using
   the information contained in the Service_Class, the RSVPv2-NSLP
   functionality is modifying the service information stored into the
   RSVPv2-NSLP state.  Subsequently the RSVPv2-NSLP "e2e service"
   functionality at the NR(receiver) creates a NslpResvMod message that
   will be used to report information related to how the NslpPathMod
   message has been processed along the path.  This NslpResvMod message
   will be encapsulated into a NTLP RESV message and sent hop-by-hop
   towards the NI(sender).

   When the NR(receiver) is not able to satisfy a NslpPathMod request
   the RSVPv2-NSLP "e2e service" functionality of this node will
   generate an NslpPathErr to report to NI(sender) that the NslpPathMod
   request could not be satisfied.  This message will be encapsulated
   into a NTLP PATHERROR message and it will be sent towards the
   NI(sender).  In this case the "e2e functionality" of the NR
   (receiver) will identify the modification type of the NslpPathErr
   message.  If the modification procedure required a higher amount of
   reservation, then the reservation asociated to the modified flow will
   have to be reseted to the reservation or to the amount (or type) of
   reservation that was stored before the modification procedure
   started.


5.3.3.1.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NR(receiver) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is
   described in Section 5.3.3.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite





Westberg, et al.          Expires October 2003                 [Page 40]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   directions are as follows:


     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NR(receiver) does not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)




5.4.  RSVPv2-NSLP functionality on nodes used for intra-domain
signaling

   This section describes the RSVPV2 functionality on the different
   nodes used for intra-domain signaling. These nodes are NF (ingress),
   NF (interior) and NF (egress).  These intra-domain signaling
   procedures are using the NSIS protocol which consists of one NTLP
   level and two NSLP hierarchical levels (see Figure 2).

   Intra-domain signaling is where the RSVPv2-NSLP signaling messages
   are originated, processed and terminated within the same domain.
   RSVPv2-NSLP is considered in this section to be optimized for unicast
   and sender-initiated protocol.

   The Intra-domain signaling procedures are mainly using RSVPv2-NSLP
   PHR/PDR objects, (see Section 5.2.2) that are originated, processed
   and terminated within the same domain.  Note that this functionality
   is used in the examples provided in Section 7.


5.4.1.  NI (NSIS Initiator) functionality

   The NI (NSIS Initiator) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.





Westberg, et al.          Expires October 2003                 [Page 41]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






5.4.1.1.  Unidirectional functionality

   The unidirectional functionality supported by the NI(sender) used in
   this type of scenarios is identical to the functionality supported by
   the NI(sender) used in the inter-domain signaling scenario (see
   Section 5.3.1.1).


5.4.1.2.  Bidirectional functionality

   The bi-directional functionality supported by the NI(sender) used in
   this type of scenarios is identical to the functionality supported by
   the NI(sender) used in the inter-domain signaling scenario (see
   Section 5.3.1.2).


5.4.2.  Functionality of NF (NSIS Forwarder) located outside NSIS
intra-domain

   The functionality of the NF (NSIS Forwarder) located outside the NSIS
   intra-domain can be characterized as unidirectional and as bi-
   directional reservation functionality.


5.4.2.1.  Unidirectional functionality

   The unidirectional functionality supported by the NF located outside
   the NSIS intra-domain and used in this type of scenarios is identical
   to the functionality supported by the NF(router) used in the inter-
   domain signaling scenario (see Section 5.3.2.1).


5.4.2.2.  Bidirectional functionality

   The bi-directional functionality supported by the NF located outside
   the NSIS intra-domain and used in this type of scenarios is identical
   to the functionality supported by the NF(router) used in the inter-
   domain signaling scenario (see Section 5.3.2.2).


5.4.3.  NF (ingress) functionality

   The NF (ingress) functionality can be characterized as unidirectional
   and bi-directional reservation functionality.






Westberg, et al.          Expires October 2003                 [Page 42]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






5.4.3.1.  Unidirectional functionality

   When an NslpPathInit arrives at the ingress node of a domain, i.e.,
   NF(ingress), the RSVPv2-NSLP "e2e service" functionality creates a
   RSVPv2-NSLP Path reservation state.  Subsequently, the RSVPv2-NSLP
   "PDR" protocol functionality is activated (see Figure 2) classifying
   the flow (i.e., Flow_Specification_Class) that is associated with the
   NslpPathInit message into an appropriate traffic class, e.g.,
   Diffserv class.  The RSVPv2-NSLP PDR functionality uses the
   RSVPv2-NSLP path state created by the NslpPathInit message and it
   introduces additional information that can be used to associate the
   PHR and PDR objects with the flow that created the RSVPv2-NSLP Path
   reservation state in the NF(ingress) node.  The RSVPv2-NSLP PDR
   functionality is subsequently using the Service_Class (e.g.,
   <SENDER_Tspec> object) and translates the requested bandwidth
   parameter into a number of resource units.  If the QoS request is
   satisfied locally, then the ingress node will generate a reservation
   request PHR object denoted as "PHR_Resource_Request" and a
   reservation request PDR object denoted as "PDR_Reservation_Request",
   (see Section 5.2.2).  The PDR object MAY contain information such as
   the IP address of the NF(ingress) node and the per-flow specification
   ID.  These PHR and PDR objects are locally defined objects which are
   included into the Service_Class object class carried by the
   NslpPathInit message.  The NslpPathInit message is encapsulated into
   a NTLP PATH message and is sent towards the NR(receiver).  Note that
   the "PDR/PHR" functionality of the NF(ingress) node should
   temporarily store the TTL value, included in the IP header of any
   message, in the PDR state associated to the NTLP PATH message.  The
   variable that temporarily stores the TTL value is denoted in this
   text as PDR_TTL_I.

   The NF(ingress) can receive a NslpResvInit message that is
   encapsulated into a RESV message. This message is associated with a
   NslpPathInit message that is sent earlier and that is used for a uni-
   directional reservation.  The "e2e service" functionality by
   extracting the Service_Class object from the NslpResvInit message, it
   can deduce that the reservation was successful. Moreover, the
   RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is extracting
   the "PDR_Reservation_Report" PDR object from the Service_Class object
   class of the NslpResvInit message.  If the initial reservation
   request was successful the RSVP-NSLP functionality encapsulates the
   NslpResvInit message into the NTLP RESV message and it is sent
   towards the NI(sender).

   The intra-domain RSVPv2-NSLP refresh procedure is a combination of a





Westberg, et al.          Expires October 2003                 [Page 43]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NTLP and a RSVPv2-NSLP "PHR/PDR" procedure.  When a refresh NTLP PATH
   message is received by a NF(ingress) node the NTLP functionality will
   activate the RSVPv2-NSLP "PHR/PDR" functionality that is carried by
   the NslpPathRef message.  By using the Flow_Specification_Class
   object class the "PDR" functionality can identify the RSVPv2-NSLP
   path state.  The RSVPv2-NSLP "PDR" functionality of the NF(ingress)
   node will generate a refresh request PHR object denoted as
   "PHR_Refresh_Update" and a refresh request PDR object denoted as
   "PDR_Refresh_Request", (see Section 5.2.2).  The PDR object MAY
   contain information such as the IP address of the NF(ingress) node
   and the per-flow specification ID.  These PHR and PDR objects are
   locally defined objects which are included into the Service_Class
   object class carried by the NslpPathRef message.

   The NF(ingress) can receive a NslpResvRef message that is
   encapsulated into a RESV message. This message is associated with a
   NslpPathRef message that is sent earlier and that is used for a uni-
   directional reservation.  The "e2e service" functionality by
   extracting the Service_Class object from the NslpResvRef message, it
   can deduce that the refresh procedure was successful. Moreover, the
   RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is extracting
   the "PDR_Refresh_Report" PDR object from the Service_Class object
   class of the NslpResvRef message.  If the refresh procedure was
   successful the RSVP-NSLP functionality encapsulates the NslpResvRef
   message into the NTLP RESV message and it is sent towards the
   NI(sender).

   The NTLP functionality of the NF(ingress) can receive a NTLP PATHTEAR
   message sent by the NI(sender). The NTLP PATHTEAR message may
   optionally carry a NslpPathTear message.  The NTLP functionality
   activates the RSVPv2-NSLP "PDR/PHR" functionality, that is related to
   the Session_ID_Class class object, and that is using the "PDR"
   object.  The RSVPv2-NSLP "PDR" functionality of the NF(ingress) node
   will generate a release request "PHR" object denoted as
   "PHR_Release_Request" and a release request PDR object denoted as
   "PDR_Release_Request", (see Section 5.2.2).  The PDR object may
   contain information such as the IP address of the NF(ingress) node
   and the per-flow specification ID.  These PHR and PDR objects are
   locally defined objects which are included into the Service_Class
   object class carried by a NslpPathTear message.  All the RSVPv2-NSLP
   and NTLP reservations, in the NF(ingress) node that are associated to
   the Session_ID_Class object class will be released.

   During an unsuccessful procedure, the NTLP functionality of the
   NF(ingress) node can receive the a PATHERROR message that will





Westberg, et al.          Expires October 2003                 [Page 44]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   activate the RSVPv2-NSLP "PDR" functionality.  Due to the "M" marked
   "PDR_Reservation_Report" object the "PDR" functionality will activate
   the RSVPv2-NSLP "e2e service".  The RSVPv2-NSLP "e2e service"
   functionality of the NF(ingress) node will generate a NslpPathErr
   message that will be sent hop-by-hop to the NI(sender) and will be
   encapsulated into a NTLP PATHERROR message. This message will inform
   the NI(sender) that the reservation request was not successful.
   Simultaneously, the NF(ingress) node will start a partial explicit
   release procedure, for releasing the unnecessarily reserved RSVP-NSLP
   resources in some NF(interior) nodes for the rejected flow.  In this
   case, the RSVP-NSLP "PDR" functionality of the NF(ingress) node will
   generate a "PHR_Release_Request" object, and it will include the
   amount of the requested resources specified the PDR state.  Moreover,
   the RSVPv2-NSLP "PDR" functionality will create the
   "PDR_Reservation_Request" PDR object.  The RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node can calculate the number of
   NF(interior) nodes that processed and reserved RSVPv2-NSLP resources.
   This number can be calculated by subtracting the value included in
   the PDR_TTL field that was included in the received
   "PDR_Reservation_Report" PDR object from the value included in the
   PDR_TTL_I variable that has been stored into the RSVPv2-NSLP state
   when the initial NslpPathInit message has been sent towards the
   NF(egress) node.  This calculated value will be included in the TTL -
   IP header field of the NTLP PATHTEAR message which is generated by
   the NF(ingress) node and which transports the "PHR_Resource_Release"
   object. The "PHR_Release_Request" and "PDR_Release_Request" objects
   are included into a NslpPathTear message. The NslpPathTear message is
   transported by a NTLP PATHTEAR message.

   A NTLP PATH message that encapsulates the NslpPathMod message can be
   received by the NTLP functionality of the NF(ingress) node. The NTLP
   functionality activates the RSVP-NSLP "PDR/PHR" functionality, which
   is associated with the Session_ID_Class object class.

   When the modification request requires an increase on the number of
   reserved resources stored in the RSVPv2-NSLP state, then the
   RSVPv2-NSLP "PHR" functionality of the NF(ingress) node will have to
   subtract the old and already reserved number of resources from the
   number of resources included in the new modification request.  The
   result of this subtraction should be introduced within a
   "PHR_Resource_Request" PHR object as the requested resources value.
   Furthermore, the number of resources that were reserved for a certain
   flow in the RSVPv2-NSLP state should also be replaced with the number
   of resources included in the modification request.
    The RSVPv2-NSLP "PDR" functionality will create a





Westberg, et al.          Expires October 2003                 [Page 45]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   "PDR_Modification_Request" PDR object. These two objects will be
   included into the Service_Class of the NslpPathMod message.  The
   NslpPathMod message is encapsulated into a modification NTLP PATH
   message and is sent towards the NF(egress) node.

   When the modification request requires a decrease on the number of
   reserved resources stored in the RSVPv2-NSLP path state, then the
   RSVPv2-NSLP "PHR" functionality of the NF(ingress) node will have to
   subtract the number of resources included in the new modification
   request from the old and already reserved number of resources.  The
   result of this subtraction should be introduced in an RSVPv2-NSLP
   "PHR_Release_Request" PHR object.  Furthermore, the number of
   resources that were reserved in the RSVPv2-NSLP path state for a
   certain flow should also be replaced with the number of resources
   included in the modification request.  The RSVPv2-NSLP "PDR"
   functionality will create a "PDR_Modification_Request" PDR object.
   These two objects will be encapsulated into a modification NTLP PATH
   message.  This message will be sent towards the NF(egress) node.

    The NF(ingress) can receive a NslpResvMod message that is
   encapsulated into a RESV message. This message is associated with a
   NslpPathMod message that is sent earlier and that is used for a uni-
   directional reservation.  The "e2e service" functionality by
   extracting the Service_Class object from the NslpResvMod message, it
   can deduce that the modification procedure was successful. Moreover,
   the RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is
   extracting the "PDR_Refresh_Report" PDR object from the Service_Class
   object class of the NslpResvRef message.  If the modification
   procedure was successful the RSVP-NSLP functionality encapsulates the
   NslpResvMod message into the NTLP RESV message and it is sent towards
   the NI(sender).

   If the modification procedure is not successful, the NTLP
   functionality of the NF(ingress) node can receive a PATHERROR
   message.  This message carries a NslpPathErr message. The "e2e
   functionality" of the NF (ingress) will identify the modification
   type of the NslpPathErr message.  The NslpPathErr message could
   either carry a "PDR_Modification_Report" or not.  When the
   NslpPathErr message carries a "PDR_Modification_Report", the RSVP-
   NSLP "PDR" functionality will detect the "M" marked
   "PDR_Modification_Report" object and it will activate the RSVPv2-NSLP
   "e2e service".  When the NslpPathErr message does not carry a
   "PDR_Modification_Report" message, the RSVPv2-NSLP "e2e service" is
   directly activated.  The RSVPv2-NSLP "e2e service" functionality of
   the NF(ingress) node will generate a NslpPathErr message that will be





Westberg, et al.          Expires October 2003                 [Page 46]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   sent hop-by-hop to the NI(sender) and will be encapsulated into a
   NTLP PATHERROR message. This message will inform the NI(sender) that
   the modification request was not successful.  If the modification
   procedure required a higher amount of reservation, then the
   NF(ingress) node has to start a partial explicit release, for
   releasing the unnecessarily reserved RSVP-NSLP resources in some
   NF(interior) nodes for the modified flow.  The number of
   unnecessarily reserved resources is found by the RSVPv2-NSLP "PHR"
   functionality that subtracts the old and already reserved number of
   resources from the number of resources included in the new
   modification request.  The partial explicit release procedure is
   further accomplished in the same as the partial explicit release
   procedure used during the unsuccessful reservation procedure.

   The NTLP signaling messages and subsequently the "PHR" and "PDR"
   objects might be dropped, for example due to route or link failure.
   The "PHR" objects that need to be sent reliable are:
     PHR_Resource_Request
     PHR_Refresh_Update

   The reliable delivery of the "PHR_Resource_Request" object is
   provided by using the functionality provided by the RSVPv2-NSLP "PDR"
   functionality located in the NF(ingress) node.  The RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node sends the
   "PHR_Resource_Request" object towards the NF(egress) node and it
   starts a timer. If the reply, e.g., "PDR_Reservation_Report" object,
   does not arrive in a predefined time it assumes that the
   "PHR_Resource_Request" object is lost.  The reliable deliver of the
   "PHR_Refresh_Update" object is provided in a similar way. A timer at
   the NF(ingress) node is started when the "PHR_Refresh_Update" is sent
   towards the NF(egress) node. If the reply, e.g., "PDR_Refresh_Report"
   object, does not arrive in a predefined time it assumes that the
   "PHR_Refresh_Update" object is lost.

   During a severe congestion situation, the NF(ingress) node can
   receive the PDR_Congestion_Report object. This object is included
   into a NslpPathErr message that is carried by a NTLP PATHERROR.  The
   RSVPv2-NSLP PDR functionality of the NF(ingress) node is extracting
   the Pdrop blocking probability from the PDR_Congestion_Report
   message.  Depending on the used policy the NF(ingress) node might
   terminate the flow, i.e., for a higher blocking probability there is
   a higher chance that the flow is terminated.  If a flow needs to be
   terminated, then for this flow, the NF(ingress) node will generate a
   "PHR_Release_Request" object that will be included into the
   Service_Class of the NslpPathTear message.  This message will be





Westberg, et al.          Expires October 2003                 [Page 47]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   transported by a NTLP PATHTEAR message towards the NF(egress).
   Furthermore, the RSVPv2-NSLP "e2e service" functionality in the
   NF(ingress) node will create a NslpPathErr that will be encapsulated
   into a NTLP PATHERROR that will be sent towards the NI(sender) to
   notify that an error occurred.



5.4.3.2.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NF(ingress) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is
   described in Section 5.4.3.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite
   directions are as follows:


     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NF(ingress) does not receive the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the PDR_Reservation_Report object used to report a successful
       reservation procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
     * the PDR_Refresh_Report object used to report a successful refresh
       procedure is carried by the NslpPathInit that is sent hop-by-hop
       from NF(egress) towards the NF(ingress)
     * the PDR_Modification_Report object used to report a successful
       modification procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
    *  the NF(egress) node can initiate an explicit partial release
       procedure towards the NF(ingress) node.





Westberg, et al.          Expires October 2003                 [Page 48]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






5.4.4.  NF (interior) functionality

   The NF (interior) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.


5.4.4.1.  Unidirectional functionality

   The initiation NTLP PATH message is processed by all NTLP stateless
   NF(interior) nodes that is passing through, up to the NF (egress).
   Each stateless NF(interior) node that processes the NTLP PATH message
   it will not create a  NTLP state but it will activate the RSVPv2-NSLP
   functionality by using the transported NslpPathInit message.  The
   RSVPv2-NSLP "PHR" functionality of these NF(interior) nodes will use
   the information included in the PHR object ("PHR_Resource_Request")
   and it will identify the ID of the traffic class, e.g., Diffserv
   class. If there is enough bandwidth capacity, it will reserve the
   requested resources. The NF(interior) node reserves the requested
   resources by e.g., adding the requested amount to the total amount of
   reserved resources for that traffic class, e.g., Diffserv class.

   It is possible that one of the NTLP stateless NF(interior) is not
   able to satisfy the request carried by the "PHR_Resource_Request" PHR
   object. The RSVPv2-NSLP "PHR" functionality of this NF(interior) node
   will mark the "M" field of the "PHR_Resource_Request" object.  The
   RSVPv2-NSLP "PHR" functionality will also include the number of
   previous NF(interior) nodes that successfully processed the
   RSVPv2-NSLP "PHR_Resource_Request" PHR object (see Appendix). This
   number can, for example, be identified by the TTL (Time-To-Live)
   value included in the IP header of the received NTLP PATH message.
   Note that each time that an IP packet passes a node, its TTL value is
   decreased by one.  In particular, the NF(interior) node that is not
   admitting the reservation request initiated by the
   "PHR_Resource_Request" PHR object will copy the TTL value included in
   the IP header of the received NTLP PATH message that carries the
   "PHR_Resource_Request" object into the "PDR_TTL" field of
   "PDR_Reservation_Request" PDR object.  Moreover, the "T" field of the
   "PHR" object (see Appendix) is set to "1". These "PHR" and "PDR"
   objects are included in the NslpPathInit message. The NslpPathInit
   message is encapsulated into a NTLP PATH message.  This NslpPathInit
   message is sent towards the NF(egress) node, which will be
   transported by a NTLP PATH message. Any NF(interior) node receiving a
   PATH message will activate the RSVPv2-NSLP "PHR" functionality. If
   the "PHR_Resource_Request" PHR object is "M" marked, then the
   RSVPv2-NSLP "PHR" functionality will not further process the "PHR"





Westberg, et al.          Expires October 2003                 [Page 49]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   object.

   The refresh NTLP PATH message is processed by all NTLP stateless
   NF(interior) nodes that is passing through, up to the NF (egress).
   Each node that processes the refresh NTLP PATH message it will
   refresh the NTLP state associated with the session ID, i.e.,
   information included into the Session_ID_Class object class.  The
   NTLP level functionality of the NTLP stateless NF(interior) nodes
   receiving the refresh NTLP PATH message will activate the RSVPv2-NSLP
   "PHR" functionality.  The RSVPv2-NSLP "PHR" functionality of these
   NF(interior) nodes will use the information included in the PHR
   object ("PHR_Refresh_Request") and it will identify the ID of the
   traffic class, e.g., Diffserv class. This object will refresh the
   requested resources included in the "PHR_Refresh_Update" object.

   The NTLP PATHTEAR message is processed by all NTLP stateless
   NF(interior) nodes that is passing through, up to the NF (egress).
   Each node that processes the PATHTEAR message will activate the
   RSVPv2-NSLP "PHR" functionality by using the transported RSVPv2-NSLP
   "PHR" object.  The NTLP functionality in the NTLP stateless
   NF(interior) node that receives the PATHTEAR message will pass the
   NslpPathTear message to the RSVPv2-NSLP functionality. The
   NslpPathTear message contains the "PHR_Release_Request" and
   "PDR_Release_Request" PHR and PDR objects, respectively.  The
   RSVPv2-NSLP "PHR" functionality of this NF(interior) node will use
   the information included in the PHR object ("PHR_Release_Request")
   and it will identify the ID of the traffic class, e.g., Diffserv
   class. This object will subtract the requested resources included in
   the "PHR_Release_Request" object from the total reserved amount of
   resources stored in the traffic class state.  Moreover, its TTL value
   of the NTLP PATHTEAR message is decremented by one.  If this value
   becomes zero, the "PHR_Resource_Release" object reached an
   NF(interior) node that marked the "PHR_Resource_Request" object
   during an unsuccessful procedure and the NTLP PATHTEAR message will
   be dropped.  Otherwise, the NTLP PATHTEAR message propagates towards
   the NR(receiver).

   Each stateless NF(interior) node that receives the modification NTLP
   PATH message will activate the RSVPv2-NSLP "PHR" functionality. The
   RSVPv2-NSLP "PHR" functionality of each stateless NF(interior)node
   processes the "PHR_Resource_Request"  and "PHR_Release_Request"
   objects included in the modification NTLP PATH message as typical
   "PHR_Resource_Request" and "PHR_Release_Request" objects,
   respectively.






Westberg, et al.          Expires October 2003                 [Page 50]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   After detecting the severe congestion situation, the RSVPv2-NSLP
   "PHR" functionality of the NF(interior) node will notify the
   NF(egress) node by using remarking of user data bytes that pass
   through the node.  Proportionally to the detected overload the
   NF(interior) node will remark a number of user data bytes which are
   passing through a severe congested interior node and are associated
   with a certain traffic class, e.g., DSCP, into a domain specific
   DSCP.



5.4.4.2.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NF(interior) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is
   described in Section 5.4.4.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite
   directions are as follows:


     * the PDR_Reservation_Report object used to report a successful
       reservation procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
     * the PDR_Refresh_Report object used to report a successful refresh
       procedure is carried by the NslpPathInit that is sent hop-by-hop
       from NF(egress) towards the NF(ingress)
     * the PDR_Modification_Report object used to report a successful
       modification procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
    *  the NF(egress) node can initiate an explicit partial release
       procedure towards the NF(ingress) node.




5.4.5.  NF (egress) functionality

   The NF (egress) functionality can be characterized as unidirectional
   and bi-directional reservation functionality.








Westberg, et al.          Expires October 2003                 [Page 51]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






5.4.5.1.  Unidirectional functionality

   The behavior of the NF(egress) node on admission or rejection of the
   NslpPathInit message that contains the "PHR_Resource_Request" object
   is the same as in the NF(interior) nodes.  After processing the
   "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of the
   NF(egress) node uses the "PDR_Reservation_Request" object and
   creates/identifies the flow specification ID and the state associated
   with it.  Subsequently, the RSVPv2-NSLP "e2e service" functionality
   is activated and by using the information contained in the
   Flow_Specification_Class it will create an RSVPv2-NSLP Path
   reservation.  If the request is admitted, the RSVPv2-NSLP "PDR"
   functionality of the NF(egress) node will report the successful
   reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
   node by using a "PDR_Reservation_Report" PDR object.  This object is
   temporarilty stored until a NslpresvInit message arrives that is
   carried by a NTLP RESV message, that was sent by the NR(receiver) and
   that is associated with an earlier processed NslpPathInit message.
   This "PDR_Reservation_Report" PDR object will be included into the
   Service_Class object class of the NslpResvInit message.  The NTLP
   PATH message is forwarded towards the NR (receiver).  Note that this
   NTLP PATH message will not include the "PDR/PHR" object information.
   If the "PHR_Resource_Request" PHR object is "M" marked, then the
   RSVPv2-NSLP "PHR" functionality will activate the RSVPv2-NSLP "PDR"
   functionality which will create and "M" mark the
   "PDR_Reservation_Report" object. Moreover, if the "T" field value
   included in the "PHR" object is "1" then the PDR_TTL value that was
   included by the NF(interior) node into the "PDR_Reservation_Request"
   object will be copied into the PDR_TTL value of the
   "PDR_Reservation_Report" object.  The "PDR" object will be included
   in an NslpPathErr message.  The NslpPathErr message will be
   encapsulated into a NTLP PATHERROR message. The NslpPathError message
   will only be processed by the NF(ingress) node.

   When the NF(egress) node receives a NslpPathError message which is
   carried by a PATHERROR message will have to identify the error type.
   If the NSlpPathErr message is associated to a NslpPathInit message
   then the NslpPathErr will have to be encapsulated into a NTLP
   PATHERROR message and sent towards the NI(sender). Moreover, its
   associated RSVPv2-NSLP state has to be deleted. The NTLP PATHERROR
   message will be processed within the NSIS intra-domain only by the
   NF(ingress) node.  If the NslpPathErr message is associated to a
   NslpPathMod request, then then the NslpPathErr will have to be
   encapsulated into a NTLP PATHERROR message and sent towards the
   NI(sender). Moreover, if the modification procedure required a higher





Westberg, et al.          Expires October 2003                 [Page 52]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   amount of reservation, then the nodes that modified the reservation
   will have to reset the reservation to the amount (or type) of
   reservation that was stored before the modification procedure
   started.

   The NF(egress) node can receive a NslpResvInit message, carried by a
   NTLP RESV message which was sent by the NR(receiver) and is
   associated with an earlier processed NslpPathInit message. The
   RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
   the successful reservation to the RSVPv2-NSLP "PDR" functionality of
   the NF(ingress) node by using a "PDR_Reservation_Report" PDR object.
   This object will be included into the Service_Class object class of
   the NslpResvInit message. Note that this message is processed in a
   NSIS intra-domain only by the NF(egress) and NF(ingress) nodes.  The
   NF(interior)nodes are not processing this message.

   The NF(egress) node can receive a refresh NTLP PATH message.  The
   NF(egress) node that processes the refresh NTLP PATH message it will
   refresh the NTLP state associated with the session ID included into
   the Session_ID_Class object class. Furthermore, it will activate the
   RSVPv2-NSLP "PHR" functionality by using the transported RSVPv2-NSLP
   "PHR" object.  The behavior of the RSVPv2-NSLP "PHR" functionality in
   the NF(egress) node is similar to the RSVPv2-NSLP "PHR" functionality
   provided in the NF(interior) nodes.  If the refresh is admitted, the
   RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
   the successful refresh procedure to the RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node by using a "PDR_Refresh_Report"
   PDR object.  This object is temporarilty stored until a NslpResvRef
   message arrives that is carried by a NTLP RESV message, that was sent
   by the NR(receiver) and that is associated with an earlier processed
   NslpPathRef message.  This "PDR_Refresh_Report" PDR object will be
   included into the Service_Class object class of the NslpResvRef
   message.  The NTLP PATH message is forwarded towards the NR
   (receiver).  Note that this NTLP PATH message will not include the
   "PDR/PHR" object information.

   The NF(egress) node can receive a NslpResvRef message, carried by a
   NTLP RESV message which was sent by the NR(receiver) and is
   associated with an earlier processed NslpPathRef message. The
   RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
   the successful refresh PDR/PHR procedure to the RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node by using a "PDR_Refresh_Report"
   PDR object. This object will be included into the Service_Class
   object class of the NslpResvRef message.  Note that this message is
   processed in a NSIS intra-domain only by the NF(egress) and





Westberg, et al.          Expires October 2003                 [Page 53]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NF(ingress) nodes. The NF(interior) nodes are not processing this
   message.

   The NF(egress) node that processes the PATHTEAR message it will
   activate the RSVPv2-NSLP "PHR" functionality by using the transported
   "PHR" object.  The behavior of the RSVPv2-NSLP "PHR" functionality in
   the NF(egress) node is similar to the RSVPv2-NSLP "PHR" functionality
   provided in the NF(interior) nodes. Furthermore, the NTLP state is
   released and the PATHTEAR message is forwarded towards the NR
   (receiver).  Note that this PATHTEAR message will not include the
   "PDR/PHR" objects.

   The behavior of the NF(egress) node related to the modification
   procedure is the same as in the NF(interior) nodes.  After receiving
   the modification NTLP PATH message the RSVPv2-NSLP is processing
   either the "PHR_Resource_Request" or "PHR_Release_Request" object.
   After that the RSVPv2-NSLP functionality of the NF(egress) node uses
   the "PDR_Modification_Request" object and identifies the flow
   specification ID and the RSVPv2-NSLP state associated with it.
   Subsequently, the RSVPv2-NSLP "e2e service" functionality is
   activated and by using the information contained in the
   Flow_Specification_Class it will modify the reservation stored into
   the RSVPv2-NSLP path state.  If the modification is admitted, the
   RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
   the successful modification procedure to the RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node by using a
   "PDR_Modification_Report" PDR object.  This object is temporarily
   stored until a NslpResvMod message arrives that is carried by a NTLP
   RESV message, which was sent by the NR(receiver) and that is
   associated with an earlier processed NslpPathMod message.  This
   "PDR_Modification_Report" PDR object will be included into the
   Service_Class object class of arriving NslpResvMod message.  The
   modification NTLP PATH message is forwarded towards the NR
   (receiver).  Note that this NTLP PATH message will not include the
   "PDR/PHR" object information.

   The NF(egress) node can receive a NslpResvMod message, carried by a
   NTLP RESV message which was sent by the NR(receiver) and is
   associated with an earlier processed NslpPathMod message. The
   RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
   the successful modification procedure PDR/PHR procedure to the
   RSVPv2-NSLP "PDR" functionality of the NF(ingress) node by using a
   "PDR_Modification_Report" PDR object. This object will be included
   into the Service_Class object class of the NslpResvMod message.  Note
   that this message is processed in a NSIS intra-domain only by the





Westberg, et al.          Expires October 2003                 [Page 54]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NF(egress) and NF(ingress) nodes. The NF(interior) nodes are not
   processing this message.

   During a severe congestion situation marked data packets arrive at
   the NF(egress) node. When the marked packets arrive at the NF(egress)
   node, the NF(egress) node will generate a "PDR_Congestion_Report"
   object and send it to the NF(ingress) node containing the over-
   allocation volume of the flow in question, e.g., a blocking
   probability. The "PDR_Congestion_Report" PDR object should be
   included into a NslpPathErr and transported by a NTLP PATHERROR
   message.  For each flow ID, the RSVPv2-NSLP PDR functionality at the
   NF(egress) node will count the number of marked bytes (# marked
   bytes) and the number of unmarked bytes (#unmarked bytes).  Based on
   this information the RSVPv2-NSLP PDR functionality at the NF(egress)
   node will have to calculate the blocking estimation of data. The
   NF(egress) node will actually calculate the blocking probability
   (Pdrop), which will be used by an NF(ingress) node to block this
   particular flow.  The blocking probability is calculated as the ratio
   between the dropped bytes and the maximum number of bytes that can be
   supported by the interior node:

   Pdrop = (# marked bytes)/(# marked bytes + # unmarked bytes)

   This blocking probability will be included in the
   "PDR_Congestion_Report" object that will be sent to the NF(ingress).


5.4.5.2.  Bidirectional functionality

   The bi-directional reservation functionality supported by the
   NF(egress) is similar to a combination of two unidirectional
   reservation functionalities that are accomplished in opposite
   directions. Such a unidirectional reservation functionality is
   described in Section 5.4.5.1.  The main differences of the bi-
   directional reservation functionality with the combination of two
   unidirectional reservation functionalities accomplished in opposite
   directions are as follows:


     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NF(egress) does not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)





Westberg, et al.          Expires October 2003                 [Page 55]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the PDR_Reservation_Report object used to report a successful
       reservation procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
     * the PDR_Refresh_Report object used to report a successful refresh
       procedure is carried by the NslpPathInit that is sent hop-by-hop
       from NF(egress) towards the NF(ingress)
     * the PDR_Modification_Report object used to report a successful
       modification procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
    *  the NF(egress) node can initiate an explicit partial release
       procedure towards the NF(ingress) node.




5.4.6.  NR (NSIS Responder) functionality

   The NR (NSIS Responder) functionality can be characterized as
   unidirectional and bi-directional reservation functionality.


5.4.6.1.  Unidirectional functionality

   The unidirectional functionality supported by the NR(receiver) used
   in this type of scenarios is identical to the functionality supported
   by the NR(receiver) used in the inter-domain signaling scenario (see
   Section 5.3.3.1).


5.4.6.2.  Bidirectional functionality

   The bi-directional functionality supported by the NR(receiver) used
   in this type of scenarios is identical to the functionality supported
   by the NR(receiver) used in the inter-domain signaling scenario (see
   Section 5.3.3.2).







Westberg, et al.          Expires October 2003                 [Page 56]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






6.  Example of RSVPv2-NSLP Inter-domain signaling procedures

   This section gives a brief description of the main flow diagram used
   by the RSVPv2-NSLP protocol for inter-domain signaling procedures.
   RSVPv2-NSLP is considered in this section to be optimized for unicast
   and sender-initiated protocol. This means that the NslpPathInit
   initiates and activates a reservation in each node that is passing
   through.  The Inter-domain signaling procedures are mainly using
   globally defined objects, i.e., e2e service objects, see Figure 1.


6.1.  Normal operation for uni-directional reservation

   This section presents examples of RSVPv2-NSLP inter-domain signaling
   procedures for RSVPv2-NSLP normal operation, i.e., successful
   reservation and operation without failures. In this example only the
   uni-directional feature is considered and it is assummed that no
   intra-domain signaling procedures are used.

   Figure 4 shows the main flow diagram used by the RSVPv2-NSLP
   protocol.  The NI(sender), after creating an NSLP reservation state,
   generates an NslpPathInit. The flow ID, the ID of the NSLP protocol
   and the time values can be included in the Flow_Specificaton_Class
   (e.g., <Session>, <Sender_template>, <Time_Values>, <NSLP_ID>
   objects). The session ID and the ID of the NSLP protocol can be
   included in the Session_ID_Class (e.g., <Session> and <NSLP_ID>
   objects).  The information that is related to the service desired
   from the network, i.e., requested QoS, can be included into the
   Service_Class object class (e.g., <Sender_Tspec> and <Flowspec>
   objects).

   The NslpPathInit is encapsulated into a NTLP PATH message (see
   [RFC2205]).  The NTLP PATH message is processed by all NTLP stateful
   nodes that is passing through, up to the NR (receiver). Each node
   that processes the NTLP PATH message will create a NTLP state and
   will activate the RSVPv2-NSLP "e2e service" functionality by using
   the transported NslpPathInit information and it will create an
   RSVPv2-NSLP reservation state. This RSVPv2-NSLP reservation state
   will be associated to a flow ID.  Note that the NTLP states have to
   store back-ward routing information, which are used by NTLP messages
   that are transported hop-by-hop in the backward direction towards the
   NI(sender).

   When the NR(receiver) receives NslpPathInit the RSVPv2-NSLP "e2e
   service" functionality creates an NslpResvInit message that is used





Westberg, et al.          Expires October 2003                 [Page 57]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   to report information related to how the NslpPathInit has been
   processed along the path.  This NslpResvInit will be encapsulated
   into a RESV message and it will only be processed by the RSVPv2-NSLP
   "e2e service" functionality at each hop that is passing by and that
   is supporting the "e2e service" functionality.

   After the successful reception of the NslpResvInit message the
   NI(sender) can start transmitting traffic user data.

   Figure 4 also shows how the refresh procedure is performed. The
   RSVPv2-NSLP refresh procedure is a pure NTLP refresh procedure,
   meaning that a refresh NTLP PATH message that is periodically sent
   through all the NTLP stateful nodes located between NI (sender) and
   NR (receiver).  If a NTLP state in a NTLP stateful is not refreshed
   on time then the NTLP functionality at this node informs the
   RSVPv2-NSLP state that the refresh procedure is unsuccesful.  Note
   that the refresh NTLP PATH message may optionally carry a NSLPPathRef
   message.  NR (receiver) will create a refresh NTLP RESV message that
   will be sent towards the NI (sender). This message will be used to
   report information related to how the NTLP PATH message has been
   processed along the path.  Note that the refresh NTLP RESV message
   may optionally carry a NSLPResvRef message.




























Westberg, et al.          Expires October 2003                 [Page 58]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






 NI (sender)          NF (router)          NF (router)       NR (receiver)
NTLP stateful       NTLP stateful         NTLP stateful     NTLP stateful
       PATH(NslpPathInit)  |                    |                    |
      |------------------->|                    |                    |
      |                    |                    |                    |
      |                    |PATH(NslpPathInit)  |                    |
      |                    |------------------->| PATH(NslpPathInit) |
      |                    |                    |------------------->|
      |                    |                    | RESV(NslpResvInit) |
      |                    | RESV(NslpResvInit) |<-------------------|
      |                    |<-------------------|                    |
      |RESV(NslpResvInit)  |                    |                    |
      |<-------------------|                    |                    |
      |                    | Traffic(user) Data |                    |
      |------------------->|------------------->|------------------->|
      |                    |                    |                    |
      |PATH([NslpPathRef]) |                    |                    |
      |------------------->|                    |                    |
      |                    |                    |                    |
      |                    |PATH([NslpPathRef]) |                    |
      |                    |------------------->|PATH([NslpPathRef]) |
      |                    |                    |------------------->|
      |                    |                    | RESV([NslpResvRef])|
      |                    | RESV([NslpResvRef])|<-------------------|
      |                    |<-------------------|                    |
      |RESV([NslpResvRef])|                     |                    |
      |<-------------------|                    |                    |


    Figure 4: Inter-domain signaling normal operation for successful
                  reservation




Figure 5 depicts the RSVPv2-NSLP tearing down procedure.  In Figure 5
The RSVPv2-NSLP "e2e service" functionality of the NI(sender) informs
the NTLP functionality of the same node to start a tear down procedure
for the specific flow. A NTLP PATHTEAR message is created that is sent
towards  the NR (receiver). This message will tear down all the NTLP and
RSVPv2-NSLP states that are associated with the Session_ID_Class of all
NTLP stateful nodes that process the NTLP PATHTEAR message.  Note that
the NTLP PATHTEAR message may optionally carry a NSLPPathTear message.







Westberg, et al.          Expires October 2003                 [Page 59]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






 NI (sender)          NF (router)          NF (router)       NR (receiver)
NTLP stateful        NTLP stateful        NTLP stateful      NTLP stateful
         |PATHTEAR([NslpPathTear])                 |                    |
         |------------------->|                    |                    |
         |                    |PATHTEAR([NslpPathTear])                 |
         |                    |------------------->|PATHTEAR([NslpPathTear])
         |                    |                    |------------------->|

Figure 5: Inter-domain signaling normal operation for tearing down a
          reservation initiated by NI (sender)




Figure 6 shows the main flow diagram used by the RSVPv2-NSLP protocol in
case of an unsuccessful reservation assuming that no intra-domain
signaling procedures are used. In this situation only the uni-
directional feature is considered.  In this situation the NslpPathInit
and NTLP PATH messages are created and transmitted in the same way as
during the successful reservation.  The main difference is related to
the fact that one of the NF(routers) is not able to satisfy the
NslpPathInit request. In this situation this RSVPv2-NSLP "e2e service"
functionality of this particular NF(router) will generate an NslpPathErr
to report to NI(sender) that the NslpPath request could not be
satisfied.  This NslpPathErr message will be encapsulated into a NTLP
PATHERROR message and it will be sent hop-by-hop towards the NI(sender).
This message will be processed hop-by-hop by the RSVPv2-NSLP  "e2e
service" functionality.

NI (sender)         NF (router)          NF (router)       NR (receiver)
NTLP stateful       NTLP stateful       NTLP stateful      NTLP stateful
      PATH(NslpPathInit)  |                    |                    |
     |------------------->|                    |                    |
     |                    |                    |                    |
     |                    | PATH(NslpPathInit) |                    |
     |                    |------------------->|                    |
     |                    |                    |                    |
     |                PATHERROR(NslpPathErr)   |                    |
     |                    |<-------------------|                    |
     |PATHERROR(NslpPathErr)                   |                    |
     |<-------------------|                    |                    |

   Figure 6: Inter-domain signaling normal operation for unsuccessful
             reservation






Westberg, et al.          Expires October 2003                 [Page 60]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






Figure 7 shows the main flow diagram used by the RSVPv2-NSLP protocol in
case of a modification of a reservation procedures assuming that no
intra-domain signaling procedures are used. In this situation only the
uni-directional feature is considered.  The modification of the
reservation is included in a new NslpPathMod message. This NSLP message
is encapsulated into a NTLP PATH message and it is sent hop-by-hop
towards the NR(receiver).  The flow ID of the flow that has to be
modified is included in the Flow_Specificaton_Class. The information
that has to be modified that is included into the Service_Class object
class. (e.g., <Sender_Tspec> and <Flowspec> objects).

The NslpPathMod information is read by each NTLP stateful node that
processes the NTLP PATH message.  The RSVPv2-NSLP functionality
identifies the flow that has to be modified by using its flow ID
information carried by the NslpPathMod message.  By using the
information contained in the Service_Class, the RSVPv2-NSLP
functionality is modifying the service information stored into the
RSVPv2-NSLP state.


Subsequently the RSVPv2-NSLP "e2e service" functionality at the
NR(receiver) will create an NslpResvMod that will be used to report
information related to how the NslpPathMod message has been processed
along the path.  This NslpResvMod message will be encapsulated into a
NTLP RESV message and sent hop-by-hop towards the NI(sender).

When a NSIS node is not able to satisfy a NslpPathMod request the
RSVPv2-NSLP "e2e service" functionality of this node will generate an
NslpPathErr to report to NI(sender) that the NslpPathMod request could
not be satisfied.  This message will be encapsulated into a NTLP
PATHERROR message and it will be sent towards the NI(sender). In this
case the "e2e functionality" of any NSIS node will identify the
modification type of the NslpPathErr message.  If the modification
procedure required a higher amount of reservation, then the reservation
asociated to the modified flow will have to be reseted to the
reservation or to the amount (or type) of reservation that was stored
before the modification procedure started.













Westberg, et al.          Expires October 2003                 [Page 61]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NI (sender)          NF (router)         NF (router)      NR (receiver)
NTLP stateful       NTLP stateful       NTLP stateful     NTLP stateful
    PATH(NslpPathMod)   |                    |                    |
   |------------------->|                    |                    |
   |                    | PATH(NslpPathMod)  |                    |
   |                    |------------------->|PATH(NslpPathMod)   |
   |                    |                    |------------------->|
   |                    |                    |  RESV(NslpResvMod) |
   |                    | RESV(NslpResvMod)  |<-------------------|
   |                    |<-------------------|                    |
   | RESV(NslpResvMod)  |                    |                    |
   |<-------------------|                    |                    |

  Figure 7: Inter-domain signaling normal operation for modification of
            reservation



6.2.  Normal operation for bi-directional reservation

   This section gives one example of inter-domain signaling for a
   successful and one example of inter-domain signaling for an
   unsuccessful bi-directional reservation.  Figure 8 shows the flow
   diagram of inter-domain signaling used by the RSVPv2-NSLP protocol in
   case of a successful bi-directional reservation.

   The bi-directional successful reservation is similar to a combination
   of two unidirectional successful reservations that are accomplished
   in opposite directions.  The main differences of the bi-directional
   successful reservation procedure with the combination of two
   unidirectional successful reservations accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NSIS aware nodes do not receive the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)





Westberg, et al.          Expires October 2003                 [Page 62]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)


   Figure 9 shows the flow diagrams of inter-domain signaling used by
   the RSVPv2-NSLP protocol in case of a unsuccessful bi-directional
   reservation. The bi-directional unsuccessful reservation is similar
   to a combination of two unidirectional unsuccessful reservations that
   are accomplished in opposite directions.  The main differences of the
   bi-directional unsuccessful procedure with the combination of two
   unidirectional successful reservations accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
































Westberg, et al.          Expires October 2003                 [Page 63]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NI (sender)          NF (router)          NF (router)       NR (receiver)
NTLP stateful       NTLP stateful         NTLP stateful     NTLP stateful
       PATH(NslpPathInit)  |                    |                    |
      |------------------->|                    |                    |
      |                    |           PATH(NslpPathInit)            |
      |                    |---------------------------------------->|
      |                    |                    |                    |
      |                    |                    |  PATH(NslpPathInit)|
      |                    |                    |<-------------------|
      |             PATH(NslpPathInit)          |                    |
      |<----------------------------------------|                    |
      |                    |                    |                    |
      |                    |                    |                    |
      |                    | Traffic(user) Data |                    |
      |------------------->|---------------------------------------->|
      |                    |                    |                    |
      |                    | Traffic(user) Data |                    |
      |<----------------------------------------|<-------------------|
      |                    |                    |                    |
      |                    |                    |                    |
      |PATH([NslpPathRef]) |                    |                    |
      |------------------->|                    |                    |
      |                    |PATH([NslpPathRef]) |                    |
      |                    |---------------------------------------->|
      |                    |                    |                    |
      |                    |                    | PATH([NslpPathRef])|
      |           PATH([NslpPathRef])           |<-------------------|
      |<----------------------------------------|                    |
      |                    |                    |                    |

  Figure 8: Inter-domain signaling for bi-directional
            reservation in case of a successful reservation


















Westberg, et al.          Expires October 2003                 [Page 64]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NI (sender)          NF (router)          NF (router)       NR (receiver)
NTLP stateful       NTLP stateful         NTLP stateful     NTLP stateful
       PATH(NslpPathInit)  |                    |                    |
      |------------------->|                    |                    |
      |                    |           PATH(NslpPathInit)            |
      |                    |---------------------------------------->|
      |                    |                    |                    |
      |                    |                    |  PATH(NslpPathInit)|
      |                    |                    |<-------------------|
      |                    |                    |                    |
      |                    |                   PATHERROR(NslpPathErr)|
      |                    |                    |------------------->|
      |                    |         PATHERROR(NslpPathErr)          |
      |                    |<----------------------------------------|
      | PATHERROR(NslpPathErr)                  |                    |
      |<-------------------|                    |                    |

  Figure 9: Inter-domain signaling for bi-directional reservation in case of
            an unsuccessful reservation



7.  Example of RSVPv2-NSLP Intra-domain signaling procedures

   This section gives a brief description of the main flow diagram used
   by the RSVPv2-NSLP protocol for intra-domain signaling procedures.
   These intra-domain signaling procedures are using the NSIS protocol
   which consists of one NTLP level and two NSLP hierarchical levels
   (see Figure 2).

   Intra-domain signaling is where the RSVPv2-NSLP signaling messages
   are originated, processed and terminated within the same domain.
   RSVPv2-NSLP is considered in this section to be optimized for unicast
   and sender-initiated protocol.

   The Intra-domain signaling procedures are mainly using RSVPv2-NSLP
    PHR/PDR objects, (see Section 5.2.2) that are originated, processed
   and terminated within the same domain.



7.1.  Normal operation for uni-directional reservation

   This section presents examples of RSVPv2 intra-signaling procedures
   for RSVPv2-NSLP normal operation, i.e., operation without failures.





Westberg, et al.          Expires October 2003                 [Page 65]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Figure 10 shows the main flow diagram intra-domain signaling used by
   the RSVPv2-NSLP protocol in case of a successful reservation.  In
   this situation only the uni-directional feature is considered.  Note
   that the same figure shows how the RSVPv2-NSLP inter-domain and
   intra-domain signaling can inter-operate.  When an NslpPathInit
   arrives at the ingress node of a domain, i.e., NF(ingress) (see
   Figure 10), the RSVPv2-NSLP "e2e service" functionality creates a
   RSVPv2-NSLP Path reservation state.  Subsequently, the RSVPv2-NSLP
   "PDR" protocol functionality is activated (see Figure 2) classifying
   the flow (i.e., Flow_Specification_Class) that is associated with the
   NslpPathInit message into an appropriate traffic class, e.g.,
   Diffserv class.  The RSVPv2-NSLP PDR functionality uses the
   RSVPv2-NSLP path state created by the NslpPathInit message and it
   introduces additional information that can be used to associate the
   PHR and PDR objects with the flow that created the RSVPv2-NSLP Path
   reservation state in the NF(ingress) node.  The RSVPv2-NSLP PDR
   functionality is subsequently using the Service_Class (e.g.,
   <SENDER_Tspec> object) and translates the requested bandwidth
   parameter into a number of resource units.  If the QoS request is
   satisfied locally, then the ingress node will generate a reservation
   request PHR object denoted as "PHR_Resource_Request" and a
   reservation request PDR object denoted as "PDR_Reservation_Request",
   (see Section 5.2.2).  The PDR object MAY contain information such as
   the IP address of the NF(ingress) node and the per-flow specification
   ID.  These PHR and PDR objects are locally defined objects which are
   included into the Service_Class object class carried by the
   NslpPathInit message.  The NslpPathInit message is encapsulated into
   a NTLP PATH message.  The NTLP PATH message is processed by all NTLP
   stateless NF(interior) nodes that is passing through, up to the NF
   (egress). Each stateless NF(interior) node that processes the NTLP
   PATH message it will not create a  state but it will activate the
   RSVPv2-NSLP functionality by using the transported NslpPathInit
   message.  The RSVPv2-NSLP "PHR" functionality of these NF(interior)
   nodes will use the information included in the PHR object
   ("PHR_Resource_Request") and it will identify the ID of the traffic
   class, e.g., Diffserv class. If there is enough bandwidth capacity,
   it will reserve the requested resources. The NF(interior) node
   reserves the requested resources by e.g., adding the requested amount
   to the total amount of reserved resources for that traffic class,
   e.g., Diffserv class.

   The behavior of the NF(egress) node on admission or rejection of the
   NslpPathInit message that contains the "PHR_Resource_Request" object
   is the same as in the NF(interior) nodes.  After processing the
   "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of the





Westberg, et al.          Expires October 2003                 [Page 66]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NF(egress) node uses the "PDR_Reservation_Request" object and
   creates/identifies the flow specification ID and the state associated
   with it.  Subsequently, the RSVPv2-NSLP "e2e service" functionality
   is activated and by using the information contained in the
   Flow_Specification_Class it will create an RSVPv2-NSLP Path
   reservation.  The NTLP PATH message is forwarded towards the NR
   (receiver), and it will be processed by all NTLP stateful nodes that
   is passing through as an inter-domain signaling procedure, see
   Section 6.  Note that this NTLP PATH message will not include the
   "PDR/PHR" object information.

   When the NR(receiver) receives the NTLP PATH message, similar to the
   procedure used in Section 6, it will create a NTLP state and it will
   activate the RSVPv2-NSLP "e2e service" functionality by using the
   NslpPathInit message. It will create a RSVPv2-NSLP path reservation
   state which will be identified by using the information contained in
   the Flow_Specification_Class object class.

   Subsequently the RSVPv2-NSLP "e2e service" functionality will create
   an NslpResvInit message that will be used to report information
   related to how the NslpPathInit has been processed along the path.
   This NslpResvInit will be encapsulated into a RESV message and it
   will only be processed by the RSVPv2-NSLP "e2e service" functionality
   at each hop that is passing by and that is supporting the "e2e
   service" functionality. Note that this message is processed in a
   domain only by the NF(egress) and NF(ingress) nodes. The NF(interior)
   nodes are not processing this message.  Moreover, the RSVPv2-NSLP
   "PDR" functionality of the NF(egress) node will report the successful
   reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
   node by using a "PDR_Reservation_Report" PDR object.  This object
   will be included into the Service_Class object class of the
   NslpResvInit message.

   After the successful reception of the NslpResvInit message, the
   NI(sender) can start transmitting traffic user data.  Figure 10 also
   shows how the refresh procedure is performed.

   The inter-domain RSVPv2-NSLP refresh procedure is a pure NTLP refresh
   procedure, see Section 6.  However, the intra-domain RSVPv2-NSLP
   refresh procedure is a combination of a NTLP and a RSVPv2-NSLP
   "PHR/PDR" procedure.  When a refresh NTLP PATH message is received by
   a NF(ingress) node the NTLP functionality will activate the
   RSVPv2-NSLP "PHR/PDR" functionality that is carried by the
   NslpPathRef message.  By using the Flow_Specification_Class object
   class the "PDR" functionality can identify the RSVPv2-NSLP path





Westberg, et al.          Expires October 2003                 [Page 67]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   state.  The RSVPv2-NSLP "PDR" functionality of the NF(ingress) node
   will generate a refresh request PHR object denoted as
   "PHR_Refresh_Update" and a refresh request PDR object denoted as
   "PDR_Refresh_Request", (see Section 5.2.2).  The PDR object MAY
   contain information such as the IP address of the NF(ingress) node
   and the per-flow specification ID.  These PHR and PDR objects are
   locally defined objects which are included into the Service_Class
   object class carried by the NslpPathRef message.

   The refresh NTLP PATH message is processed by all NTLP stateless
   NF(interior) nodes that is passing through, up to the NF (egress).
   Each node that processes the refresh NTLP PATH message it will
   refresh the NTLP state associated with the session ID, i.e.,
   information included into the Session_ID_Class object class.  The
   NTLP level functionality of the NTLP stateless NF(interior) nodes
   receiving the refresh NTLP PATH message will activate the RSVPv2-NSLP
   "PHR" functionality.

   The RSVPv2-NSLP "PHR" functionality of these NF(interior) nodes will
   use the information included in the PHR object
   ("PHR_Refresh_Request") and it will identify the ID of the traffic
   class, e.g., Diffserv class. This object will refresh the requested
   resources included in the "PHR_Refresh_Update" object.

   The NF(egress) node that processes the refresh NTLP PATH message it
   will refresh the NTLP state associated with the session ID included
   into the Session_ID_Class object class. Furthermore, it will activate
   the RSVPv2-NSLP "PHR" functionality by using the transported
   RSVPv2-NSLP "PHR" object.

   The behavior of the RSVPv2-NSLP "PHR" functionality in the NF(egress)
   node is similar to the RSVPv2-NSLP "PHR" functionality provided in
   the NF(interior) nodes.

   Subsequently, the refresh NTLP PATH  message is forwarded towards the
   NR (receiver), and it will be processed by all NTLP stateful nodes
   that is passing through as an inter-domain signaling procedure, see
   Section 6.  Note that this refresh NTLP PATH message will not include
   the "PDR/PHR" objects.

   When the NF(responder) receives the refresh NTLP PATH message, it
   will refresh the NTLP state and it will invoke the RSVPv2-NSLP "e2e
   service" functionality.

   If a NTLP state in a NTLP stateful is not refreshed on time then the





Westberg, et al.          Expires October 2003                 [Page 68]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NTLP functionality at this node informs the RSVPv2-NSLP state that
   the refresh procedure is unsuccessful.

   Note that the refresh NTLP PATH message may optionally carry a
   NSLPPathRef message.  NR (receiver) will create a NTLP RESV message
   that will be sent towards the NI (sender). This message will be used
   to report information related to how the NTLP PATH message has been
   processed along the path.  Note that the refresh NTLP RESV message
   may optionally carry a NSLPResvRef message. Note that this message is
   processed in a domain only by the NF(egress) and NF(ingress) nodes.
   The NF(interior) nodes are not processing this message.  Moreover,
   the RSVPv2-NSLP "PDR" functionality of the NF(egress) node will
   report the successful refresh PDR/PHR procedure to the RSVPv2-NSLP
   "PDR" functionality of the NF(ingress) node by using a
   "PDR_Refresh_Report" PDR object.  This object will be included into
   the Service_Class object class of the NslpResvRef message.


































Westberg, et al.          Expires October 2003                 [Page 69]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)     NF (interior)          NF (interior)     NF (egress)
NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
    |                    |                    |                    |
PATH(NslpPathInit)       |                    |                    |
--->|PATH(NslpPathInit): |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ResReq          |PATH(NslpPathInit): |                    |
    |------------------->|PHR_Resource_Request|                    |
    |                    |PDR_ResReq          |PATH(NslpPathInit): |
    |                    |------------------->|PHR_Resource_Request|
    |                    |                    |PDR_ResReq          |
    |                    |                    |------------------->|
    |                    |                    |         PATH(NslpPathInit)
    |                    |                    |                    |----->
    |                    |                    |         RESV(NslpResvInit)
    |                    |                    |                    |<------
    |                    |RESV (NslpResvInit) |                    |
    |                    |PDR_Reservation_Report                   |
    |<-------------------------------------------------------------|
RESV(NslpResvInit)       |                    |                    |
<---|                    |                    |                    |
    |                    | Traffic(user) Data |                    |
--->|------------------->|------------------->|------------------->|--->
    |                    |                    |                    |
PATH([NslpPathRef])      |                    |                    |
--->|                    |                    |                    |
    PATH(NslpPathRef):   |                    |                    |
    |PHR_Refresh_Update  |                    |                    |
    |PDR_RefReq          |PATH(NslpPathRef):  |                    |
    |------------------->|PHR_Refresh_Update  |                    |
    |                    |PDR_RefReq          |PATH(NslpPathRef):
    |                    |------------------->|PHR_Refresh_Update  |
    |                    |                    |PDR_RefReq          |
    |                    |                    |------------------->|
    |                    |                    |         PATH([NslpPathRef])
    |                    |                    |                    |----->
    |                    |                    |         RESV([NslpResvRef])
    |                    |                    |                    |<------
    |                    |RESV(NslpResvRef):  |                    |
    |                    |PDR_Refresh_Report  |                    |
    |<-------------------------------------------------------------|
RESV ([NslpResvRef])     |                    |                    |
<---|                    |                    |                    |
   (PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
                   This PDR object is processed only by the





Westberg, et al.          Expires October 2003                 [Page 70]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                   NF(ingress) and NF(egress) nodes.

   (PDR_RefReq) - represents the PDR_Refresh_Request PDR object
                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.

         Figure 10: Intra-domain signaling normal operation for successful
                     reservation

   Figure 11 depicts the intra-domain RSVPv2-NSLP tearing down
   procedure.  A NTLP PATHTEAR message, is received by the NTLP
   functionality in the NF(ingress) node. Note that the NTLP PATHTEAR
   message may optionally carry a NSLPPathTear message.  The NTLP
   functionality activates the RSVPv2-NSLP "PDR/PHR" functionality, that
   is related to the Session_ID_Class class object, and that is using
   the "PDR" object.  The RSVPv2-NSLP "PDR" functionality of the
   NF(ingress) node will generate a release request "PHR" object denoted
   as "PHR_Release_Request" and a release request PDR object denoted as
   "PDR_Release_Request", (see Section 5.2.2).  The PDR object may
   contain information such as the IP address of the NF(ingress) node
   and the per-flow specification ID.

   These PHR and PDR objects are locally defined objects which are
   included into the Service_Class object class carried by a
   NslpPathTear message.  All the RSVPv2-NSLP and NTLP reservations, in
   the NF(ingress) node that are associated to the Session_ID_Class
   object class will be released.  The NTLP PATHTEAR message is
   processed by all NTLP stateless NF(interior) nodes that is passing
   through, up to the NF (egress). Each node that processes the PATHTEAR
   message will activate the RSVPv2-NSLP "PHR" functionality by using
   the transported RSVPv2-NSLP "PHR" object.  The NTLP functionality in
   the NTLP stateless NF(interior) node that receives the PATHTEAR
   message will pass the NslpPathTear message to the RSVPv2-NSLP
   functionality. The NslpPathTear message contains the
   "PHR_Release_Request" and "PDR_Release_Request" PHR and PDR objects,
   respectively.

   The RSVPv2-NSLP "PHR" functionality of this NF(interior) node will
   use the information included in the PHR object
   ("PHR_Release_Request") and it will identify the ID of the traffic
   class, e.g., Diffserv class. This object will subtract the requested
   resources included in the "PHR_Release_Request" object from the total
   reserved amount of resources stored in the traffic class state.

   The NF(egress) node that processes the PATHTEAR message it will it





Westberg, et al.          Expires October 2003                 [Page 71]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   will activate the RSVPv2-NSLP "PHR" functionality by using the
   transported "PHR" object.

   The behavior of the RSVPv2-NSLP "PHR" functionality in the NF(egress)
   node is similar to the RSVPv2-NSLP "PHR" functionality provided in
   the NF(interior) nodes. Furthermore, the NTLP state is released and
   the PATHTEAR message is forwarded towards the NR (receiver), and it
   will be processed by all NTLP stateful nodes that is passing through
   as an inter-domain signaling procedure, see Section 6.  Note that
   this PATHTEAR message will not include the "PDR/PHR" objects.

NF (ingress)     NF (interior)          NF (interior)     NF (egress)
  NTLP stateful  NTLP stateless         NTLP stateless    NTLP stateful
   |                    |                    |                    |
   |                    | Traffic(user) Data |                    |
-->|------------------->|------------------->|------------------->|--->
   |                    |                    |                    |
PATHTEAR([NslpPathTear])|                    |                    |
-->|                    |                    |                    |
   PATHTEAR(NslpPathTear):                   |                    |
   |PHR_Release_Request |                    |                    |
   |PDR_RelReq          |PATHTEAR(NslpPathTear):                  |
   |------------------->|PHR_Release_Request                      |
   |                    |PDR_RelReq   PATHTEAR(NslpPathTear):
   |                    |------------------->|PHR_Release_Request |
   |                    |                    |PDR_RelReq          |
   |                    |                    |------------------->|
   |                    |                    |     PATHTEAR([NslpPathTear])
   |                    |                    |                    |----->

   (PDR_RelReq) - represents the PDR_Release_Request object. This object is
                   processed only by the NF(ingress) and NF(egress) nodes.


     Figure 11: Intra-domain signaling normal operation for explicit release

   Figure 12 shows the main intra-domain flow diagram used by the
   RSVPv2-NSLP protocol in case of an unsuccessful reservation. In this
   situation only the uni-directional feature is considered.  In this
   situation the RSVPv2-NSLP and NTLP messages are created and
   transmitted in the same way as during the successful reservation.
   The main difference is related to the fact that one of the NTLP
   stateless NF(interior) is not able to satisfy the request carried by
   the "PHR_Resource_Request" PHR object. The RSVPv2-NSLP "PHR"
   functionality of this NF(interior) node will mark the "M" field of





Westberg, et al.          Expires October 2003                 [Page 72]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   the "PHR_Resource_Request" object.  The RSVPv2-NSLP "PHR"
   functionality will also include the number of previous NF(interior)
   nodes that successfully processed the RSVPv2-NSLP
   "PHR_Resource_Request" PHR object (see Appendix).  This number can,
   for example, be identified by the TTL (Time-To-Live) value included
   in the IP header of the received NTLP PATH message.  Note that each
   time that an IP packet passes a node, its TTL value is decreased by
   one.  Furthermore, note that the NF(ingress) node should temporarily
   store the TTL value included in the IP header of any message in the
   PDR state associated to the NTLP PATH message.  In case of an
   unsuccessful reservation, this information, that we denote as
   PDR_TTT_I will be used in combination with the value included in the
   PDR_TTL field (see Appendix) of a receiving "PDR" reporting object.
   The PDR_TTL field is generated and sent by a NF(interior) node that
   could not successfully process the "PHR" object, e.g., admit the
   requested "PHR" reservation.  The NF(Ingress) node using this
   information can calculate how many NF(interior) nodes, before the
   NF(interior) node, rejected the "PHR_Resource_Request" object.

   In particular, the NF(interior) node that is not admitting the
   reservation request initiated by the "PHR_Resource_Request" PHR
   object will copy the TTL value included in the IP header of the
   received NTLP PATH message that carries the "PHR_Resource_Request"
   object into the "PDR_TTL" field of "PDR_Reservation_Request" PDR
   object. Moreover, the "T" field of the "PHR" object (see Appendix) is
   set to "1". These "PHR" and "PDR" objects are included in the
   NslpPathInit message.  The NslpPathInit message is encapsulated into
   a NTLP PATH message.

   This NslpPathInit message is sent towards the NF(egress) node, which
   will be transported by a NTLP PATH message. Any NF(interior) node
   receiving a PATH message will activate the RSVPv2-NSLP "PHR"
   functionality. If the "PHR_Resource_Request" PHR object is "M"
   marked, then the RSVPv2-NSLP "PHR" functionality will not further
   process the "PHR" object.  The NF(egress) node receiving a NTLP PATH
   message will activate the RSVPv2-NSLP "PHR" functionality. If the
   "PHR_Resource_Request" PHR object is "M" marked, then the RSVPv2-NSLP
   "PHR" functionality will activate the RSVPv2-NSLP "PDR" functionality
   which will create and "M" mark the "PDR_Reservation_Report" object.
   Moreover, if the "T" field value included in the "PHR" object is "1"
   then the PDR_TTL value that was included by the NF(interior) node
   into the "PDR_Reservation_Request" object will be copied into the
   PDR_TTL value of the "PDR_Reservation_Report" object.  The "PDR"
   object will be included in an NslpPathErr message.  The NslpPathErr
   message will be encapsulated into a NTLP PATHERROR message.  The





Westberg, et al.          Expires October 2003                 [Page 73]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NslpPathError message will only be processed by the NF(ingress) node.
   The NTLP functionality of the NF(ingress) node that receives the
   PATHERROR message will activate the RSVPv2-NSLP "PDR" functionality.
   Due to the "M" marked "PDR_Reservation_Report" object the "PDR"
   functionality will activate the RSVPv2-NSLP "e2e service".  The
   RSVPv2-NSLP "e2e service" functionality of the NF(ingress) node will
   generate a NslpPathErr message that will be sent hop-by-hop to the
   NI(sender) and will be encapsulated into a NTLP PATHERROR message.
   This message will inform the NI(sender) that the reservation request
   was not successful.

   Simultaneously, the NF(ingress) node will start a partial explicit
   release procedure, for releasing the unnecessarily reserved RSVP-NSLP
   resources in some interior nodes for the rejected flow.  In this
   case, the RSVP-NSLP "PDR" functionality of the NF(ingress) node will
   generate a "PHR_Release_Request" object, and it will include the
   amount of the requested resources specified the PDR state.  Moreover,
   the RSVPv2-NSLP "PDR" functionality will create the
   "PDR_Reservation_Request" PDR object.

   The RSVPv2-NSLP "PDR" functionality of the NF(ingress) node can
   calculate the number of NF(interior) nodes that processed and
   reserved RSVPv2-NSLP resources.

   This number can be calculated by subtracting the value included in
   the PDR_TTL field that was included in the received
   "PDR_Reservation_Report" PDR object from the value included in the
   PDR_TTL_I variable that has been stored into the RSVPv2-NSLP state.
   This calculated value will be included in the TTL - IP header field
   of the NTLP PATHTEAR message which is generated by the NF(ingress)
   node and which transports the "PHR_Resource_Release" object. The
   "PHR_Release_Request" and "PDR_Release_Request" objects are included
   into a NslpPathTear message. The NslpPathTear message is transported
   by a NTLP PATHTEAR message.

   The RSVPv2-NSLP "PHR" functionality of any node that receives a
   "PHR_Resource_Release" object must identify the traffic class, e.g.,
   DSCP and release the requested resources associated with it.  This
   can be achieved by e.g., subtracting the amount of requested
   resources, included in the "PHR_Release_Request" object, from the
   total reserved amount of resources stored in the traffic class state.
   Moreover, its TTL value of the NTLP PATHTEAR message is decremented
   by one.  When this value becomes zero, the "PHR_Resource_Release"
   object reached the interior node that marked the
   "PHR_Resource_Request" object and it will be dropped. This means that





Westberg, et al.          Expires October 2003                 [Page 74]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   this PHR object will not release any resources in this node.

NF (ingress)     NF (interior)         NF (interior)       NF (egress)
NTLP stateful    NTLP stateless        NTLP stateless    NTLP stateful
    |                    |                    |                    |
PATH(NslpPathInit)       |                    |                    |
--->|PATH(NslpPathInit): |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ResReq          |PATH(NslpPathInit): |                    |
    |------------------->|PHR_Resource_Request|                    |
    |                    |PDR_ResReq          |PATH(NslpPathInit): |
    |                    |------------------->M PHR_Resource_Request (M
    |                    |                    M            marked)
    |                    |                    M PDR_ResReq         |
    |                    |                    M------------------->|
    |                    |PATHERROR(NslpPathErr):                  |
    |                    |PDR_Reservation_Report                   |
    |<-------------------------------------------------------------|
PATHERROR(NslpPathErr)   |                    |                    |
<---|                    |                    |                    |
    |PATHTEAR(NslpPathTear):                  |                    |
    |PHR_Resource_Release|                    |                    |
    |PDR_RelReq          |                    |                    |
    |------------------->|                    |                    |

   (PDR_ResReq*) - represents the "PDR_Reservation_Request" PDR object.
                   This PDR object is processed only by the
                   NF(ingress) and NF(egress) nodes.

   (PDR_RelReq*) - represents the PDR_Release_Request object. This object is
                   processed only by the NF(ingress) and NF(egress) nodes.

        Figure 12: Intra-domain signaling normal operation for unsuccessful
                     reservation

   Figure 11 and Figure 12 show the intra-domain main flow diagram used
   by the RSVPv2-NSLP protocol for a  modification of a reservation
   procedure.  In this situation only the uni-directional feature is
   considered.

   The request for modification of the reservation is included into the
   NslpPathMod message.  A NTLP PATH message that encapsulates the
   NslpPathMod message is received by the NTLP functionality of the
   NF(ingress) node. The NTLP functionality activates the RSVP-NSLP
   "PDR/PHR" functionality, which is associated with the





Westberg, et al.          Expires October 2003                 [Page 75]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Session_ID_Class object class.  When the modification request
   requires an increase on the number of reserved resources stored in
   the RSVPv2-NSLP state (see Figure 13), then the RSVPv2-NSLP "PHR"
   functionality of the NF(ingress) node will have to subtract the old
   and already reserved number of resources from the number of resources
   included in the new modification request.  The result of this
   subtraction should be introduced within a "PHR_Resource_Request" PHR
   object as the requested resources value.  Furthermore, the number of
   resources that were reserved for a certain flow in the RSVPv2-NSLP
   state should also be replaced with the number of resources included
   in the modification request.

   The RSVPv2-NSLP "PDR" functionality will create a
   "PDR_Modification_Request" PDR object. These two objects will be
   included into the Service_Class of the NslpPathMod message.

   The RSVPv2-NSLP "PHR" functionality of each stateless NF(interior)
   node processes the PHR object as a "PHR_Resource_Request" object.
   Each stateless NF(interior) node that receives the modification NTLP
   PATH message will activate the RSVPv2-NSLP "PHR" functionality.  If a
   RSVPv2-NSLP "PHR" functionality of any node is not able to reserve
   the number of requested resources, then the "PHR_Resource_Request"
   PHR object will be marked. In this situation the RSVPv2-NSLP PHR and
   PDR protocol functionality associated with an unsuccessful
   reservation procedure will be applied for this case (see Figure 12).

   The behavior of the NF(egress) node related to the modification
   procedure is the same as in the NF(interior) nodes.  After processing
   the "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of
   the NF(egress) node uses the "PDR_Modification_Request" object and
   identifies the flow specification ID and the RSVPv2-NSLP state
   associated with it.  Subsequently, the RSVPv2-NSLP "e2e service"
   functionality is activated and by using the information contained in
   the Flow_Specification_Class it will modify the reservation stored
   into the RSVPv2-NSLP path state.

   The NTLP PATH message is forwarded towards the NR (receiver), and it
   will be processed by all NTLP stateful nodes that is passing through
   as an inter-domain signaling procedure, see Section 6.  Note that
   this NTLP PATH message will not include the "PDR/PHR" object
   information.


   When the NR(receiver) receives the NTLP PATH message, similar to the
   procedure used in Section 6, it will create a it will activate the





Westberg, et al.          Expires October 2003                 [Page 76]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   RSVPv2-NSLP "e2e service" functionality by using the NslpPathMod
   message. By using the information contained in the
   Flow_Specification_Class it will modify the reservation stored into
   the RSVPv2-NSLP path state.

   Subsequently the RSVPv2-NSLP "e2e service" functionality will create
   an NslpResvMod message that will be used to report information
   related to how the NslpPathMod has been processed along the path.
   This NslpResvMod will be encapsulated into a RESV message and it will
   only be processed by the RSVPv2-NSLP "e2e service" functionality at
   each hop that is passing by and that is supporting the "e2e service"
   functionality. Note that this message is processed in a domain only
   by the NF(egress) and NF(ingress) nodes. The NF(interior) nodes are
   not processing this message.  Moreover, the RSVPv2-NSLP "PDR"
   functionality of the NF(egress) node will report the successful
   reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
   node by using a "PDR_Modification_Report" PDR object.  This object
   will be included into the Service_Class object class of the
   NslpResvMod message.































Westberg, et al.          Expires October 2003                 [Page 77]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)    NF (interior)          NF (interior)        NF (egress)
NTLP stateful   NTLP stateless         NTLP stateless       NTLP stateful
    |                    |                    |                    |
PATH(NslpPathMod)        |                    |                    |
--->|PATH(NslpPathMod):  |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ModReq          |PATH(NslpPathMod):  |                    |
    |------------------->|PHR_Resource_Request|                    |
    |                    |PDR_ModReq          |PATH(NslpPathMod): |
    |                    |------------------->|PHR_Resource_Request|
    |                    |                    |PDR_ModReq          |
    |                    |                    |------------------->|
    |                    |                    |         PATH(NslpPathMod)
    |                    |                    |                    |----->
    |                    |                    |         RESV(NslpResvMod)
    |                    |                    |                    |<------
    |                    |RESV (NslpResvMod)  |                    |
    |                    |PDR_Modification_Report                  |
    |<-------------------------------------------------------------|
RESV(NslpResvMod)        |                    |                    |
<---|                    |                    |                    |


   (PDR_ModReq*) - represents the "PDR_Modification_Request" PDR object.
                   This PDR object is processed only by the
                   NF(ingress) and NF(egress) nodes.


       Figure 13: Intra-domain signaling normal operation for modification of
                     reservation when new number of resources is higher
                     than number of already reserved resources


   When the modification request requires a decrease on the number of
   reserved resources stored in the RSVPv2-NSLP path state (see Figure
   14), then the RSVPv2-NSLP "PHR" functionality of the NF(ingress) node
   will have to subtract the number of resources included in the new
   modification request from the old and already reserved number of
   resources.  The result of this subtraction should be introduced in an
   RSVPv2-NSLP "PHR_Release_Request" PHR object.  Furthermore, the
   number of resources that were reserved in the RSVPv2-NSLP path state
   for a certain flow should also be replaced with the number of
   resources included in the modification request.  The RSVPv2-NSLP
   "PDR" functionality will create a "PDR_Modification_Request" PDR
   object. These two objects will be encapsulated into a modification





Westberg, et al.          Expires October 2003                 [Page 78]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   NTLP PATH message. This message will be sent towards the NF(egress)
   node. The RSVPv2-NSLP "PHR" functionality of each NF node processes
   the PHR object as a "PHR_Resource_Release" object. Each NF(interior)
   node that receives the modification NTLP PATH message will activate
   the RSVPv2-NSLP "PHR" functionality. The RSVPv2-NSLP "PHR"
   functionality of these NF(interior) nodes will use the information
   included in the PHR object ("PHR_Release_Request") and it will
   identify the ID of the traffic class, e.g., Diffserv class. This
   object will subtract the requested resources included in the
   "PHR_Release_Request" object from the total reserved amount of
   resources stored in the traffic class state.

   The behavior of the NF(egress) node related to the modification
   procedure is the same as in the NF(interior) nodes.  After processing
   the "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of
   the NF(egress) node uses the "PDR_Modification_Request" object and
   identifies the flow specification ID and the RSVPv2-NSLP state
   associated with it.  Subsequently, the RSVPv2-NSLP "e2e service"
   functionality is activated and by using the information contained in
   the Flow_Specification_Class, it will modify the reservation stored
   into the RSVPv2-NSLP path state.

   The rest part of the modification procedure depicted in Figure 14 is
   identical to the one described earlier and depicted in Figure 13.


























Westberg, et al.          Expires October 2003                 [Page 79]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)    NF (interior)          NF (interior)        NF (egress)
NTLP stateful   NTLP stateless         NTLP stateless       NTLP stateful
    |                    |                    |                    |
PATH(NslpPathMod)        |                    |                    |
--->|PATH(NslpPathMod):  |                    |                    |
    |PHR_Resource_Release|                    |                    |
    |PDR_ModReq          |PATH(NslpPathMod):  |                    |
    |------------------->|PHR_Resource_Release|                    |
    |                    |PDR_ModReq          |PATH(NslpPathMod):  |
    |                    |------------------->|PHR_Resource_Release|
    |                    |                    |PDR_ModReq          |
    |                    |                    |------------------->|
    |                    |                    |         PATH(NslpPathMod)
    |                    |                    |                    |----->
    |                    |                    |         RESV(NslpResvMod)
    |                    |                    |                    |<------
    |                    |RESV (NslpResvMod)  |                    |
    |                    |PDR_Modification_Report                  |
    |<-------------------------------------------------------------|
RESV(NslpResvMod)        |                    |                    |
<---|                    |                    |                    |



   (PDR_ModReq*) - represents the PDR_Modification_Request object. This
                   object is processed only by the NF(ingress) and NF(egress)
                   nodes.

        Figure 14: Modification of reserved resources when new number of
        resources is lower than number of already reserved resources




7.2.  Example of Fault Handling Operation

   Fault Handling Operation refers to the situations when there are
   errors in the network, such as loss of NTLP messages route change,
   link failure, etc. Two typical situations will be described: the loss
   of the PHR signalling messages and severe congestion.  The fault
   handling operation described here is in general independent from the
   type of the example scenarios, thus it can be applied in both cases.








Westberg, et al.          Expires October 2003                 [Page 80]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






7.2.1.  Loss of NTLP signalling messages

   The NTLP signaling messages and subsequently the "PHR" and "PDR"
   objects might be dropped, for example due to route or link failure.
   The loss of the "PHR" objects is especially problematic for the
   reservation-based "PHR" concept, see e.g., [RODA], since the dropped
   signalling messages might have reserved resources in some
   NF(interior) nodes in the communication path that will now not be
   used.  This does not present a problem for the measurement-based
   "PHR" concept, see e.g., [RIMA], since there are no reservation
   states. The "PHR" objects that need to be sent reliable are:
     PHR_Resource_Request
     PHR_Refresh_Update

   The reliable delivery of the "PHR_Resource_Request" object is
   provided by using the functionality provided by the RSVPv2-NSLP "PDR"
   functionality located in the NF(ingress) node.  The RSVPv2-NSLP "PDR"
   functionality of the NF(ingress) node sends the
   "PHR_Resource_Request" object towards the NF(egress) node and it
   starts a timer. If the reply, e.g., "PDR_Reservation_Report" object,
   does not arrive in a predefined time it assumes that the
   "PHR_Resource_Request" object is lost.  The reliable deliver of the
   "PHR_Refresh_Update" object is provided in a similar way. A timer at
   the NF(ingress) node is started when the "PHR_Refresh_Update" is sent
   towards the NF(egress) node. If the reply, e.g., "PDR_Refresh_Report"
   object, does not arrive in a predefined time it assumes that the
   "PHR_Refresh_Update" object is lost.



7.2.2.  Severe Congestion Handling operation

   Severe congestion can be detected by any NF(interior) node by using
   different methods. Moreover, the severe congestion situation can be
   notified by any NF(interior) node to NF(egress) nodes by using three
   approaches, i.e., "Greedy Marking", "Proportional Marking" and "PHR
   message marking". The "PHR message marking" can only be applied on
   the reservation-based "PHR" concept, while the other two methods can
   be applied on both "PHR" concept types.

   In this section the "Proportional Marking" severe congestion
   notification methods is used.








Westberg, et al.          Expires October 2003                 [Page 81]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






7.2.2.1.  Proportional marking

   Using this severe congestion notification method, after detecting the
   severe congestion situation, the NF(interior) node will notify the
   NF(egress) node by using remarking of user data packets that pass
   through the node (see Figure 15). Proportionally to the detected
   overload the NF(interior) node will remark a number of user data
   packets which are passing through a severe congested interior node
   and are associated with a certain traffic class, e.g., DSCP, into a
   domain specific DSCP.

   When the marked packets arrive at the NF(egress) node, the NF(egress)
   node will generate a "PDR_Congestion_Report" object and send it to
   the NF(ingress) node containing the over-allocation volume of the
   flow in question, e.g., a blocking probability. The
   "PDR_Congestion_Report" PDR object should be included into a
   NslpPathErr and transported by a NTLP PATHERROR message.  For each
   flow ID, the RSVPv2-NSLP PDR functionality at the NF(egress) node
   will count the number of marked bytes (# marked bytes) and the number
   of unmarked bytes (#unmarked bytes).

   Based on this information the RSVPv2-NSLP PDR functionality at the
   NF(egress) node will have to calculate the blocking estimation of
   data. The NF(egress) node will actually calculate the blocking
   probability (Pdrop), which will be used by an NF(ingress) node to
   block this particular flow.

   The blocking probability is calculated as the ratio between the
   dropped bytes and the maximum number of bytes that can be supported
   by the interior node:

   Pdrop = (# marked bytes)/(# marked bytes + # unmarked bytes)

   This blocking probability will be included in the
   "PDR_Congestion_Report" object that will be sent to the NF(ingress).

   The RSVPv2-NSLP PDR functionality of the NF(ingress) node after
   receiving the PDR_Congestion_Report object and based on the Pdrop
   blocking probability, and depending on the used policy, might
   terminate the flow, i.e., for a higher blocking probability there is
   a higher chance that the flow is terminated.

   If a flow needs to be terminated, then for this flow, the ingress
   node will generate a "PHR_Release_Request" object that will be
   included into the Service_Class of the NslpPathTear message.  This





Westberg, et al.          Expires October 2003                 [Page 82]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   message will be transported by a NTLP PATHTEAR message towards the
   NF(egress).  Furthermore, the RSVPv2-NSLP "e2e service" functionality
   in the NF(ingress) node will create a NslpPathErr that will be
   encapsulated into a PathError that will be sent towards the
   NI(sender) to notify that an error occured.


NF (ingress)   NF (interior)          NF (interior)      NF (egress)
NTLP stateful  NTLP stateless        NTLP stateless     NTLP stateful
(sent)
 user|(sent) user data   |                    |                    |
 data|                   |                    |                    |
---->|------------------>| (sent) user data   |  user data         |
     |                   |------------------->S(# marked bytes)    |
     |                   |                    S------------------->|
     |                   |                    S(# unmarked bytes)  |
     |                   |                    S------------------->|
     |                   |PATHERROR(NslpPathErr):                  |
     |                  PDR_Congestion_Report ("S" marked + Pdrop) |
     |<------------------|--------------------|--------------------|
Terminate                |                    |                    |
flow?|                   |                    |                    |
Yes PATHTEAR(NslpPathTear):                   |                    |
     |PHR_Release_Request|                    |                    |
     |PDR_RelReq         |PATHTEAR(NslpPathTear):                  |
     |------------------>|PHR_Release_Request                      |
     |                   |PDR_RelReq          | PATHTEAR(NslpPathTear):
     |                   |------------------->|PHR_Release_Request |
     |                   |                    |PDR_RelReq          |
     |                   |                    |------------------->|
     |                   |                    |                    |
     |                   |                    |                    |
PathErr(NslpPathErr)     |                    |                    |
<----|                   |                    |                    |

 Figure 15: Intra-domain Severe Congestion handling Operation:
            with proportional marking

(PDR_RelReq*) - represents the PDR_Release_Request object. This object is
                processed only by the NF(ingress) and NF(egress) nodes.










Westberg, et al.          Expires October 2003                 [Page 83]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






7.3.  Example of Adaptation to load sharing operation
   This procedure has to be based on the solutions provided by the NTLP
   protocol level on this issue. These NTLP protocol level solutions are
   not yet defined. Therefore, this procedure will be specified in a
   future version of this draft.


7.4.  Normal operation for bi-directional reservation

   There are situations where, for example, the inter-domain signaling
   has to support in addition to the unidirectional reservations also
   bi-directional reservations. This section gives one example of inter-
   domain signaling for a successful and one example of inter-domain
   signaling for an unsuccessful bi-directional reservation.


   Figure 16 shows the flow diagram of intra-domain signaling used by
   the RSVPv2-NSLP protocol and the way how the RSVPv2-NSLP inter-domain
   and intra-domain signaling inter-operates in case of a successful bi-
   directional reservation.

   The bi-directional successful reservation is similar to a combination
   of two unidirectional successful reservations that are accomplished
   in opposite directions.  The main differences of the bi-directional
   successful reservation procedure with the combination of two
   unidirectional successful reservations accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the success of the reservation procedure is reported to the NI(sender)
       using the NslpPathInit that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathRef that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the success of the refresh procedure is reported to the NI(sender)
       using the NslpPathMod that is sent hop-by-hop from NR(receiver)
       towards the NI(sender)
     * the PDR_Reservation_Report object used to report a successful
       reservation procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)





Westberg, et al.          Expires October 2003                 [Page 84]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






     * the PDR_Refresh_Report object used to report a successful refresh
       procedure is carried by the NslpPathInit that is sent hop-by-hop
       from NF(egress) towards the NF(ingress)
     * the PDR_Modification_Report object used to report a successful
       modification procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
    *  the NF(egress) node can initiate an explicit partial release
       procedure towards the NF(ingress) node.



   Figure 17 and Figure 18 show the flow diagrams of intra-domain
   signaling used by the RSVPv2-NSLP protocol and the way how the
   RSVPv2-NSLP inter-domain and intra-domain signaling inter-operates in
   case of a unsuccessful bi-directional reservation.

   The bi-directional unsuccessful reservation is similar to a
   combination of two unidirectional unsuccessful reservations that are
   accomplished in opposite directions.  The main differences of the bi-
   directional unsuccessful procedure with the combination of two
   unidirectional successful reservations accomplished in opposite
   directions are as follows:

     * the reservation state specifies a bi-directional reservation
     * the Service_Class object specifies that the reservation is
       bi-directional
     * the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
       NslpResvMod messages
     * the PDR_Reservation_Report object used to report a successful
       reservation procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
     * the PDR_Refresh_Report object used to report a successful refresh
       procedure is carried by the NslpPathInit that is sent hop-by-hop
       from NF(egress) towards the NF(ingress)
     * the PDR_Modification_Report object used to report a successful
       modification procedure is carried by the NslpPathInit that is sent
       hop-by-hop from NF(egress) towards the NF(ingress)
    *  the NF(egress) node can initiate an explicit partial release
       procedure towards the NF(ingress) node.











Westberg, et al.          Expires October 2003                 [Page 85]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)     NF (interior)          NF (interior)     NF (egress)
NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
    |                    |                    |                    |
PATH(NslpPathInit)       |                    |                    |
--->|                    |                    |                    |
    |PATH(NslpPathInit): |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ResReq          |      PATH(NslpPathInit):                |
    |------------------->|      PHR_Resource_Request               |
    |                    |      PDR_ResReq    |                    |
    |                    |---------------------------------------->|
    |                    |                    |           PATH(NslpPathInit)
    |                    |                    |                    |-->
    |                    |           PATH(NslpPathInit):           |
    |                    |             PDR_Reservation_Report      |
    |                    |             PHR_Resource_Request PATH(NslpPathInit)
    |        PATH(NslpPathInit):       PDR_ResReq                  |<---
    |        PDR_Reservation_Report           |                    |
    |        PHR_Resource_Request             |<-------------------|
    |        PDR_ResReq  |                    |                    |
    |<----------------------------------------|                    |
    |                    |                    |                    |
    |                    |                    |                    |
    |                    | Traffic(user) Data |                    |
 ---|------------------->|---------------------------------------->|--->
    |                    | Traffic(user) Data |                    |
 <--|<----------------------------------------|<-------------------|----
    |                    |                    |                    |
  PATH(NslpPathRef)      |                    |                    |
--->|                    |                    |                    |
    |PATH([NslpPathRef]):|                    |                    |
    |PHR_Refresh_Update  |                    |                    |
    |PDR_Refreq          |           PATH([NslpPathRef]):          |
    |------------------->|           PHR_Refresh_Update            |
    |                    |           PDR_Refreq                    |
    |                    |---------------------------------------->|
    |                    |                    |     PATH([NslpPathRef])
    |                    |            PATH([NslpPathRef]):         |--->
    |                    |               PDR_Refresh_Report        |
    |                    |               PHR_Refresh_Update PATH([NslpPathRef])
    |                    |               PDR_Refreq                |<---
    |           PATH([NslpPathRef]):          |<-------------------|
    |           PHR_Refresh_Report            |                    |
    |           PHR_Resource_Request          |                    |
    |           PDR_ResReq                    |                    |





Westberg, et al.          Expires October 2003                 [Page 86]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    |<----------------------------------------|                    |
 PATH([NslpPathRef])     |                    |                    |
 <--|                    |                    |                    |

   (PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
                   This PDR object is processed only by the
                   NF(ingress) and NF(egress) nodes.

   (PDR_RefReq) - represents the PDR_Refresh_Request PDR object
                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.

         Figure 16: Intra-domain signaling normal operation for successful
                    bi-directional reservation




































Westberg, et al.          Expires October 2003                 [Page 87]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)     NF (interior)          NF (interior)     NF (egress)
NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
    |                    |                    |                    |
PATH(NslpPathInit)       |                    |                    |
--->|                    |                    |                    |
    |PATH(NslpPathInit): |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ResReq          |      PATH(NslpPathInit):                |
    |------------------->M      PHR_Resource_Request               |
    |                    M      PDR_ResReq    |                    |
    |                    M---------------------------------------->|
    |  PATHERROR(NslpPathErr):                |                    |
    |   PDR_Reservation_Report                |                    |
    |<-------------------------------------------------------------|
PATHERROR(NslpPathErr)   M                    |                    |
 <--|                    M                    |                    |
    |PATHTEAR(NslpPathTear):                  |                    |
    |PHR_Release_Request M                    |                    |
    |PDR_RelReq          M                    |                    |
    |------------------->M                    |                    |
   (PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
                   This PDR object is processed only by the
                   NF(ingress) and NF(egress) nodes.

   (PDR_RefReq) - represents the PDR_Refresh_Request PDR object
                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.
   (PDR_RelReq) - represents the PDR_Release_Request PDR object
                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.

         Figure 17: Intra-domain signaling normal operation for unsuccessful
                    bi-directional reservation (rejection on path NF(ingress)
                    towards NF(egress))
















Westberg, et al.          Expires October 2003                 [Page 88]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






NF (ingress)     NF (interior)          NF (interior)     NF (egress)
NTLP stateful    NTLP stateless         NTLP stateless    NTLP stateful
    |                    |                    |                    |
PATH(NslpPathInit)       |                    |                    |
--->|                    |                    |                    |
    |PATH(NslpPathInit): |                    |                    |
    |PHR_Resource_Request|                    |                    |
    |PDR_ResReq          |      PATH(NslpPathInit):                |
    |------------------->|      PHR_Resource_Request               |
    |                    |      PDR_ResReq    |                    |
    |                    |---------------------------------------->|
    |                    |                    |           PATH(NslpPathInit)
    |                    |                    |                    |-->
    |                    |           PATH(NslpPathInit):           |
    |                    |             PHR_Reservation_Report      |
    |        PATH(NslpPathInit):       PHR_Resource_Request PATH(NslpPathInit)
    |        PDR_Reservation_Report     PDR_ResReq                  |<---
    |        PHR_Resource_Request             M<-------------------|
    |        PDR_ResReq  |                    M                    |
    |<----------------------------------------M                    |
    |  PATHERROR(NslpPathErr):                M                    |
    |   PDR_Reservation_Report                M                    |
    |------------------------------------------------------------->|
    |                    |                    M           PATHERROR(NslpPathErr)
    |                    |                    M                    |-->
    |                    |                    M           PATHTEAR(NslpPathTear):
    |                    |                    M             PHR_Release_Request
    |                    |                    M             PDR_Relreq
    |                    |                    M<-------------------|
    |  PATHERROR(NslpPathErr):                M                    |
    |   PDR_Reservation_Report                M                    |
    |<-------------------------------------------------------------|
PATHERROR(NslpPathErr)   |                    M                    |
 <--|                    |                    M                    |
    |PATHTEAR(NslpPathTear):                  M                    |
    |PHR_Release_Request |                    M                    |
    |PDR_RelReq          |      PATHTEAR(NslpPathTear):            |
    |------------------->|      PHR_Release_Request                |
    |                    |      PDR_RelReq    M                    |
    |                    |---------------------------------------->|
   (PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
                   This PDR object is processed only by the
                   NF(ingress) and NF(egress) nodes.

   (PDR_RefReq) - represents the PDR_Refresh_Request PDR object





Westberg, et al.          Expires October 2003                 [Page 89]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.
   (PDR_RelReq) - represents the PDR_Release_Request PDR object
                   This PDR object is processed only by the NF(ingress) and
                   NF(egress) nodes.

         Figure 18: Intra-domain signaling normal operation for unsuccessful
                    bi-directional reservation (rejection on path NF(egress)
                    towards NF(ingress))



8.  Appendix  - Examples of PHR and PDR object specifications

   This appendix provides examples of how PHR and PDR objects could be
   specified.


8.1.  PHR objects
   RSVPv2 should support both IP versions, i.e., IPv4 and IPv6.  The
   format of the PHR object that is based on both IPv4 and IPv6 versions
   is depicted in Figure 19.  On top of the PHR specific information of
   the PHR object, the three (standard) RSVPv1 object fields are used,
   i.e., Length, Class-Num and C-type.


    0                                                             31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Length(bytes)          | Class-Num     |   C-Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |        Unused                 |P-LEN| P-ID  |S|M|  C  |T|Unused|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Requested Resources        |   Delta T     |   Shared %     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |                                                                |
   |                                                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

      Figure 19: PHR object format based on IPv4 or IPv6

   Length
   (in octets):    16-bit field containing the total object length in
                   octets. It must always be a multiple of 4 and at least
                   4 octets.






Westberg, et al.          Expires October 2003                 [Page 90]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   Class-Num:      8-bit field identifying the object class. Each object
                   class has a name.

   C-Type:         8-bit field identifying the object type, unique within
                   Class-Num. In this case a C-Type ID should be assigned
                   to the PHR object.

   P-LEN           3-bit field. This specifies the length in
   (PHR length)    octets of the specific PHR information data,
                   without including the "Variable length" field.

                   The value 0 specifies that this IP option
                   field contains only data in the "Variable length"
                   field.
                   This data MUST begin on the next 32-bit word
                   boundary after the P-LEN field (after the first
                   "unused" field).  In this case, the sender MUST
                   set the "S", "M", "C", and "unused" fields to 0.
                   The P-ID MUST have the value 1.

                   If a receiver receives a packet with a P-LEN value
                   of 0, it MUST ignore the values in the "S", "M",
                   "C", and "unused" fields.

   P-ID (PHR type) 4-bit field. This specifies the PHR type.
                   For the RODA PHR, the value MUST be 1.

   S               1-bit field. The sender MUST set the "S"
   (Severe         field to 0. This field is set to 1
   Congestion)     by an NF(interior) or NF(edge) node when a severe
                   congestion situation occurs.

   M               1-bit field. The sender MUST set the "M"
   (Marked)        field to 0. This field is set to 1 by an
                   NF(interior) or NF(edge) node when the node cannot
                   satisfy the "Requested Resources" value.

   C               3-bit field. This field specifies the
   (Object type)  type of the PHR object.

                    C     Description
                   -------------------------------
                    0     Reserved
                    1     "PHR_Resource_Request"
                    2     "PHR_Refresh_Update"





Westberg, et al.          Expires October 2003                 [Page 91]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                    3     "PHR_Release_Request"
                    4-7   Unused

                   "PHR_Resource_Request": initiate or update the
                    traffic class reservation state on all nodes
                    located on the communication path between the
                    NF(ingress) and NF(egress) nodes according to an
                    external SAPU Path request.

                    "PHR_Refresh_Update": refresh the traffic class
                    reservation soft state on all nodes located on
                    the communication path between the NF(ingress) and
                    NF(egress) nodes according to a resource reservation
                    request that was successfully processed by the
                    RSVPv2-NSLP PHR functionality during a previous refresh
                    period.

                    "PHR_Release_Request": explicitly release, by
                    subtraction, the reserved resources for a particular
                    flow from a traffic class reservation state.

   T               1-bit field. The NF(ingress) node MUST set
   (TTL active)    the "T" field to 0. This field MAY be set to "1"
                   by a node when the node will have to include the
                   TTL value from the header of the IP packet into
                   the "PDR_TTL" field of the PDR object.


   U               A 3-bit field that is currently unused.  Reserved for
                   future PHR object extensions.

   Requested       16-bit field. This field specifies the requested
   Resources       number of units of resources to be reserved by
                   a node. The unit is not necessarily a simple
                   bandwidth value.  It may be defined in terms of
                   any resource unit (e.g., effective bandwidth) to
                   support statistical multiplexing at message level.

   Delta T         8 bit field. The value of this field MAY be set
                   by any NF(ingress) node into (only)
                   "PHR_Resource_Release" objects. It specifies a
                   percentage that represents the ratio between a
                   time lag, say T_lag, and the length of the refresh
                   period, say T_period.  Where, T_lag represents
                   the difference between the departure time of the





Westberg, et al.          Expires October 2003                 [Page 92]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                   previous sent "PHR_Refresh_Update" object and
                   the departure time of the "PHR_Resource_Release"
                   object. T_period represents the length of the
                   refresh period. This information MAY be used by
                   any node during an explicit release procedure.

   Shared %        8 bit field. This value MAY be used to specify if a
   (Shared         load sharing situation occurred on a communication path
   percentage)     or not. The ingress node sets this value to 100. If
                   load sharing occurred in a node then the node
                   will divide the shared percentage value to the
                   number of equal cost paths.

   Variable        this field is currently unused.  Reserved for
   length          future PHR object extensions.


8.2.  PDR objects
   The format of the PDR object that is based on the IPv4 version is
   depicted in Figure 20.  On top of the PDR specific information of the
   PDR object, the three (standard) RSVPv1 object fields are used, i.e.,
   Length, Class-Num and C-type.




























Westberg, et al.          Expires October 2003                 [Page 93]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






    0                                                             31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Length(bytes)          | Class-Num     |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PDRID |MsgType|S|M|B| Unused  |F-Type |EP-Type|   PDR-TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reverse Requested Resources  |   Shared %    |Dropping rate %|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Ingress (Egress) Address (IPv4)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Flow-ID (length varies)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Variable length field                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 20: PDR object format based on IPv4

   Length
   (in octets):    16-bit field containing the total object length in
                   octets. It must always be a multiple of 4 and at least
                   4 octets.

   Class-Num:      8-bit field identifying the object class. Each object
                   class has a name.

   C-Type:         8-bit field identifying the object type, unique within
                   Class-Num. In this case a C-Type ID should be assigned
                   to the the PHR object.

   PDRID:          4-bit field identifying the ID of the PDR object. It is
                   zero for an experimental protocol.

   MsgType:        4-bit field identifying the type of PDR object. See
                   below for a table of recognized values.

                   MsgType  Description              Sent with PHR object
                    -----------------------------------------------------
                   0     reserved
                   1     PDR_Reservation_Request  PHR_Resource_Request
                   2     PDR_Refresh_Request      PHR_Refresh_Update
                   3     PDR_Release_Request      PHR_Resource_Release





Westberg, et al.          Expires October 2003                 [Page 94]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                   4     PDR_Reservation_Report
                   5     PDR_Refresh_Report
                   6     PDR_Release_Report
                   7     PDR_Request_Info         PHR_Resource_Request OR
                                                  PHR_Refresh_Update   OR
                                                  PHR_Resource_Release OR
                                                  PHR_Modification_Request
                   8     PDR_Congestion_Report
                   9     PDR_Modification_Request
                   10    PDR_Modification_Report
                   11-16 unused

                   "PDR_Reservation_Request": generated by the NF(ingress)
                   node in order to initiate or update the RSVPv2-NSLP PDR state
                   in the NF(egress) node

                   "PDR_Refresh_Request": generated by the NF(ingress) node
                   and sent to the NF(egress) node to refresh, in case
                   needed, the RSVPv2-NSLP PDR states located in the NF(egress)
                   node

                   "PDR_Modification_Request": generated and sent by the
                   NF(ingress) node to the NF(egress) node to modify the
                   PDR states located in the NF(egress) node

                   "PDR_Release_Request": generated and sent by the
                   NF(ingress) node to the NF(egress) node to release the
                   flows explicitly

                   "PDR_Request_Info": an object that can be used as a
                   common "PDR_Reservation_Request", "PDR_Refresh_Request",
                   "PDR_Release_Request" and "PDR_Modification_Request"

                   "PDR_Reservation_Report": generated and sent by the
                   NF(egress) node to the NF(ingress) node to report that
                   a "PHR_Resource_Request" PHR object and a
                   "PDR_Reservation_Request" PDR object has been received
                   and that the request has been admitted or rejected

                   "PDR_Refresh_Report": generated and sent by the NF(egress)
                   node in case needed, to the NF(ingress) node to report that
                   a "PHR_Refresh_Update" PHR object and a
                   "PDR_Refresh_Request" PDR object have been received and have
                   been processed






Westberg, et al.          Expires October 2003                 [Page 95]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






                   "PDR_Congestion_Report": generated and sent by the
                   NF(egress) node to the NF(ingress) node and used for severe
                   congestion notification. They are only used when either the
                   "greedy marking" or "proportional marking" severe
                   congestion notification procedures are applied.

                   "PDR_Modification_Report": generated and sent by the
                   NF(egress) node to NF(ingress) node to report that the
                   combination of either the "PHR_Resource_Request" PHR
                   object and the "PDR_Modification_Request" PDR object or
                   the "PHR_Release_Request" PHR object and the
                   "PDR_Modification_Request" have been received and
                   processed

   PDRID:          4-bit field. ID of the PDR object. It is
                   zero for an experimental protocol.

   S (Severe  :    1-bit field. specifies if a severe congestion
   Congestion)     situation occured. It can also carry the "S" flag of
                   the "PHR_Resource_Request" or "PHR_Refresh_Update"
                   PHR objects.
                   This flag only applies to "PDR_Reservation_Report",
                   "PDR_Refresh_Report", "PDR_Congestion_Report" and
                   "PDR_Modification_Report" objects.

   M (Marked):     1-bit field. Carries the "M" value of the
                   "PHR_Resource_Request" or "PHR_Refresh_Update" PHR
                   objects.
                   This flag only applies to "PDR_Reservation_Report",
                   "PDR_Refresh_Report", "PDR_Congestion_Report" and
                   "PDR_Modification_Report" objects.

   B          :     1-bit field. specifies that the "PHR" objects should be
   (Bi-directional  used for bi-directional reservations in intra-domain
   reservation)     signaling. Note that when the inter-domain signaling
                    procedures are applied for bi-directional reservations
                    it does not mean that the associated intra-domain
                    signaling procedures should also use bi-directional
                    reservations.

   F-Type:         4-bit field. The Flow-ID type identifier. Defined by the
   (Flow           PDR protocol. It informs the NF(ingress) and NF(egress)
    Type)          nodes what kind of data is contained in the Flow-ID and
                   its length. Every NF(edge) node should be configured to
                   process the F-Types.





Westberg, et al.          Expires October 2003                 [Page 96]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   EP-Type:        4-bit field. Identifies the used external protocol.
   (External       Only useful when the intra-domain signaling procedures
   Protocol        are used in combination with non-RSVPv2 inter-domain
   Type)           signaling procedures. It informs the NF(ingress) and
                   NF(egress) nodes  what type of external protocol (EP)
                   data is contained in the Variable length field. Every
                   edge node MUST be configured to process the EP-Type. If
                   this field is 0000 then the Variable length field can be
                   used for other purposes, i.e., future specifications.

   PDR-TTL:        8-bit field. The TTL value introduced by a node that
                   could  not admit or process a "PHR_Resource_Request"
                   object.

   Reverse     :   16 bits. This field only applies when the "B" flag is
   Requested       set to "1".
   Resources       It specifies the requested number of
                   units of resources that have to be reserved by a node
                   in the reverse direction when the intra-domain signaling
                   procedures require a bi-directional reservation procedure.
                   The unit is not necessarily a simple bandwidth value: it
                   may be defined in terms of any resource unit (e.g.,
                   effective bandwidth) to support statistical multiplexing
                   at packet level.

   Shared % :      8-bit field. This value specifies if a load sharing
   (Shared         situation occurred on a communication path or not. The
   percentage):    NF(ingress) node  sets this value to 100. If load sharing
                   occurred in a node then the node will have to divide the
                   shared percentage value to the number of equal cost paths.

   Dropping  :     8-bit field: This value specifies the dropping rate
   rate %:         percentage and is used during severe congestion. The ingress
   (Dropping rate  node will use this rate as a blocking probability, to
   percentage)     terminate the particular flow.

   Ingress   :     32-bit field. For the case that the PDR object is sent by
   (Egress)        NF(ingress) to NF(egress) this field represents the
   Address         NF(ingress) IP address. In the other direction this field
                   represents the NF(egress) IP address.

   Flow-ID:        Length depends on F-Type. It specifies the flow ID used
                   by the PDR state.

   Variable :      variable length field. It can be used either for





Westberg, et al.          Expires October 2003                 [Page 97]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






   length          including external protocol data or reserved for
   field           future PDR object extensions.

   The format of the PDR object that is based on the IPv6 version is
   depicted in Figure 21.  Note that the only difference between the PDR
   object format based on IPv4 and IPv6 versions is the Ingress (Egress)
   Address field, i.e., in IPv6 is this field 128 bits long, while in
   IPv4 is this field 32 bits long.

    0                                                             31
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Length(bytes)          | Class-Num     |   C-Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PDRID |MsgType|S|M|B| Unused  |F-Type |EP-Type|   PDR-TTL     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Reverse Requested Resources  |   Shared %    |Dropping rate %|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |            Ingress (Egress) Address (IPv6)                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     Flow-ID (length varies)                   |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  Variable length field                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Figure 21: PDR object format based on IPv6



9.  References

   [BrLi01]   Braden, R., Lindell, B., "A Two-Level Architecture for
              Internet Signaling", Internet Draft (work in progress),
              2001.

   [Bru03]    Brunner, M., "Requirements for QoS Signaling Protocols",
              draft-ietf-nsis-req-06.txt (work in progress), 2003

   [CsTa02]   Csaszar, A., Takacs, A., Szabo, R., Rexhepi, V.,





Westberg, et al.          Expires October 2003                 [Page 98]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






              Karagiannis, G., "Severe Congestion Handling
              with Resource Management in Diffserv On Demand",
              submitted to Networking 2002, May 19-24 2002,
              Pisa - ITALY.

   [Hanc03]   Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.,
              Van den Bosch, S., "Next Steps in Signaling: Framework",
              Internet Draft, 2003, Work in progress.

   [RFC1633]  Braden, R., Clark, D., Shenker, S., "Integrated
              Services in the Internet Architecture: an Overview",
              IETF RFC 1633, 1994.

   [RFC2002]  Perkins, C., Editor, "IP Mobility Support", RFC 2002,
              October 1996.

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

   [RFC2747]  F. Baker, B. Lindell, M.Talwar.  "RSVP Cryptographic
              Authentication", IETF RFC, January 2000.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang,
              Zh., Weiss, W., "An Architecture for Differentiated
              Services", IETF RFC 2475, 1998.

   [RFC3175]  Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
              "Aggregation of RSVP for IPv4 and IPv6 Reservations",
              IETF RFC 3175, 2001.

   [RIMA]    Westberg, L., Heijenk, G., Karagiannis, G., Oosthoek, S.,
             Partain, D., Rexhepi, V., Szabo, R., Wallentin, P.,
             el Allali, H.,"Resource Management in Diffserv
             Measurement-based Admission Control PHR", Internet draft
             Work in progress, 2002.

   [RODA]    Westberg, L., Karagiannis, G., Kogel, de M., Partain, D.,
             Oosthoek, S., Jacobsson, M., Rexhepi, V., "Resource Management
             in Diffserv On DemAnd (RODA) PHR", Internet Draft,
             Work in progress.

   [RMD-frame]  Westberg, L., Jacobsson, M., Karagiannis, G., Rexhepi, V.,
             Partain, D., Oosthoek, S., Szabo, R., Wallentin, P.,





Westberg, et al.          Expires October 2003                 [Page 99]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






             "Resource Management in Diffserv
             Framework", Internet draft, Work in progress.

   [NSIS-ML1] Braden, B., "Re: What's in the charter of NSIS",
              http://www1.ietf.org/mail-archive/working-groups/
              nsis/current/msg01368.html

   [PAN-SSP]  Pan, P., Murphy, J., "A Network Architecture
              for Simplified Signaling Protocol", IETF Internet
              Draft, draft-pan-signal-req-00.txt, Work in Progress,
              May 2002.

   [RANISSUE] Partain, D., Karagiannis, G., Wallentin, P.,
              Westberg, L.,"ResourceReservation Issues in
              Cellular Radio Access Networks", Internet Draft,
              draft-westberg-rmd-cellular-issues-01.txt, Work
              in Progress, June 2002.

   [WeKa03]   Westberg, L., Karagiannis, G., Rexhepi, V.,
              "Using RSVPv1 as NTLP (NSIS Transport layer Protocol):
              suggestions for modifications on RFC2205", Internet
              Draft, Work in Progress,
              draft-westberg-nsis-rsvp-as-ntlp-01.txt, February 2003.



























Westberg, et al.          Expires October 2003                [Page 100]


Internet Draft          Proposal for RSVPv2-NSLP              April 2003






10.  Authors' Addresses

   Lars Westberg
   Ericsson Research
   Torshamnsgatan 23
   SE-164 80 Stockholm
   Sweden
   EMail: Lars.Westberg@era.ericsson.se

   Attila Bader
   Traffic Lab
   Ericsson Hungary Ltd.
   Laborc u. 1
   H-1037 Budapest
   Hungary
   EMail: Attila.Bader@eth.ericsson.se

   Georgios Karagiannis
   University of Twente
   P.O. BOX 217
   7500 AE Enschede
   The Netherlands
   EMail: karagian@cs.utwente.nl

   David Partain
   Ericsson Radio Systems AB
   P.O. Box 1248
   SE-581 12  Linkoping
   Sweden
   EMail: David.Partain@ericsson.com

   Vlora Rexhepi
   Ericsson EuroLab Netherlands B.V.
   Institutenweg 25
   P.O.Box 645  7500 AP Enschede
   The Netherlands
   EMail: Vlora.Rexhepi@eln.ericsson.se













Westberg, et al.          Expires October 2003                [Page 101]