[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
   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]