Internet DRAFT - draft-westberg-nsis-rsvp-as-ntlp

draft-westberg-nsis-rsvp-as-ntlp







Internet Draft               RSVPv1 as NTLP                   March 2003


Internet Engineering Task Force                             L. Westberg
INTERNET-DRAFT                                           G. Karagiannis
Expires September 2003                                       V. Rexhepi
                                                               Ericsson
                                                             March 2003


   Using RSVPv1 as NTLP (NSIS Transport Layer Protocol): suggestions
                      for modifications on RFC2205
                draft-westberg-nsis-rsvp-as-ntlp-01.txt







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


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






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


Internet Draft               RSVPv1 as NTLP                   March 2003






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 desire of many to deploy technology to deliver services
   with different levels of quality of service (QoS) to their customers.
   The reasons for this are arguably well-understood and documented and
   are not the focus of this memo.  This memo is proposing a (NSIS
   Transport Layer Protocol) NTLP that is a modified version of RSVPv1
   specified in RFC2205.  Furthermore, it provides design guidelines and
   specifications for the development of the NLTP that is based on a
   modified version of RSVPv1.





































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


Internet Draft               RSVPv1 as NTLP                   March 2003






   Table of Contents


   1 Introduction .................................................    4
   1.1 Motivation of using RSVPv1 as NTLP  ........................    4
   1.2 Definitions/Terminology ....................................    5
   2 NTLP concept and features ....................................    8
   2.1 NTLP features ..............................................    8
   2.2 NTLP Message Formats .......................................    9
   2.2.1 Common Header ............................................   10
   2.2.2 Transport layer object formats ...........................   12
   2.3 NTLP concept ...............................................   14
   3 Suggestions for modifications on RFC2205 .....................   16
   4 References ...................................................   18
   5 Authors' Addresses ...........................................   19





























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


Internet Draft               RSVPv1 as NTLP                   March 2003






1.  Introduction

   A number of different QoS solutions have been developed by the IETF,
   amongst them IntServ and its signalling protocol, RSVPv1, defined in
   [RFC2205].  RSVPv1 [RFC2205] is a resource reservation signalling
   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.

   The NSIS WG uses the two-level architecture for Internet Signaling
   proposed in [BrLi01]:

      (1) a common lower level that performs transport-layer functions.
          This common lower level is denoted in [Hanco2] as
          NSIS Transport Layer Protocol (NTLP) that is a placeholder
          name for the NSIS protocol component that will support lower
          layer (signaling application independent) functions.
      (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
          signaling layer protocols denoted in [Hanc02] as NSIS Signaling
          Layer Protocol (NSLP).


   This memo outlines the main concept that is used by the proposed NTLP
   and provides guidelines and specifications for the modifications that
   have to be done in RFC2205 [RFC2205], such that RSVPv1 can be applied
   as NTLP.



1.1.  Motivation of using RSVPv1 as NTLP

   A great deal of effort was put into the specification and design of
   the RSVPv1 [RFC2205] protocol.  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.

   The main transport-layer features supported by RSVPv1 [RFC2205], such
   as support of unicast path-coupled signaling and soft state support
   have been proven in practice of being lightweight and robust.
   However, the multicast support introduces a level of complexity into
   the RSVPv1 protocol that is not needed in support of unicast
   applications.  For example, RSVPv1's state maintenance is complex as





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


Internet Draft               RSVPv1 as NTLP                   March 2003






   it needs to support dynamic membership changes in the multicast
   groups, such as reservation state merging and maintenance.

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

   Using RSVPv1 as NTLP will eliminate the need of reinventing solutions
   for transport-layer features. Furthermore, this will shorten the time
   needed to standardize NTLP by reusing the current RSVP design
   experience and RSVP protocol specification. Moreover, after minor
   modifications, existing RSVPv1 [RFC2205] implementations can be
   reused and used as NTLP, decreasing the deployment costs.

   Additional transport-layer features can be introduced in a modular
   way, either by adding them one by one as optional features into the
   NTLP specifications and implementations or using an existing protocol
   below NTLP that could provide these additional features.



1.2.  Definitions/Terminology


   Interdomain traffic:

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

   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 [Hanc02]):

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

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

     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.







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


Internet Draft               RSVPv1 as NTLP                   March 2003






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

     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:

     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 [Hanc02]):

     NSIS Entity that initiates NSIS signaling for a
     network resource.

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

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

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

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

   NSIS Transport Layer Protocol (NTLP) (identical to [Hanc02]):





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


Internet Draft               RSVPv1 as NTLP                   March 2003






     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

     NF entity that is NTLP stateful.

   NF NTLP stateless

     NF entity that is NTLP stateless.


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

      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





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


Internet Draft               RSVPv1 as NTLP                   March 2003






     can be considered as a NI or a NR.



   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.  NTLP concept and features


   As mentioned in Section 1 of this memo the NTLP performs transport-
   layer functions that are signaling application independent.


2.1.  NTLP features

   The NTLP provides the following subset of transport layer functions:

   * Support of Path-Coupled (Path-Directed) Signaling. The NTLP
     signaling messages are routed on the same path as the path
     followed by the data path. NTLP is not itself a routing protocol
     and it should be designed to operate with current and future
     routing protocols.  Similar to RSVPv1 [RFC2205], a NTLP process,
     consults the local routing database(s) to obtain routes.

   * Soft state support: This feature is similar to the soft state feature
     supported by RSVPv1 [RFC2205] and ensures that a state will be removed
     if it is not periodically refreshed or explicitly removed. This state is
     mainly used as a path state, where it maintains path-coupled routing
     information. The NTLP soft state, similar to RSVPv1, is created and
     periodically refreshed by Path and Resv messages.  This state, similar
     to RSVPv1, is deleted either if no matching refresh messages arrive
     before the expiration of a "cleanup timeout" interval, or may also be
     deleted by an explicit "teardown" message, i.e., PathTear or ResvTear.
     At the expiration of each "refresh timeout" period and after a state
     change, NTLP scans its state to build and forward Path and Resv refresh
     messages to succeeding hops.
     The state is globally and unique identified by a transport state
     identifier that is associated to a data flow and has to remain unchanged
     for the complete duration of the data flow. Moreover, for the duration of a
     data flow, the transport state  identifier remains the same while the





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


Internet Draft               RSVPv1 as NTLP                   March 2003






     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 transport state identifier associated with that data
     flow should not change. The RSVPv1 "Session" object can be applied as
     NTLP transport state ID.


   * Adaptation to load sharing. Load sharing allows NF interior
     nodes to take advantage of multiple routes to the same
     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 is able to exchange local information
     between NSIS Forwarders located within one single administrative
     domain.

   * In case of unexpected situations, e.g., errors, any NSIS Forwarder
     is able to  asynchronously generate a signaling message.

   * NTLP transports application layer (NSLP) "objects" that are
     opaque to NTLP.

   * NTLP provides transparent operation through routers that do not
     support it.

   * NTLP supports both IPv4 and IPv6.



2.2.  NTLP Message Formats

   NTLP uses the existing RSVPv1 signaling messages as NTLP transport
   protocol  messages. However, ResvConf is not anymore used, since the
   confirmation of a reservation is considered to be an application
   layer related feature.  The NTLP message types are: Path, Resv,
   PathErr, ResvErr, ResvTear. The main difference is related to the
   objects that will be carried by these messages, where the number of
   mandatory  objects is reduced substantially.

   The NTLP message, see Figure 1, 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





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


Internet Draft               RSVPv1 as NTLP                   March 2003






   layer (NSLP) "objects" are opaque and transparent to NTLP. A router
   implementation should create and read messages with the objects in
   the order shown in [RFC2205]. However, note that only a subset of the
   objects specified in [RFC2205] are needed in NTLP.


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

                     Figure 1: NTLP message format



2.2.1.  Common Header

   The common header, excluding the ResvConf message, is identical to
   the RSVPv1 Common header specified in [RFC2205].





















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


Internet Draft               RSVPv1 as NTLP                   March 2003






                   0             1              2             3
            +-------------+-------------+-------------+-------------+
            | Vers | Flags|  Msg Type   |       RSVP Checksum       |
            +-------------+-------------+-------------+-------------+
            |  Send_TTL   | (Reserved)  |        RSVP Length        |
            +-------------+-------------+-------------+-------------+



            The fields in the common header are as follows:

            Vers: 4 bits

                 Protocol version number.  This is version 1.

            Flags: 4 bits

                 0x01-0x08: Reserved

                      No flag bits are defined yet.

            Msg Type: 8 bits

                 1 = Path

                 2 = Resv

                 3 = PathErr

                 4 = ResvErr

                 5 = PathTear

                 6 = ResvTear



            RSVP Checksum: 16 bits

                 The one's complement of the one's complement sum of the
                 message, with the checksum field replaced by zero for the
                 purpose of computing the checksum.  An all-zero value
                 means that no checksum was transmitted.

            Send_TTL: 8 bits





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


Internet Draft               RSVPv1 as NTLP                   March 2003






                 The IP TTL value with which the message was sent.  See
                 Section 3.8.

            RSVP Length: 16 bits

                 The total length of this RSVP message in bytes, including
                 the common header and the variable-length objects that
                 follow.


2.2.2.  Transport layer object formats

   Similar to [RFC2205], every object consists of one or more 32-bit
   words with a one-word header, with the following format:

                   0             1              2             3
            +-------------+-------------+-------------+-------------+
            |       Length (bytes)      |  Class-Num  |   C-Type    |
            +-------------+-------------+-------------+-------------+
            |                                                       |
            //       (Transport layer object content)               //
            |                                                       |
            +-------------+-------------+-------------+-------------+

            An object header has the following fields:

            Length

                 A 16-bit field containing the total object length in
                 bytes.  Must always be a multiple of 4, and at least 4.

            Class-Num

                 Identifies the object class (see [RFC2205]); An NTLP
                 implementation must recognize the following classes:

                 NULL (as in [RFC2205])

                      A NULL object has a Class-Num of zero, and its C-Type
                      is ignored.  Its length must be at least 4, but can
                      be any multiple of 4.  A NULL object may appear
                      anywhere in a sequence of objects, and its contents
                      will be ignored by the receiver.

                 SESSION (as in [RFC2205])





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


Internet Draft               RSVPv1 as NTLP                   March 2003






                      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.  Required in every
                      NTLP  message. The "Session" object can be
                      applied as NTLP transport state ID.


                 RSVP_HOP (as in [RFC2205])


                      Carries the IP address of the NTLP aware node that
                      sent this message and a logical outgoing interface
                      handle (LIH).  This document refers
                      to a RSVP_HOP object as a PHOP ("previous hop")
                      object for downstream messages or as a NHOP (" next
                      hop") object for upstream messages.

                 TIME_VALUES (as in [RFC2205])

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



                 ERROR_SPEC (as in [RFC2205])

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


                 INTEGRITY (as in [RFC2205])

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



            C-Type

                 Object type, unique within Class-Num.  Values are defined
                 in [RFC2205].





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


Internet Draft               RSVPv1 as NTLP                   March 2003






2.3.  NTLP concept

   The NTLP protocol can be used for End-to-End, Edge-to-Edge, and End-
   to-Edge scenarios.  In the End-to-End scenario 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 NSIS framework shown in Figure 2 and Figure 3 is separated in two
   different levels. The lowest hierarchical level represents the NTLP
   level protocol and the higher hierarchical level represents the NSLP.
   Note that 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, the NF interior nodes of a
   domain can be either NTLP stateful nodes (see Figure 2) or, when
   processing optimisation is required, the NF interior nodes can be
   NTLP stateless nodes (see Figure 3).  The NF NTLP 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 NTLP
   protocol.  The interface between NTLP and NSLP can be based on an
   Application Program Interface (API) and its specification is ouf of
   the scope of this memo.






















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


Internet Draft               RSVPv1 as NTLP                   March 2003






   |------|   |-------|   |-------|   |-------|   |-------|   |------|
   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP |
   |      |   |       |   |       |   |       |   |       |   |      |
   |------|   |-------|   |-------|   |-------|   |-------|   |------|---
   |      |   |       |   |       |   |       |   |       |   |      | ^
   |      |   |       |   |       |   |       |   |       |   |      | |
   -------------------------------------------------------------------API
   |      |   |       |   |       |   |       |   |       |   |      | |
   |      |   |       |   |       |   |       |   |       |   |      | v
   |------|   |-------|   |-------|   |-------|   |-------|   |------|---
   | NTLP |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP  |<->| NTLP |
   |st.ful|   |st.ful |   |st.ful |   |st.ful |   |st.full|   |st.ful|
   |------|   |-------|   |-------|   |-------|   |-------|   |------|
      NI         NF          NF          NF          NF         NR
               (edge)     (interior)  (interior)   (edge)

   NTLP st.ful  : NTLP stateful

      Figure 2: NTLP/NSLP framework with stateful NF(interior) nodes































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


Internet Draft               RSVPv1 as NTLP                   March 2003






   |------|   |-------|   |-------|   |-------|   |-------|   |------|
   | NSLP |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP  |<->| NSLP |
   |      |   |       |   |       |   |       |   |       |   |      |
   |------|   |-------|   |-------|   |-------|   |-------|   |------|---
   |      |   |       |   |       |   |       |   |       |   |      | ^
   |      |   |       |   |       |   |       |   |       |   |      | |
   -------------------------------------------------------------------API
   |      |   |       |   |       |   |       |   |       |   |      | |
   |      |   |       |   |       |   |       |   |       |   |      | v
   |------|   |-------|   |-------|   |-------|   |-------|   |------|---
   | 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 3: NTLP/NSLP framework with stateless NF(interior) nodes


3.  Suggestions for modifications on RFC2205

   Based on the introduced features and concept presented in Section 2,
   we've gone through the RFC2205 to find out how much of the RSVPv1
   specification can be reused in changing RSVPv1 into an NTLP. We've
   seen that a lot of work and text available in RFC2205 can be re-used
   in specifying a modified version of RSVPv1 that can be used as NTLP.
   A list with such changes on RFC2205 is given below.

   RFC2205 table of contents:

   * Section 1 of RFC2205: Introduction - needs to be re-written
       1.1 Data Flows
       1.2 Reservation Model - needs to be re-written
                               to introduce the used transport model
       1.3 Reservation Styles - is not needed anymore as this is
                                Signaling Application specific
       1.4 Examples of Styles - is not needed anymore as this is
                                Signaling Application specific

   * Section 2 of RFC2205: RSVP Protocol Mechanisms
       2.1 RSVP Messages - minor changes are needed to emphasise
                           that these messages are mainly used for





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


Internet Draft               RSVPv1 as NTLP                   March 2003






                           transport layer functionality.
       2.2 Merging Flowspecs - is not needed anymore as this is
                               Signaling Application specific
       2.3 Soft State - needs to be changed such that it explains
                        transport state management functionality,
                        see Section 2 of this memo.
       2.4 Teardown -  needs to be changed such that it explains
                       transport state management functionality
       2.5 Errors - minor changes are needed to emphasize the
                    transport layer functionality
       2.6 Confirmation - is not needed anymore as this is
                           Signaling Application specific
       2.7 Policy Control - is not needed any more as this is
                            Signaling Application specific
       2.8 Security - minor changes are needed to emphasize the
                      transport layer functionality
       2.9 Non-RSVP Clouds - may remain the same
       2.10 Host model- we can reuse it, but we'll need to update
                        it to emphaise the transport layer
                        functionality

   * Section 3 of RFC2205: RSVP Functional Specification

       3.1 RSVP Message Formats - remains basically the same
            apart from the objects, i.e. the mentioned objects in
            Section 2 of this memo remain while the rest of the
            objects will be removed completely.
    .
    .

       3.2 Port Usage - remains the same
       3.3 Sending RSVP Messages - remains the same apart from the
           multicast part which we'll need to remove
       3.4 Avoiding RSVP Message Loops - remains the same. Here there
            is a paragraph that explains what to do when WF is used,
            which it could be removed.
       3.5 Blockade State - probably it could be removed, since the
                            blockade state can be considered as Signaling
                            Application specific
       3.6 Local Repair - minor changes are needed to emphasize the
                          transport layer functionality
       3.7 Time Parameters - minor changes are needed to emphasize the
                           transport state management and refresh
                           mechanisms.
       3.8 Traffic Policing and Non-Integrated Service Hops - is not





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


Internet Draft               RSVPv1 as NTLP                   March 2003






                      needed as it is Signaling Application
                      specific, i.e., Intserv specific
       3.9 Multihomed Hosts - may be reused
       3.10 Future Compatibility remains the same
       3.11 RSVP Interfaces - it will either be completely removed
                      or it will be changed to define new API interfaces
                      to the signaling application layer (NSLP).

   * Section 4 of RFC2205: Acknowledgements
                 needs of course to be re-written

   * APPENDIX A. Object Definitions - needs to be changed, according
                 to the details provided in Section 2 of this memo.

   * APPENDIX B. Error Codes and Values - most error codes and values
                 will remain the same. However, new error codes and values
                 might be defined.

   * APPENDIX C. UDP Encapsulation - remains the same

   * APPENDIX D. Glossary - needs to be updated accordingly with the
                 changes in the document
   * REFERENCES - need to be updated accordingly




4.  References

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

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


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





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


Internet Draft               RSVPv1 as NTLP                   March 2003






5.  Authors' Addresses

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

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

   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 September 2003                [Page 19]