Internet DRAFT - draft-brunner-nsis-ntlp-func
draft-brunner-nsis-ntlp-func
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].
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
