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]