NSIS working group
Internet Draft M. Buchli
E. Waegeman
S. Van den Bosch
Document: draft-buchli-nsis-ntlp-00.txt Alcatel
Expires: December 2003 June 2003
Implementation of CASP NTLP
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 document describes the implementation of a signaling protocol
based on the two protocol layer concept of NSIS. The implementation
of the transport layer is based on the CASP proposal and is
discussed in this document. The design of a client layer for QoS
signaling is detailed in a separate document.
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 [2].
Table of Contents
Buchli et al. Expires - December 2003 [Page 1]
Implementation of CASP NTLP June 2003
1. Terminology....................................................2
2. Introduction...................................................2
3. Transport layer................................................3
3.1 Route changes..............................................4
3.2 Interaction with client layer..............................4
3.3 Flow ID....................................................4
3.4 State management...........................................4
Security Considerations...........................................5
References........................................................5
Author's Addresses................................................6
1. Terminology
The terminology used in this document is aligned with [3].
2. Introduction
We have implemented a signaling protocol according to the two-layer
protocol model of NSIS. It consists of a generic transport layer
(NTLP) and an application specific layer (NSLP).
The implemented NTLP is a modified version of the CASP transport
layer protocol as specified in [4]. The aim of this document is to
provide the design choices made for the NTLP protocol. The design of
the QoS signaling protocol that has been implemented is documented
separately in [5].
The protocol layer model is depicted in figure 1. As depicted,
certain functionalities of the transport layer can be implemented by
existing (and proven) protocols to provide e.g. reliable delivery
and security.
+=========================================+
| |
| Client layer (NSLP) |
| |
+=========================================+
| | -
| Transport layer | \
|.........................................| |
| [security protocols (IPSec, TLS)] | | NTLP
|.........................................| |
| transport protocol (TCP, SCTP) | /
+=========================================+ -
| IPv4, IPv6 |
+=========================================+
Buchli et al. Expires - December 2003 [Page 2]
Implementation of CASP NTLP June 2003
Figure 1:Protocol layer model
As mentioned before, the transport layer is a modification of the
CASP proposal [4]. The main differences are:
o The transport layer only detects route changes and triggers the
NSLP. The NSLP is in full control of executing the required
actions upon the route change notification.
o Only one NSLP type can be associated to a transport session.
o Each node involved with a session should support the NSLP. Hence,
in case of a route change there is always an NSLP in place that
can react on the route change. Furthermore, much of the required
security functionality can be incorporated at the NTLP.
o The Flow ID is defined by the source and destination address. This
allows for multiple flows within a single session between two end
hosts.
o Only SCTP and TCP are considered as transport protocols in order
to provide reliable delivery, fragementation, congestion control,
etc. Hence, raw IP and UDP are not considered for transport.
3. Transport layer
The implementation of the transport layer is derived from the
specification of [4]. Some functionalities are not considered, are
specific to our usage scenario or will be implemented in a later
stage.
Not considered for implementation:
- In-band discovery by means of SCOUT messages. When, in a later
stage, dynamic discovery will be implemented a directory based
approach will be used.
Not required for our usage scenario:
- Currently, only a QoS signaling client layer is considered. Fate
sharing is assumed between the transport and client layer. The
soft state mechanism is located in the transport layer; the client
layer does not have a notion of refresh messages.
Functionality to be added in future versions:
- Security features, these may be provided by existing security
protocols such as IPSec.
- Dynamic discovery of neighbors; currently, the neighbor
information is configured statically.
Buchli et al. Expires - December 2003 [Page 3]
Implementation of CASP NTLP June 2003
The design choices for the transport layer protocol are elaborated
in some more detail below.
3.1 Route changes
o Route changes are detected by the transport layer but the actions
to respond to the route change and the removal of transport/client
state on the old path is the task of the client layer. Indeed,
this provides the client layer full control to implement
application specific actions to react to a route change; e.g. when
to release the state on the old path.
3.2 Interaction with client layer
o The number of client layers associated with a transport session is
restricted to one. This avoids the transport layer having to
determine when all client layers have finished the processing of a
route change before the transport layer may release the transport
state on the old path. By allowing only one client per session the
client layer has full control in case of a route change.
o When a session is setup each signaling node involved with that
session should support the particular client layer. This is
due to the following reasons:
- Route changes can be handled by the client layer at the node
where the route change was detected. It avoids the need for
signaling to an upstream signaling node, which supports the
specific client layer, to trigger the necessary actions for a
route change.
- Security and keep-alive mechanisms can be constraint to a hop-
by-hop scope, and hence, can be implemented at the transport
layer. However, objects that require e.g. end-to-end protection
may be protected at the client layer.
3.3 Flow ID
o The flow at the transport layer is only defined by the source and
destination IP address. The client layer may handle more
specific flow information, e.g. port numbers and protocol
identifier. This allows to support multiple flows within the same
session between two end hosts.
o At the client layer, multiple source/destination ports may be
specified for each session.
3.4 State management
Buchli et al. Expires - December 2003 [Page 4]
Implementation of CASP NTLP June 2003
o Soft state management is considered a generic functionality, and
hence, included in the transport layer. Only the transport state
is refreshed, not the client objects. In case the soft state times
out the transport layer will trigger the client layer. The client
layer is responsible for discarding the state.
In order to support soft state at the transport layer an
additional bit is defined in the common header as defined in
section 4.2 of [4]. Bit 4 of the flag field is designated as
the refresh bit. This bit is set to æ1Æ to indicate a refresh
message; otherwise it should be set to æ0Æ.
The refresh message has the refresh bit set and contains one or
more session ids that need to be refreshed. The number of sessions
to be refreshed can be derived from the message length. The
refresh interval between two neighboring signaling nodes is fixed.
o The transport layer will maintain the following state for each
session:
1. Previous / next NSIS Entities, for each previous/next hop a
branch is created. Multiple branches may exist e.g. in case of
route changes.
2. Flow identifier, consisting of a source and destination IP
address.
3. Session identifier, this should be a global unique number used
to identify state.
4. Client type, which specifies the client that is associated with
the transport state. Note that only one client is allowed per
session.
Security Considerations
The transport layer provides hop-by-hop security. It should allow
for at least authentication and message integrity between
neighboring signaling nodes. Confidentiality (i.e. encryption) may
be desirable. In order to provide the required functionality
existing (and proven!) security mechanisms such as IPSec or TLS
should be used.
References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
Buchli et al. Expires - December 2003 [Page 5]
Implementation of CASP NTLP June 2003
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and Van
den Bosch, S., "Next steps in signaling: Framework", Internet
Engineering Task Force, draft-ietf-nsis-fw-02.txt, work in
progress, March 2003.
4 Schulzrinne, H., Tschofenig, H., Fu, X., McDonald, A., "CASP -
Cross-Application Signaling Protocol", draft-schulzrinne-nsis-
casp-01.txt, work in progress, March 2003.
5 Buchli, M., Waegeman, E., Conte, A., "A Network Service Layer
Protocol for QoS signaling", draft-buchli-nsis-nslp-00.txt, May
2003.
Author's Addresses
Maarten Buchli
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, BELGIUM
Phone: +32 3 240 7081
Email: maarten.buchli@alcatel.be
Eric Waegeman
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, BELGIUM
Email: eric.waegeman@alcatel.be
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen, BELGIUM
Email: sven.van_den_bosch@alcatel.be
Buchli et al. Expires - December 2003 [Page 6]