M. Brunner
   Internet Draft                                                   NEC
   Document: draft-brunner-nsis-ntlp-func-00.txt
   Expires: June 2003                                     December 2002


            NSIS Transport Layer Protocol (NTLP) Functionality
                   <draft-brunner-nsis-ntlp-func-00.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.


Abstract

   This memo is a first step towards the design of a NSIS Transport
   Layer Protocol (NTLP). It lists protocol requirements, protocol
   design principles, and functional issues on the protocol level coming
   out of the NSIS requirements document[NSIS-REQ], the NSIS framework
   document [NSIS-FW], and several analysis documents. This list might
   be very near to implementation or solution already. The draft has
   been motivated by recommendations to list protocol requirements
   instead of higher level NSIS requirements as done in the NSIS
   requirements draft [NSIS-REQ].

. Introduction

   We assume that a two layer approach has been agreed upon. This
   document only deals with the general signaling layer also called the
   NSIS Transport Layer Protocol (NTLP) in [NSIS-FW].

   Its functionality should be general enough such that higher layer
   signaling applications or several different NSIS Signaling Layer
   Protocols (NSLP) can run on top of NTLP.



   Brunner               - Expires March 2003                        1

                        Towards RSVP Version 2           December 2002


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

. Requirements List

3.1. NTLP MUST Co-exist with RSVP Version 1

   We assume that RSVP Version 1 still will exist and can be used for
   several applications it has been designed for (IntServ, Multicast,
   ...)

   In the ideal case, NTLP SHOULD run dual-stack together with RSVP
   version 1.

3.2. NTLP MUST primarily work for Unicast

   We consider multicast an important feature of a signaling protocol,
   however for simplicity reasons unicast is of primarily interest. For
   multicasting RSVP Version 1 does a god job. We think that multicast
   support for homogeneous reservations and small groups can be regarded
   as an extension to be added to the protocol in a late step.

3.3. NTLP MUST use Soft State for State Management

   RSVP version 1 is a Soft State protocol, which means that information
   about the flows, reservations etc. is temporary saved along the path.
   Soft state gives adaptivity to route changes during the lifetime of a
   reservation and increases the protocol robustness to loss of
   messages. Besides, unexpected loss of connectivity from an end-point
   will simply lead to timeout states after some time along the path.
   These characteristics seem to be very important in many scenarios
   where a signaling protocol is used.

   NTLP MUST use Soft State. This implies it MUST have a refresh message
   type. However the information stored and refreshed is an issue for
   NSLP.

3.4. NTLS MUST signal Reservation Acceptance and Non-acceptance

   After sending a NTLP reservation request, the initiator MUST receive
   a positive or negative answer (acknowledgement or error
   notification).

3.5. NTLP MUST allow for optimistic behavior

   We refer to optimistic behavior in sender-oriented modes. Basically,
   after sending a reservation request the data sender can immediately
   state sending hoping that the reservation has been successful.



   Brunner                Expires March 2003                         2

                        Towards RSVP Version 2           December 2002


3.6. NTLP MUST signal error conditions

   NTLP MUST signal error conditions within the network to its NSIS
   initiator. And it MAY also send it to the NSIS Responders

3.7. NTLP MUST be service-independent

   Various NSLPs MUST run using the same base protocol.

3.8. NTLP MUST be optimized for "speed"


3.9. NTLP MUST be able to run over IP

   NTLP MUST run over IP only. This is the same as RSVP Version 1 does.
   It MAY run also over other transport protocols. A candidate for the
   transport protocol could be UDP.

3.10. Flow Identifier SHOULD be included in NTLP

   From the NSLP perspective, flow identification might be part of NSLP
   since it is also service-dependent.

   However, a flow identifier might be changed or looked at from other
   network boxes than routers. E.g., NAT need to change the flow
   identification if NTLP should work in these environments. Firewall
   function might use the flow identification for their blocking or
   passing decision.

3.11. A Reservation Identifier MUST be included in NTLP

   Each RSVP message MUST carry a Reservation Identifier to address the
   reservation it acts on.

3.12. Refreshing Intervals MUST be configurable

   Different environments need different types of refreshing, so the
   refreshing interval MUST be configurable. The granularity of
   configuration is open. In some cases, it MUST be configurable on a
   per reservation basis in other per NSIS entity is enough.

3.13. NTLP MUST avoid per-reservation timers in core nodes

   The protocol specification of NTLP MUST NOT force the implementation
   of per-reservation timers.

3.14. NTLP MUST have a message for explicit teardown

   NTLP MUST have a message for explicit end (teardown) of a
   reservation; this feature can be useful to avoid keeping resources
   allocated when they are not needed any longer.



   Brunner                Expires March 2003                         3

                        Towards RSVP Version 2           December 2002


3.15. NTLP MUST work without any state maintained on NSIS forwarders

   NTLP MUST be able to run without any state maintained in NSIS
   forwarders for the NTLP itself. If NSLP maintains state for its own
   purpose, NTLP MUST provides the mechanisms for it.

3.16. NTLP MUST use routing information also used for the data.

3.17. NTLP MUST support Sender- and Receiver Initiated

   Find definitions in of Sender- and Receiver Initiated Signaling in
   [NSIS-FW]

3.18. NTLP MUST support Uni-Directional and Bi-Directional Reservations

   Bi-Directional reservations MUST NOT follow the same path.

3.19. NTLP SHOULD support two-pass reservations

   NTLP MUST perform complex function in NSIS Initiator and/or NSIS
   Responders not in NSIS Forwarders

. References

   [NSIS-REQ] M. Brunner et al. (Editor) "Requirements for Signaling
   Protocols", draft-ietf-nsis-req-05.txt, 2002.

   [NSIS-FW] R. Hancock et al. (Editor), "Next Steps in Signaling:
   Framework, draft-nsis-fw-01.txt, 2002.

. Author's Addresses

   Marcus Brunner
   NEC Europe Ltd.
   Network Laboratories
   Kurfuersten-Anlage 34
   D-69115 Heidelberg
   Germany
   E-Mail: brunner@ccrle.nec.de















   Brunner                Expires March 2003                         4