M. Brunner Internet Draft NEC Document: draft-brunner-nsis-ntlp-func-00.txt Expires: June 2003 December 2002 NSIS Transport Layer Protocol (NTLP) Functionality 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]. 1. 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 2. 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. 3. 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 4. 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. 5. 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