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

Versions: (draft-mcdonald-nsis-qos-nslp) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 5974

        NSIS Working Group
        Internet Draft                             Sven Van den Bosch (Editor)
                                                                       Alcatel
                                                          Georgios Karagiannis
                                                      Univ. of Twente/Ericsson
                                                               Andrew McDonald
                                                   Siemens/Roke Manor Research
     
     
        Document: draft-ietf-nsis-qos-nslp-01.txt
        Expires: April 2004                                       October 2003
     
     
                        NSLP for Quality-of-Service signaling
     
     Status of this Memo
     
        This document is an Internet-Draft and is in full conformance with
        all provisions of Section 10 of RFC2026.
     
        Internet-Drafts are working documents of the Internet Engineering
        Task Force (IETF), its areas, and its working groups. Note that
        other groups may also distribute working documents as Internet-
        Drafts.
     
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
     
        The list of current Internet-Drafts can be accessed at
             http://www.ietf.org/ietf/1id-abstracts.txt
        The list of Internet-Draft Shadow Directories can be accessed at
             http://www.ietf.org/shadow.html.
     
     Abstract
     
        This draft describes an NSIS Signaling Layer Protocol (NSLP) for
        signaling QoS reservations in the Internet. It is in accordance with
        the framework and requirements developed in NSIS.
     
        Together with the NTLP, it provides functionality similar to RSVP and
        extends it. The QoS-NSLP is independent of the underlying QoS
        specification or architecture and provides support for different
        reservation models. It is simplified by the elimination of support
        for multicast flows.
     
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 1]


                     NSLP for Quality-of-Service signaling    October 2003
     
        This version of the draft focuses on the basic protocol structure. It
        identifies the different message types and describes the basic
        operation of the protocol to create, refresh, modify and teardown a
        reservation or to obtain information on the characteristics of the
        associated data path.
     
     Conventions used in this document
     
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in RFC-2119 [1].
     
     Table of Contents
     
        1. Introduction...................................................3
          1.1 Scope and background........................................3
          1.2 Model of operation..........................................3
          1.3 Terminology.................................................6
        2. Protocol design principles.....................................7
          2.1 Basic protocol structure....................................7
          2.2 QoS model...................................................8
          2.3 Authentication and authorization............................9
          2.4 Control Information.........................................9
          2.5 Nested protocol operation..................................10
          2.6 Protocol extensibility.....................................11
          2.7 Implementation flexibility for scalability.................11
        3. Basic message types...........................................12
          3.1 RESERVE....................................................12
          3.2 QUERY......................................................14
          3.3 RESPONSE...................................................15
          3.4 NOTIFY.....................................................15
        4. Basic outline of operation....................................16
          4.1 Making a reservation.......................................16
          4.2 Refreshing a reservation...................................17
          4.3 Sending a response.........................................18
          4.4 Performing a query.........................................19
          4.5 Tearing down a reservation.................................20
        5. IANA section..................................................20
        6. Requirements for the NSIS Transport Layer Protocol (NTLP).....21
          6.1 Support for stateless operation............................21
          6.2 Support for Source Identification Information (SII)........21
          6.3 Last node detection........................................22
          6.4 Re-routing detection.......................................22
          6.5 Performance requirements...................................22
        7. Open issues...................................................23
          7.1 Refinements of this version................................23
          7.2 Content for next (-01) version.............................23
          7.3 Content for future (-0x) versions..........................24
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 2]


                     NSLP for Quality-of-Service signaling    October 2003
     
        8. Security Considerations.......................................26
        9. Change History................................................26
        10. Appendix A: A strawman QSpec template........................26
        References.......................................................27
        Acknowledgments..................................................30
        Contributors.....................................................30
        Contact information..............................................30
        Full Copyright Statement.........................................30
     
     1. Introduction
     
     1.1 Scope and background
     
        This document defines a Quality of Service (QoS) NSIS Signaling Layer
        Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This
        protocol establishes and maintains state at nodes along the path of a
        data flow for the purpose of providing some forwarding resources for
        that flow. It is intended to satisfy the QoS-related requirements of
        [2]. This QoS-NSLP is part of a larger suite of signaling protocols,
        whose structure is outlined in [3]; this defines a common NSIS
        Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many
        aspects of signaling message delivery.
     
        The design of QoS-NSLP is conceptually similar to RSVP [4], and uses
        soft-state peer-to-peer refresh messages as the primary state
        management mechanism. Although there is no backwards compatibility at
        the level of protocol messages, interworking with RSVP at a signaling
        application gateway would be possible in some circumstances. QoS-NSLP
        extends the set of reservation mechanisms to meet the requirements of
        [2], in particular support of sender or receiver-initiated
        reservations, as well as a type of bi-directional reservation and
        support of reservations between arbitrary nodes, e.g. edge-to-edge,
        end-to-access, etc. On the other hand, there is no support for IP
        multicast.
     
        QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular
        QoS provisioning method or QoS architecture; this is similar to (but
        stronger than) the decoupling between RSVP and the IntServ
        architecture [5]. It should be able to carry information for various
        QoS models; the specification of Integrated Services for use with
        RSVP given in [6] could form the basis of one QoS model.
     
     
     1.2 Model of operation
     
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 3]


                     NSLP for Quality-of-Service signaling    October 2003
     
        This section presents a logical model for the operation of the QoS-
        NSLP and associated provisioning mechanisms within a single node. It
        is adapted from the discussion in section 1 of [4]. The model is
        shown in Figure 1.
                                           +---------------+
                                           |     Local     |
                                           |Applications or|
                                           |Management (e.g|
                                           |for aggregates)|
                                           +---------------+
                                                   ^
                                                   ^
                                                   V
                                                   V
                    +----------+             +----------+      +---------+
                    | QoS-NSLP |             | Resource |      | Policy  |
                    |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
                    +----------+             +----------+      +---------+
                      .  ^   |              *      ^
                      |  V   .            *        ^
                    +----------+        *          ^
                    |   NTLP   |       *           ^
                    |Processing|       *           V
                    +----------+       *           V
                      |      |         *           V
          ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
                      .      .         *           V
                      |      |         *     .............................
                      .      .         *     .   Traffic Control         .
                      |      |         *     .                +---------+.
                      .      .         *     .                |Admission|.
                      |      |         *     .                | Control |.
            +----------+    +------------+   .                +---------+.
        <-.-|  Input   |    | Outgoing   |-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
            |  Packet  |    | Interface  |   .+----------+    +---------+.
        ===>|Processing|====| Selection  |===.|  Packet  |====| Packet  |.==>
            |          |    |(Forwarding)|   .|Classifier|     Scheduler|.
            +----------+    +------------+   .+----------+    +---------+.
                                             .............................
                <.-.-> = signaling flow
                =====> = data flow (sender -->receiver)
                <<<>>> = control and configuration operations
                ****** = routing table manipulation
     
                              Figure 1: QoS-NSLP in a Node
     
        This diagram shows an example implementation scenario where QoS
        conditioning is performed on the output interface. However, this does
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 4]


                     NSLP for Quality-of-Service signaling    October 2003
     
        not limit the possible implementations. For example, in some cases
        traffic conditioning may be performed on the incoming interface, or
        it may be split over the input and output interfaces.
     
        From the perspective of a single node, the request for QoS may result
        from a local application request, or from processing an incoming QoS-
        NSLP message.
     
        -  The 'local application case' includes not only user
           applications (e.g. multimedia applications) but also network
           management (e.g. initiating a tunnel to handle an aggregate,
           or interworking with some other reservation protocol - such as
           RSVP). In this sense, the model does not distinguish between
           hosts and routers.
     
        -  The 'incoming message' case requires NSIS messages to be
           captured during input packet processing and handled by the
           NTLP. Only messages related to QoS are passed to the QoS-NSLP.
           The NTLP may also generate triggers to the QoS-NSLP (e.g.
           indications that a route change has occurred).
     
        The QoS request is handled by a local 'resource management' function,
        which coordinates the activities required to grant and configure the
        resource.
     
        -  The grant processing involves two local decision modules,
           'policy control' and 'admission control'. Policy control
           determines whether the user has administrative permission to
           make the reservation. Admission control determines whether the
           node has sufficient available resources to supply the
           requested QoS.
     
        -  If both checks succeed, parameters are set in the packet
           classifier and in the link layer interface (e.g., in the
           packet scheduler) to obtain the desired QoS. Error
           notifications are passed back to the request originator. The
           resource management function may also manipulate the
           forwarding tables at this stage, to select (or at least pin) a
           route; this must be done before interface-dependent actions
           are carried out (including forwarding outgoing messages over
           any new route), and is in any case invisible to the operation
           of the protocol.
     
        Policy control is expected to make use of a AAA service external to
        the node itself. Some discussion can be found in [7] and [8]. More
        generally, the processing of policy and resource management functions
        may be outsourced to an external node leaving only 'stubs' co-located
        with the NSLP; this is not visible to the protocol operation,
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 5]


                     NSLP for Quality-of-Service signaling    October 2003
     
        although it may have some influence on the detailed design of
        protocol messages to allow the stub to be minimally complex.
     
        The group of user plane functions, which implement QoS for a flow
        (admission control, packet classification, and scheduling) is
        sometimes known as 'traffic control'.
     
        Admission control, packet scheduling, and any part of policy control
        beyond simple authentication have to be implemented using specific
        definitions for types and levels of QoS; we refer to this as a QoS
        model. Our assumption is that the QoS-NSLP is independent of the QoS
        model, that is, QoS parameters (e.g. IntServ service elements) are
        interpreted only by the resource management and associated functions,
        and are opaque to the QoS-NSLP itself. QoS Models are discussed
        further in section 2.2.
     
        The final stage of processing for a resource request is to indicate
        to the QoS-NSLP protocol processing that the required resources have
        been configured. The QoS-NSLP may generate an acknowledgement message
        in one direction, and may propagate the resource request forwards in
        the other. Message routing is (by default) carried out by the NTLP
        module. Note that while Figure 1 shows a unidirectional data flow,
        the signaling messages can pass in both directions through the node,
        depending on the particular message and orientation of the
        reservation.
     
     1.3 Terminology
     
        The terminology defined in [3] applies to this draft. In addition,
        the following terms are used:
     
        -  edge QNE - a QNE that is located at the boundary of an
           administrative domain, e.g., Diffserv.
     
        -  egress QNE - an edge QNE that handles the traffic as it leaves
           the domain.
     
        -  ingress QNE - an edge QNE that handles the traffic as it
           enters the domain.
     
        -  interior QNE - a QNE that is part of an administrative domain,
           e.g., Diffserv, and is not an edge QNE.
     
        -  QNE - an NSIS Entity (NE), which supports the QoS-NSLP.
     
        -  QNI - the first node in the sequence of QNEs that issues a
           reservation request.
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 6]


                     NSLP for Quality-of-Service signaling    October 2003
     
     
        -  QNR - the last node in the sequence of QNEs that receives a
           reservation request.
     
        -  QoS-NSLP stateful operation - mode of operation where per-flow
           reservation states are created, maintained and used.
     
        -  QoS-NSLP reduced-state operation - mode of operation where
           reservation states with a coarser granularity (e.g. per-class)
           are created, maintained and used.
     
        -  QoS-NSLP stateless operation - mode of operation where
           reservation state is not needed and not created.
     
        -  reduced state QNE - a QNE that supports the QoS NSLP reduced
           state operation.
     
        -  Source or message source - QoS NSLP messages are sent peer-to-
           peer. This means that a QNE considers its adjacent stateful
           upstream or downstream peer to be the source of a QoS NSLP
           message. I.e. the source of a QoS NSLP message is not
           necessarily the QNI.
     
        -  Stateful QNE - a QNE that supports the QoS NSLP stateful
           operation.
     
        -  Stateless QNE - a QNE that supports the QoS NSLP stateless
           operation.
     
     2. Protocol design principles
     
     2.1 Basic protocol structure
     
        Messages are normally passed from the NSLP to the NTLP via an API,
        which also specifies the signaling application (as QoS-NSLP), the
        flow/session identifier, and an indication of the intended direction
        - towards data sender or receiver. On reception, the NTLP provides
        the same information to the QoS-NSLP.
     
        The protocol specifies four message types (RESERVE, QUERY, RESPONSE
        and NOTIFY) and two objects (QSpec and Policy object).
     
        -  Each protocol message includes header information that
           identifies the message type and determines which objects it
           may carry.
     
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 7]


                     NSLP for Quality-of-Service signaling    October 2003
     
        -  A protocol message also contains Control Information (CI);
           this is a group of objects that qualify and/or restrict the
           action that a QNE may perform on the QoS message. Control
           Information is always associated to a QSpec, i.e. CI and QSpec
           always come in pairs. This is important when we have locally
           valid objects e.g. for reduced state operation, because both a
           CI and a QSpec will be added.
     
        -  QSpec object: The QoS parameters defined by the QoS model are
           carried in a QSpec object. It describes the QoS that is being
           reserved.
     
        -  Policy object: The Policy object authenticates and authorizes
           the requester of the QoS reservation.
     
        This memo intends to define message types and control information for
        the QoS-NSLP (generic to all QoS models). It also introduces the QoS
        model (section 2.2) and Policy object (section 2.3). However, a
        detailed description of these objects will need to be provided in
        separate documents.
     
     2.2 QoS model
     
        A QoS model is a defined mechanism for achieving QoS as a whole. The
        specification of a QoS model includes a description of its QoS
        parameter information, as well as how that information should be
        treated or interpreted in the network. In that sense, the QoS model
        goes beyond the QoS-NSLP protocol level in that it could also
        describe underlying assumptions, conditions and/or specific
        provisioning mechanisms appropriate for it.
     
        A QoS model provides a specific set of parameters to be carried in
        the QSpec, or restricts the values these parameters can take.
        Integrated Services [5], Differentiated Services[9] and RMD [11] are
        all examples of QoS models. There is no restriction on the number of
        QoS models. QoS models may be local, meaning that they are private to
        one network, implementation or vendor specific or global, meaning
        that they must be implementable by different networks and vendors.
     
        The QSpec contains a set of parameters and values describing the
        requested resources. It is opaque to the QoS-NSLP and similar in
        purpose to the TSpec, RSpec and AdSpec specified in [4,6]. At each
        QNE, its content is interpreted by the resource management function
        for the purposes of policy control and traffic control (including
        admission control and configuration of the packet classifier and
        scheduler).
     
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 8]


                     NSLP for Quality-of-Service signaling    October 2003
     
        Different QoS models may share a common set of QoS parameters.
        Standardizing a QSpec template would allow for a consistent
        specification of common QoS parameters in different QoS models. It
        would simplify the introduction of new QoS models as well as greatly
        increasing interoperability. Other examples of QoS description for
        which a template was standardized are e.g. the MEF Ethernet Service
        definition [10]. The QSpec template is envisaged to be useful for
        specifying a wide range of QoS descriptions. It would, for instance,
        need to support both qualitative and quantitative QoS specifications
        in order to provide for terminals that are not willing or capable to
        quantitatively describe the traffic behavior they require. A strawman
        QSpec template is described in Appendix A. In addition to
        standardizing a QSpec template, individual QoS models could be
        standardized, but we would expect them to have local significance
        only.
     
     2.3 Authentication and authorization
     
        Future versions of this document will contain a discussion on the
        Policy object, based on [7,8].
     
     2.4 Control Information
     
        Any QoS-NSLP message may contain a set of objects for conveying
        information about how these messages should be handled. This set of
        objects is collectively known as Control Information (CI).
     
        Control Information can have a local scope (Local Control Information
        or LCI) or global scope.
     
        The ability of a QNE to explicitly request a RESPONSE to its messages
        (section 2.4.1) and the ability to limit the scope of a message are
        both examples of Control Information (section 2.4.2). Future versions
        of the draft may include more examples of Control
        Information objects.
     
     2.4.1ResponseRequest
     
        Some QNEs may require explicit responses to messages they send. A
        QUERY message (section 3.2), for instance, will always cause a
        RESPONSE message (section 3.3) to be sent. The QNE that generates a
        RESERVE message (section 3.1) may explicitly request that it triggers
        a RESPONSE.
     
     
     
     Van den Bosch et al.     Expires - April 2004                 [Page 9]


                     NSLP for Quality-of-Service signaling    October 2003
     
        If a RESPONSE message is required or desired, the QNE inserts a
        ResponseRequest object in the message. The exact format of this
        object will be determined in a future version of this specification.
     
        In order to be able to match a response back to the corresponding
        request , the ResponseRequest object contains Response Identification
        Information (RII). The RII is inserted by the QNE that requests the
        response and is copied into the corresponding RESPONSE message. QNEs
        that receive a RESPONSE containing their own RII should not forward
        the message further.
     
        The ResponseRequest object also contains a flag to indicate whether
        it is requesting a response from the next node (a 'local' response),
        or a response from the QNR. More general ways of specifying scoping
        information will be investigated in future versions of this document.
     
        Note that if an intermediate QNE desires a RESPONSE as well, it
        should not change the RII or add another ResponseRequest since the
        RESPONSE will pass through it anyway.
     
     2.4.2Message and object scoping
     
        QoS-NSLP supports locally defined QoS model specifications by means
        of local QSpecs and local Control Information. Messages containing
        such local information need to be scoped, i.e. it should be possible
        to restrict the forwarding of such a message to the domain in which
        it is applicable. It may also be needed to scope individual objects
        in the message.
     
        One example of message scoping uses the RII to limit the forwarding
        of a RESPONSE to the QNE that requested it. Another example might be
        controlling the scope of a tearing RESERVE.
     
        The two scopes of "single QoS-NSLP hop" and "whole path" appear to be
        useful concepts. In case no scoping information is specified, the
        default case of "whole path" must be assumed. It is still to be
        determined what the best way(s) of specifying more flexible scoping
        information, such as per-domain are.
     
     2.5 Nested protocol operation
     
        For various reasons an operator may want to use a different type of
        QoS specification (i.e. a different QoS model) within its network.
        This may be done, for example, in order for QNEs to be able to store
        less reservation state. In order to allow some local selection of
        which QoS Model to use without destroying all end-to-end aspects of
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 10]


                     NSLP for Quality-of-Service signaling    October 2003
     
        the signaling, QoS-NSLP allows a nesting of QoS Models by 'stacking'
        more than one pair of Control Information / QSpec object within a
        message.
     
        The details of this operation will be covered in future versions of
        this draft. This nested operation would allow localized QSpec objects
        and control information to be used along parts of the path. It also
        has dependencies on the scoping facilities provided by the protocol.
     
     2.6 Protocol extensibility
     
        QoS-NSLP is designed in modular way making it possible to support
        different QoS models and other future extensions of the protocol.
        Extensions can be provided by specifying new QoS models and their
        usage or defining new QoS-NSLP objects (similar to the current QSpec
        and Policy object) and their usage.
     
        In QoS-NSLP the basic operation mechanism of the protocol is clearly
        separated from the control and traffic information being transported.
        This logical separation makes it possible to develop a variety of new
        QoS models within one protocol frame. Each of the QoS-NSLP message
        types can carry, for each supported QoS Model, QoS descriptions by
        using object templates. This memo discusses a template for the QoS
        specification (QSpec). A future version will also cover the Policy
        object.
     
        A new QoS model is specified by defining the internal content of the
        template objects and by defining how QoS provisioning is done in
        different nodes. Another important aspect of defining a new QoS model
        is the specification of the associated CI used in these templates,
        which allow particular setting in different nodes.
     
        A QoS model may have internal structure into different components,
        some of which may have application limited to particular nodes while
        being opaque to others.
     
     2.7 Implementation flexibility for scalability
     
        The QoS-NSLP protocol supports QoS architectures in which some QNEs
        may not be able or willing to store per-session state. A stateless
        operation is conceivable, in which QNEs interior to a domain store
        neither NSLP nor NTLP state. They rather e.g. just send and receive
        messages to provide information on currently available resources, and
        react upon overload detection.  Also reduced-state operation is
        conceivable, in which QNEs do not store full per session (per-flow or
        per-aggregate) state in both NSLP and NTLP, but rather, e.g. one per-
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 11]


                     NSLP for Quality-of-Service signaling    October 2003
     
        class state in NSLP and no state in NTLP. Examples of how QoS can be
        achieved with stateless and reduced-state operation are described in
        RMD [11].
     
        Stateless and reduced state operation is only applicable under
        certain circumstances. Stateless or reduced state QNEs are not able
        to perform message bundling, message fragmentation and reassembly (at
        the NSLP) or congestion control. They are not able to establish and
        maintain security associations with their neighbors, which means they
        can only be applied in a trusted environment. For these reasons, a
        typical application of stateless or reduced state QNEs is for
        signaling within a single domain where the edges of the domain are
        stateful QNEs.
     
        Stateless and reduced state QoS-NSLP operation makes the most sense
        when (some nodes of) the underlying NTLP is (are) able to operate in
        a stateless way as well. Such nodes should not worry about keeping
        reverse path state, message fragmentation and reassembly (at the
        NTLP), congestion control or security associations. A stateless or
        reduced state QNE will be able to inform the underlying NTLP of this
        situation. We rely on the NTLP design to allow for a mode of
        operation that can take advantage of this information (section 6.1).
     
     3. Basic message types
     
        The QoS-NSLP contains four message types: RESERVE, QUERY, RESPONSE
        and NOTIFY.
     
        These messages have different conceptual properties; the
        fundamental properties of the message determine how it should be
        analyzed from the perspective of re-ordering, loss, end-to-end
        reliability and so on. It is important for applications to know
        whether NSLP messages can be repeated, discarded or merged and so on
        (e.g. for edge mobility support, rerouting, etc). Indeed, the
        ordering of messages that don't manipulate state at QNEs matters
        little, whereas the way that messages that manipulate state are
        interleaved matters very much. Therefore NSLP is designed such that
        the message type identifies whether a message is manipulating state
        (in which case it is idempotent) or not (it is impotent).
     
     3.1 RESERVE
     
        The RESERVE message is used to manipulate QoS reservation state in
        QNEs. A RESERVE message may create, refresh, modify or remove such
        state.
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 12]


                     NSLP for Quality-of-Service signaling    October 2003
     
        The RESERVE message opaquely transports a QSpec object, describing
        the desired service level and a Policy object, authorizing the
        requestor of the service. It also carries the lifetime of the
        reservation (most likely in the Control Information part). Each node
        may insert a local QSpec object and or local Control Information
        (LCI) provided it has a way of scoping this information (e.g. at the
        boundary of a domain).
     
        In some cases, a QNE needs to be able to distinguish between newly
        created, modified state or refreshed state based on the RESERVE
        message alone (not in combination with state information obtained
        from previous messages). Therefore, one or more additional flags that
        provide this differentiation may be needed. Future versions of this
        draft will describe how such flag(s) will be provided and used.
     
        In order to clearly distinguish between a RESERVE message that sets
        the reserved resources to zero and a RESERVE message that tears down
        QoS-NSLP state completely, a tear bit should be foreseen. Note that
        the potential initiation of (reverse path) state removal at the NTLP
        is a separate issue. This will be signaled over the API between NTLP
        and QoS-NSLP.
     
        RESERVE messages are sent peer-to-peer. This means that a QNE
        considers its adjacent upstream or downstream peer to be the source
        of the RESERVE message. Note that two nodes that are adjacent at the
        QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS-
        NSLP node may want to be able to detect changes in its QoS-NSLP
        peers, or send a message to an explicitly identified node, e.g. for
        tearing down a reservation on an old path. This functionality can be
        provided by keeping track of a Source Identification Information
        (SII) object that is similar in nature to the RSVP_HOP object
        described in [4]. We assume such an SII (section 6.2) to be available
        as a service from the NTLP.
     
        The RESERVE message is idempotent; the resultant effect is the same
        whether a message is received once or many times. In addition, the
        ordering of RESERVE messages matters - an old RESERVE message does
        not replace a newer one. Both of these features are required for
        protocol robustness - messages may be re-ordered on route (e.g.
        because of mobility, or at intermediate NTLP nodes) or spuriously
        retransmitted.
     
        In order to tackle these issues, the RESERVE message contains a
        Reservation Sequence Number (RSN). An RSN is an incrementing sequence
        number that indicates the order in which state modifying actions are
        performed by a QNE. The RSN has local significance only, i.e. between
        QNEs. Attempting to make an identifier that was unique in the context
        of a session identifier but the same along the complete path would be
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 13]


                     NSLP for Quality-of-Service signaling    October 2003
     
        very hard. Since RESERVEs can be sent by any node on the path that
        maintains reservation state (e.g. for path repair) we would have the
        difficult task of attempting to keep the identifier synchronized
        along the whole path. The ordering only matters between a pair of
        nodes maintaining reservation state, i.e. stateful QNEs. This means
        that we can instead make the Reservation Sequence Number unique just
        between a pair of neighboring stateful QNEs. Note that an alternative
        might be for the NTLP to guarantee in-order delivery between the NSLP
        peers.
     
        A Flow Identifier groups together state items for a single flow. The
        RSN is one of these state items, and is used to identify reordering
        of messages and to allow the use of partial refresh messages. The
        state items for a number of flows can be linked together and
        identified as part of a single reservation using a Session
        Identifier. The identifiers play complementary roles in the
        management of QoS NSLP state.
     
        The sender of a RESERVE message may want to receive some confirmation
        from a downstream node. For this purpose the RESERVE message may
        contain a ResponseRequest object (section 2.4.1).
     
     3.2 QUERY
     
        A QUERY message is used to request information about the data path
        without making a reservation. This functionality can be used to
        'probe' the network for path characteristics or for support of
        certain QoS models. The information obtained from a QUERY may be used
        in the admission control process of a QNE (e.g. in case of
        measurement-based admission control). Note that a QUERY does not
        change existing reservation state, nor does it cause state to be
        installed in nodes other than the one that generated the QUERY.
     
        A QUERY message contains a ResponseRequest object containing Response
        Identification Information (RII) that allows matching back RESPONSE
        to the QUERY request. It is transported unchanged along the data path
        and may be used to scope the RESPONSE to a QUERY message (section
        3.3).
     
        The QUERY message can gather information along the data path in a
        number of objects. Some of these objects may be part of the QoS
        model. Others may be generic to the QoS-NSLP protocol.
     
        A QUERY message may be scoped. If scoping information is present,
        this means that the QUERY is not supposed to go down the entire path
        to the QNR but rather that is has a maximum number of QNE hops it can
        travel. Else, the default case (whole path) is assumed. It is
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 14]


                     NSLP for Quality-of-Service signaling    October 2003
     
        currently an open issue what the best way of message scoping is
        (section 7.1)
     
     3.3 RESPONSE
     
        The REPONSE message is used to provide information about the result
        of a previous QoS-NSLP message, e.g. confirmation, error or
        information resulting from a query. The RESPONSE message is impotent,
        it does not cause any state to be installed or modified.
     
        A QNE may want to receive a RESPONSE message to inform it that the
        reservation has been successfully installed. The RESERVE message may
        contain a ResponseRequest object for this purpose. Such a
        ResponseRequest object can be used to request an explicit
        confirmation of the state manipulation signaled in the RESERVE
        message.
     
        The forwarding of the RESPONSE message along the path does not
        necessarily imply the existence of NTLP reverse-path state at every
        node. For example, the NTLP may have a mechanism to pass a message
        directly from the egress to the ingress of a region of QNEs that do
        not store per-flow reverse-path state.
     
        If a QNE or the QNR is unable to provide the requested information or
        if the response is negative, the RESPONSE message may be used to
        carry an error message.
     
        A QUERY always causes a RESPONSE to be sent. Therefore, a QUERY
        message will always contain a ResponseRequest object. A RESERVE may
        cause a RESPONSE to be sent if this is explicitly requested or when
        an error occurs.
     
     3.4 NOTIFY
     
        NOTIFY messages are used to convey information to a QNE. NOTIFY
        messages are impotent (they do not cause a change in state directly).
     
        NOTIFY messages differ from RESPONSEs in that they need not refer to
        any particular state or previously received message. They are sent
        asynchronously. The NOTIFY message itself does not trigger or mandate
        any action in the receiving QNE.
     
        The information conveyed by a NOTIFY message is typically related to
        error conditions. One example would be notification to an upstream
        peer about state being torn down.
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 15]


                     NSLP for Quality-of-Service signaling    October 2003
     
     4. Basic outline of operation
     
     4.1 Making a reservation
     
        To make a new reservation, the QNI builds a RESERVE message
        containing a QSpec specifying the resources required and a Policy
        object containing user identification and authorization information.
        It initializes a Reservation Sequence Number (RSN) counter for the
        flow and provides the initial value in the RESERVE message. This
        message is passed to the NTLP, which delivers it to the next QNE. A
        ResponseRequest object may be introduced if a confirmation of
        successful reservation is desired.
     
        At the next QNE the RESERVE message is examined. Policy control and
        admission control decisions are made. The node performs appropriate
        actions based on the content of any QSpec object in the message. The
        QoS NSLP generates a new RESERVE message based on the one it
        received. This is passed to the NTLP, which forwards it to the next
        QNE.
     
        The same processing is performed at further QNEs on the path, up to
        the QNR.
     
        At the QNR, having determined that it is the last QNE (section 6.3)
        on the path, the attempt to send a further RESERVE message is
        aborted. The NR may rely on information obtained from the NTLP to
        determine that it is the last node (section 6.3).
     
        A QNE may want to store per-flow state for a number of reasons. It
        may be that per-flow reservations are required to provide better
        granularity of reserved resources. Some additional functions can also
        be provided by the NSLP by storing NSLP state.
     
        If the QNE wishes to be able to detect changes in the neighboring QNE
        (i.e. that a future RESERVE message did not come from the same node
        as the one that sent this RESERVE), then it records the identity of
        that node (e.g. SII). The SII on the outgoing message is defined by
        the NTLP.
     
        If the QNE also wants to detect re-ordered or duplicated RESERVE
        messages then it must also store the Reservation Sequence Number.
        When an NSLP node that maintains per-flow reservation state (and may
        generate refreshes) generates a RESERVE message to forward on to the
        next peer it must replace the Reservation Sequence Number in the
        message it received with one of its own. If the NSLP does not
        maintain any per-flow reservation state (and thus cannot generate new
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 16]


                     NSLP for Quality-of-Service signaling    October 2003
     
        RESERVE messages (refreshes, tears, etc) on its own) then it can use
        the RSN from the RESERVE message it received, rather than maintaining
        its own sequence numbers. By managing the sequence numbers in this
        manner, the source of the RESERVE does not need to determine how the
        next NSLP node will process the message.
     
        Layering approaches (as outlined in section 2.5) can be used by an
        ingress QNE to translate end-to-end NSLP messages into a form which
        is particularly suited to the local network, where it is expected
        that interior nodes will benefit from this. For example, where only
        per-class state or no state is stored by nodes (as for stateless or
        reduced-state operation in section 2.7). At the egress of the region,
        this local QSpec can be removed.
     
     4.2 Refreshing a reservation
     
        Since the NSIS protocol suite normally takes a soft-state approach to
        managing reservation state in QNEs, the state created by a RESERVE
        message must be periodically refreshed. Reservation state is deleted
        if no new RESERVE messages arrive before the expiration of the
        reservation lifetime. The Reservation lifetime is indicated in the
        RESERVE message when the reservation is made. Maintaining the
        reservation beyond this lifetime can be done by sending a RESERVE
        message with the same QSpec and Policy objects as the original
        message that created the reservation and by indicating that it is
        refreshing existing state. Note that a refreshing RESERVE should not
        increment the Reservation Sequence Number.
     
        At the expiration of a "refresh timeout" period, each QNE
        independently examines its state and sends a refreshing RESERVE
        message to the next QNE peer where it is absorbed. This peer-to-peer
        refreshing (as opposed to the QNI initiating a refresh which travels
        all the way to the QNR) allows QNEs to choose refresh intervals as
        appropriate for their environment. For example, it is conceivable
        that refreshing intervals in the backbone, where reservations are
        relatively stable, are much larger than in an access network. The
        "refresh timeout" is calculated within the QNE and is not part of the
        protocol; however, it must be chosen to be compatible with the
        reservation lifetime, and an assessment of the reliability of message
        delivery.
     
        The details of timer management and timer changes (slew handling and
        so on) are left for future versions of this document.
     
        If a RESPONSE has been received to acknowledge that reservation state
        has been installed, then an abbreviated form of refreshing RESERVE
        message ('summary refresh') can be sent which references the
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 17]


                     NSLP for Quality-of-Service signaling    October 2003
     
        reservation using the Reservation Sequence Number, rather than
        including the full reservation specification. Note that this
        functionality requires an explicit acknowledgment of state
        installation to ensure that the RSN reference will be understood. It
        is up to a QNE that receives a ResponseRequest to decide whether it
        wants to accept summary refreshes and provide this explicit
        acknowledgment. For example, reduced state QNEs that cannot support
        summary refreshes would not send this acknowledgement.
     
        It is currently an open point which parts of the RESERVE message are
        reused by the summary refresh. A summary refresh containing only the
        RSN seems to be the minimal case of a broad spectrum of varying
        amounts of data that we send in an update. Future versions of this
        document will attempt to identify some objects as 'needing refresh'.
     
        When a QNE receives a partial refresh message it compares the RSN
        against that of the currently installed reservation. If it matches
        then the state is refreshed. If the RSN in the message is less than
        that of the currently installed state (i.e. it refers to 'old' state)
        then the message is discarded (possibly the messages got reordered
        between the nodes). If the RSN in the message is greater than that of
        the currently installed state then an error MUST be signalled back.
        It means that the peer QNE believes that state is installed when it
        is not. If not informed it would continue to attempt to refresh the
        non-existent state. A partial refresh containing either an unknown
        session identifier or flow identifier MUST also be responded to with
        an error message (this is likely to occur following a rerouting
        event).
     
     4.3 Sending a response
     
        A QNE sending a RESERVE message may also request a RESPONSE message
        to be sent back to it. To do this it includes a ResponseRequest
        object with a RII object in it.
     
        When a node processes a received RESERVE message it should examine it
        to see if it contains a local ResponseRequest object. If it does,
        then a RESPONSE message is generated, and the contents of this object
        are copied into it. The local ResponseRequest object is removed from
        the RESERVE message being sent out.
     
        At the QNR, the processing of local ResponseRequest objects is
        carried out normally (this may happen before this QNE has determined
        that it is the QNR). If the RESERVE message received by the QNR
        contained a ResponseRequest object, then a RESPONSE message is
        created with the contents of the ResponseRequest object copied into
        it.
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 18]


                     NSLP for Quality-of-Service signaling    October 2003
     
     
        On receiving a RESPONSE message a QNE should check the contents of
        the ResponseRequest object echoed back to see if it contains an
        identifier supplied by it (the RII). If it does, then it should
        inspect the contents of the message and send it no further. This
        should always be the case for local ResponseRequest objects. If one
        of these is received with an incorrect identifier, then the RESPONSE
        must be discarded.
     
        For other QNR responses, the QNE may inspect the message and then
        must pass it back to the NTLP to be sent on.
     
        When a RESPONSE message reaches the edge of a stateless domain, the
        egress QNE will map/interchange the control information used by the
        "end to end" and "local" scope QoS model types. The generated LCI
        information will be encapsulated into the RESPONSE message. By using
        the stored SII of the ingress QNE the RESPONSE message will be sent
        to the particular ingress QNE node.
     
        Stateless and reduced state interior QNEs are not using the RESPONSE
        message.
     
        When the RESPONSE message is received by the ingress QNE node, the
        LCI information is used by the "local" scope QoS model. Afterwards,
        the LCI information is removed from the RESPONSE message, which is
        sent towards the QNI.
     
     4.4 Performing a query
     
        In order to perform a query along a path, a QNE constructs a QUERY
        message. The message must contain a ResponseRequest object in the
        same manner as described above to allow it to match any received
        RESPONSE messages back to the original QUERY. The QUERY message may
        contain general QoS NSLP query elements, as well as objects specific
        to a given QoS model. The message is then passed to the NTLP to be
        passed along the path.
     
        A QNE (including the QNR) receiving a QUERY message should inspect it
        and manipulate the general query objects and QoS model specific query
        objects as required. It then passes it to the NTLP for further
        forwarding unless it knows it is the QNR.
     
        At the QNR, a RESPONSE message is generated. Into this is copied the
        ResponseRequest object, and other general and QoS model specific
        information from the QUERY message. It is then passed to the NTLP to
        be forwarded peer-to-peer back along the path.
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 19]


                     NSLP for Quality-of-Service signaling    October 2003
     
        Each QNE receiving the RESPONSE message should inspect the
        ResponseRequest object to see if it contains an RII supplied by it.
        If it does not then it simply passes the message back to the NTLP
        unless it is a local RESPONSE. If it does, it uses the RII to match
        the RESPONSE back to the original QUERY, and performs any appropriate
        action based on the result of the query.
     
     4.5 Tearing down a reservation
     
        Although the use of soft state means that it is not necessary to
        explicitly tear down an old reservation, it is RECOMMENDED that QNIs
        send a teardown request as soon as a reservation is no longer needed.
        A teardown deletes reservation state and travels towards the QNR from
        its point of initiation. A teardown message may be initiated either
        by an application in a QNI or by a QNE along the route as the result
        of a state timeout or service preemption. Once initiated, a teardown
        message must be forwarded QNE peer - to - QNE peer without delay.
     
        A QNE can remove a reservation by building a RESERVE message with the
        'tear' indicator set to inform the next-hop QNE to remove the
        reservation state that it may hold. The tearing RESERVE is passed to
        the NTLP to be forwarded along the NEs up to the next-hop QNE. It is
        currently an open issue whether the tearing RESERVE will
        automatically tear down state in each NE. The next-hop QNE either
        tears down the corresponding reservation and passes on the tearing
        RESERVE, or, if it already has torn down the reservation, discards
        the message.
     
        In addition, the QNE should construct a NOTIFY message and attempt to
        send it back to the QNE that requested the reservation originally.
        The NOTIFY message will inform the other QNE that a reservation has
        been removed. On receipt of such a NOTIFY message a QNE should
        determine an appropriate course of action. This may include removing
        its own reservation state, and passing the NOTIFY message back
        further along the path.
     
        The attempt to send a NOTIFY message may be abandoned if the NTLP is
        not able to route the message along the reverse-path (e.g. because it
        has not stored the necessary state). In case of a stateless or
        reduced state domain, the ingress QNE of the domain will be notified
        by the egress QNE, which has kept track of its SII. The ingress QNE
        can then send the NOTIFY message further upstream. It can also
        initiate a scoped tearing RESERVE message towards the egress QNE.
     
     5. IANA section
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 20]


                     NSLP for Quality-of-Service signaling    October 2003
     
        This section provides guidance to the Internet Assigned Numbers
        Authority (IANA) regarding registration of values related to the QoS-
        NSLP, in accordance with BCP 26 [12].
     
        Future versions of this draft will identify name spaces in QoS-NSLP
        that require registration and contain recommendations for
        registration policies.
     
     6. Requirements for the NSIS Transport Layer Protocol (NTLP)
     
        For the moment this section will merely describe what we assume
        and/or request to be available from the NTLP. This section will later
        be updated to describe the eventual interface when NTLP work gets
        finalized.
     
     6.1 Support for stateless operation
     
        Stateless or reduced state QoS-NSLP operation makes the most sense
        when (some nodes of) the underlying NTLP is (are) able to operate in
        a stateless way as well. Such nodes should not worry about keeping
        reverse state, message fragmentation and reassembly (at the NTLP),
        congestion control or security associations. A stateless or reduced
        state QNE will be able to inform the underlying NTLP of this
        situation. We rely on the NTLP design to allow for a mode of
        operation that can take advantage of this information.
     
     6.2 Support for Source Identification Information (SII)
     
        There are several circumstances where it is necessary for a QNE to
        identify the adjacent QNE peer, which is the source of a signaling
        application message; for example, it may be to apply the policy that
        "state can only be modified by messages from the node that created
        it".
     
        We rely on the NTLP to provide this functionality. By default, all
        outgoing QoS-NSLP messages are tagged like this at the NTLP layer,
        and this is propagated to the next QNE, where it can be used as an
        opaque identifier for the state associated with the message; we call
        this the Source Identification Information (SII). The SII is
        logically similar to the RSVP_HOP object of [4]; however, any IP (and
        possibly higher level) addressing information is not interpreted in
        the QoS-NSLP. Indeed, the intermediate NTLP nodes could enforce
        topology hiding by masking the content of the SII (provided this is
        done in a stable way).
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 21]


                     NSLP for Quality-of-Service signaling    October 2003
     
        Keeping track of the SII of a certain reservation also provides a
        means for the QoS-NSLP to detect route changes. When a QNE receives a
        RESERVE referring to existing state but with a different SII, it
        knows that its upstream peer has changed. It can then use the old SII
        to send initiate a teardown along the old section of the path. This
        functionality would require the NTLP to be able to route based on the
        SII. We would like this functionality to be available as a service
        from the NTLP.
     
     6.3 Last node detection
     
        There are situations in which a QNE needs to determine whether it is
        the last QNE on the data path (QNR), e.g. to construct and send a
        RESPONSE message.
     
        A number of conditions may result in a QNE determining that it is the
        QNR:
     
        -  the QNE may be the flow destination
     
        -  the QNE have some other prior knowledge that it should act as
           the QNR
     
        -  the QNE may be the last NSIS-capable node on the path
     
        -  the QNE may be the last NSIS-capable node on the path
           supporting the QoS NSLP
     
        Of these four conditions, the last two can only be detected by the
        NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by
        providing a trigger to the QoS-NSLP when it determines that it is the
        last NE on the path, which supports the QoS-NSLP. It requires the
        NTLP to have an error message indicating that no more NSLPs of a
        particular type are available on the path.
     
     6.4 Re-routing detection
     
        This trigger is provided when the NTLP detects that the route taken
        by a flow (which the QoS-NSLP has issued signaling messages for) has
        changed.
     
     6.5 Performance requirements
     
        The QoS-NSLP will generate messages with a range of performance
        requirements for the NTLP. These requirements may result from a
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 22]


                     NSLP for Quality-of-Service signaling    October 2003
     
        prioritization at the QoS-NSLP (section 7.3.4) or from the
        responsiveness expected by certain applications supported by the QoS-
        NSLP.
     
        The NTLP design should be able to ensure that performance for one
        class of messages was not degraded by aggregation with other classes
        of messages. The different classes of performance requirements will
        be listed in future versions of this document.
     
     7. Open issues
     
     7.1 Refinements of this version
     
        Some topics raised in this document would benefit from more detailed
        discussion. These include:
        - description of the operation under re-routing conditions
        - description of the modification operation
        - description of the operation under error conditions
        - detailed discussion of message timer
        - detailed discussion of control information, more particularly
          message scoping
        - detailed discussion on the impact of a tearing RESERVE on state
          teardown at the NTLP
     
     7.2 Content for next (-02) version
     
        In addition to refining the discussion of topics currently described
        in this document, we intend the next version of this document to
        discuss the following issues.
     
     7.2.1 Sender/Receiver-initiated operation
     
        A sender-initiated reservation is made when the QNI for that flow is
        located upstream of the QNR with respect to the data path of the flow
        that is being signaled for. A receiver-initiated reservation is then
        made when the QNI is located downstream of the QNR with respect to
        the data path of the flow that is being signaled for. Note however,
        that the actual QoS-NSLP entities that initiate these signaling
        procedures can be anywhere along the data path, not just at the
        endpoints.
     
        There are signaling scenarios in which the receiver-initiated
        approach is more advantageous, while in others the sender-initiated
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 23]


                     NSLP for Quality-of-Service signaling    October 2003
     
        approach is required. QoS-NSLP stateless operation, for example, is
        only possible when the sender-initiated approach is applied.
     
        The next version of this draft will describe the use of sender-
        initiated and receiver-initiated reservations in the protocol. Note
        that the solution of this issue will also impact the way bi-
        directional reservations are supported (see Section 7.3.3).
     
     7.2.2 Message formats
     
        This version of the draft describes the functionality provided by the
        QoS-NSLP messages. Encoding this functionality into a message format
        is left for the next version.
     
     7.2.3Message flows
     
        This version of the draft briefly describes basic protocol operation.
        Future versions of this draft will include message flow diagrams for
        informative purposes (potentially in an appendix).
     
     7.3 Content for future (-0x) versions
     
     7.3.1 Aggregation
     
        Future versions of this document will describe the use of aggregation
        to reduce the signaling overhead (message bundling) and the routing
        state (similar to [13]).
     
     7.3.2 Tunnel management
     
        Future versions of this document will describe the use of QoS-NSLP
        over tunnels and the associated tunnel management.
     
     7.3.3 Bi-directional/proxy operation
     
        A future version of this draft will discuss the use of bi-directional
        reservations, i.e. combining the reservations for a pair of coupled
        flows going in opposite directions. The main difficulty here is that
        the two flows, although between the same end points, may traverse
        different paths across the Internet.
     
        Two proposals for tackling this are:
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 24]


                     NSLP for Quality-of-Service signaling    October 2003
     
        - generate both a sender initiated and a receiver-initiated
        reservation at the QNI (section 7.2.1), and allow them to be bundled
        together by the NTLP (the bundle can be split if the paths diverge).
        - generate a sender-initiated reservation that includes a request for
        the QNR to generate a sender-initiated reservation for the flow in
        the other direction.
     
        Both methods make some assumption about the flow routing. The first
        method requires that both flows pass through the same QNI. The second
        assumes that the QNR for one direction is on the path of the flow in
        the other direction.
     
        A future version will also include discussion on the operation of
        QoS-NSLP with (path-coupled) proxies.
     
     7.3.4 Priority and preemption
     
        The QoS-NSLP will generate messages with different priority.
        Prioritization at the level of the QoS-NSLP includes reservation
        priority and message priority.
     
        Reservation priority enables some reservations to be setup even if
        resources would normally not be available (e.g. for emergency
        services). This requires a priority indication in the message. Note
        that such an indication may be restricted to the QoS model scope,
        although every QoS model is expected to need this functionality.
        Whether resources are freed by means of pre-emption (the act of
        tearing down an existing reservation to free resource for a new one)
        or whether high-priority resources should be pre-provisioned is an
        implementation issue for the Resource Management Function.
     
        Message priority allows QoS-NSLP messages to be processed and
        forwarded in a different order than in which they arrived. This may
        be needed to ensure responsiveness to reservation requests or
        modifications (e.g. a reservation caused by a mobility event of an
        in-service session may need to be handled faster than a query or a
        new reservation request). This kind of prioritization should then be
        supported in the QoS-NSLP message set and may pose requirements on
        the NTLP (section 6.5).
     
        Future versions of this document will describe the support and use of
        prioritization for the QoS-NSLP.
     
     7.3.5 Network Address Translation (NAT)
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 25]


                     NSLP for Quality-of-Service signaling    October 2003
     
        Since the QoS-NSLP is used for requesting resources for data flows,
        the messages inevitably involve IP addresses and, possibly, port
        numbers. However, the addresses/ports of the data flow can be
        modified by Network Address Translators (NATs) along the path. It is
        hoped that some (or all) of this problem can be pushed down into the
        NTLP, so that only generic NSIS-awareness is required at the NAT,
        rather than requiring specific support for QoS-NSLP (as described in
        section 5.3 of [3]). Future versions of this document may contain
        additional discussion on this issue.
     
     7.3.6 Security components
     
     7.3.7 Mobility
     
        A future version of this draft will provide details on mobility
        support in QoS-NSLP, following the requirements in [2], [14]. A
        number of issues are associated with mobility support, such as
        localizing the new reservation to the new segment of the path,
        removing reservation state along the old segment of the path,
        recognizing a RESERVE message for an already established reservation
        although the IP address of the mobile node changed, possible
        concealment of QoS-NSLP messages due to IP-in-IP tunneling utilized
        in mobile IP, etc. Some of these issues can be solved by employing a
        session ID that is independent of the IP address, in addition to the
        flow ID (this has security implications, see [15]), and by supporting
        the SII and reservation sequence numbers. Some mobility support will
        be provided by NTLP, such as detection of route changes. More details
        are discussed in [16].
     
     8. Security Considerations
     
        The security of the NSLP is provided by a combination of security
        functions at the NTLP and NSLP. Subsequent versions of this draft
        will need to contain a specification of the NSLP security features,
        and how these interact with those at the NTLP.
     
        Some consideration of the problems can be found in [17][15][8]
     
     9. Change History
     
     10. Appendix A: A strawman QSpec template
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 26]


                     NSLP for Quality-of-Service signaling    October 2003
     
        This appendix describes a strawman QSpec template. The QSpec template
        could include objects and fields for conveying the following
        information:
     
        -  QSpec ID: This would allow IANA reservation of well known
           QSpec parameter combinations
     
        -  Traffic Envelope and traffic conformance (similar to RSVP's
           TSpec)
     
        -  Excess treatment: what happens to non-conforming traffic of a
           certain reservation (may be dropped but could be remarked as
           well)
     
        -  Offered guarantees: this may be delay, jitter, loss or
           throughput, both qualitatively (low delay) and quantitatively
           (delay < 100ms, optionally even with quantiles
           Note that the specification may support ranges of acceptable
           values
     
        -  Service schedule: for when is the service requested: this
           would allow a RESERVE/COMMIT functionality
     
        -  Reliability: what percentage of the time do you expect to get
           the offered guarantee (this will allow e.g. a local resource
           management function to map the traffic to an APS protected
           link)
     
        -  Monitoring requirements: what information do you require about
           the reservation. This is related to the AdSpec functionality
           and may contain parameters or sub object to be used in QUERY.
     
        Note that Flow identification information is also needed but that
        this is not assumed to be part of the QSpec template but rather
        available over the API between NTLP and QoS-NSLP.
     
        It is not the intention that all QoS models support all fields and
        sub objects defined here. The definition of a QoS model entails a
        selection of one or more of these fields and/or sub objects. For
        instance, one QoS model could only allow QSpec ID and DSCP to be
        specified.
     
     References
     
        1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
           Levels", BCP 14, RFC 2119, March 1997
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 27]


                     NSLP for Quality-of-Service signaling    October 2003
     
     
     
        2  M. Brunner, Ed., "Requirements for QoS signaling protocols."
           draft-ietf-nsis-req-09.txt, August 2003.
     
        3  R. Hancock, Ed., "Next Steps in Signaling: Framework", draft-ietf-
           nsis-fw-03.txt (work in progress), June 2003.
     
        4  Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
           "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
           Specification", RFC 2205, September 1997.
     
        5  Braden, B., Clark, D. and S. Shenker, "Integrated Services in the
           Internet Architecture: an Overview", RFC 1633, June 1994.
     
        6  Wroclawski, J., "The Use of RSVP with IETF Integrated Services",
           RFC 2210, September 1997.
     
        7  Tschofenig, H., "NSIS Authentication, Authorization and Accounting
           Issues", draft-tschofenig-nsis-aaa-issues-01 (work in progress),
           March 2003.
     
        8  Tschofenig, H., Buechli, M., Van den Bosch, S. and H. Schulzrinne,
           "QoS NSLP Authorization Issues", draft-tschofenig-nsis-qos-authz-
           issues-00 (work in progress), June 2003.
     
        9  S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, "An
           Architecture for Differentiated Services", RFC 2475, December
           1998.
     
        10 Metro Ethernet Forum, "Ethernet Services Model," letter ballot
           document, August 2003.
     
        11 Westberg, L., "Resource Management in Diffserv (RMD) Framework",
           draft-westberg-rmd-framework-04 (work in progress), September
           2003.
     
        12 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
           Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
     
        13 Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
           "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
           September 2001.
     
        14 H. Chaskar, "Requirements of a QoS solution for Mobile IP," RFC
           3583, Sept. 2003.
     
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 28]


                     NSLP for Quality-of-Service signaling    October 2003
     
     
        15 H. Tschofenig, H. Schulzrinne, et al., "Security implications of
           the session identifier" Internet Draft, June 2003.
     
        16 X. Fu, H. Schulzrinne, H. Tschofenig "Mobility Support in NSIS",
           Internet Draft, June 2003.
     
        17 H. Tschofenig and D. Kroeselberg, "Security Threats for NSIS",
           draft-ietf-nsis-threats-02.txt (work in progress), June 2003.
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 29]


     Acknowledgments
        This section will contain acknowledgments.
     
     Contributors
     
        This draft combines work from three individual drafts. The following
        authors from these drafts also contributed to this document: Robert
        Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
        Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
        Maarten Buechli (Dante) and Eric Waegeman (Alcatel).
     
     Contact information
     
        Georgios Karagiannis
        University of Twente
        P.O. BOX 217
        7500 AE Enschede
        The Netherlands
        email: karagian@cs.utwente.nl
     
        Andrew McDonald
        Roke Manor Research
        Old Salisbury Lane
        Romsey
        Hampshire
        SO51 0ZN
        United Kingdom
        email: andrew.mcdonald@roke.co.uk
     
        Sven Van den Bosch
        Alcatel
        Francis Wellesplein 1
        B-2018 Antwerpen
        Belgium
        email: sven.van_den_bosch@alcatel.be
     
     Full Copyright Statement
     
        Copyright (C) The Internet Society (2003). All Rights Reserved. This
        document and translations of it may be copied and furnished to
        others, and derivative works that comment on or otherwise explain it
        or assist in its implementation may be prepared, copied, published
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 30]


                     NSLP for Quality-of-Service signaling    October 2003
     
        and distributed, in whole or in part, without restriction of any
        kind, provided that the above copyright notice and this paragraph are
        included on all such copies and derivative works. However, this
        document itself may not be modified in any way, such as by removing
        the copyright notice or references to the Internet Society or other
        Internet organizations, except as needed for the purpose of
        developing Internet standards in which case the procedures for
        copyrights defined in the Internet Standards process must be
        followed, or as required to translate it into languages other than
        English.
     
        The limited permissions granted above are perpetual and will not be
        revoked by the Internet Society or its successors or assigns. This
        document and the information contained herein is provided on an "AS
        IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
        FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
        LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
        NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
        OR FITNESS FOR A PARTICULAR PURPOSE.
     
     
     Van den Bosch et al.     Expires - April 2004                [Page 31]
     

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