INTERNET-DRAFT Venkatesh Selvaraj Prasanna Kumar M V Motorola Expires June 2001 December 12, 2000 SCTP Dedicated Management Connection Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. To learn the current status of any Internet-Draft, please check the '1id-abstracts.txt' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Selva & Prasanna [Page 1] Internet Draft SCTP Dedicated Management Connection December 2000 Abstract This Internet Draft defines a Dedicated Management Connection between Upper Layer Management entity and Stream Control Transmission Protocol (SCTP)[1] on any Network Element using SCTP. The Dedicated Management Connection provides an interface for upper Layer Management entity to obtain different types of events pertaining to all SCTP associations that exist from host network element to peer network elements. It also provides a mechanism for tuning stack specific parameters,dynamic IP address addition[2] and collecting debug,status,trace and diagnostic informations. Selva & Prasanna [Page 2] Internet Draft SCTP Dedicated Management Connection December 2000 TABLE OF CONTENTS 1. Introduction............................................. 4 1.1 Scope................................................. 4 1.2 Terminology........................................... 5 1.3 Abbreviations......................................... 6 1.4 DMC Architecture...................................... 6 2. Dedicated Management Connection.......................... 7 2.1 Management of SCTP Associations ....................... 7 2.1.1 Registration/deregistration of SCTP Events ....... 7 2.1.2 Tearing down associations......................... 8 2.1.3 Status Query...................................... 8 2.2 Trace ................................................. 8 2.3 Diagnostics ........................................... 9 2.4 SCTP Stack Parameters tuning .......................... 9 2.5 Debug ................................................. 9 2.6 Dynamic IP address Addition ........................... 9 3. DMC Interface ............................................ 10 3.1 ULME to SCTP Interface ................................ 10 3.2 SCTP to ULME Interface ................................ 17 4. References............................................... 18 5. Author's Addresses....................................... 18 Selva & Prasanna [Page 3] Internet Draft SCTP Dedicated Management Connection December 2000 1. Introduction 1.1 Scope SCTP is used as the transport protocol for various PSTN and other Signaling information transfer over IP. In most applications the resources allocated by the upper layer are tied to the SCTP associ- ations. So it is required to monitor those associations by an upper layer entity.For e.g. if the association breaks the network element may have to deallocate the corresponding resources and try to do some recovery actions for that association. Also using a Local Maintenance Terminal(LMT) the operator would be interested in performing some query or carry out some maintenance activities (like shutting down an association) on the associations. There is a need for a dedicated connection which serves as an interface between SCTP stack and upper layer management entity. The Upper Layer Management entity can receive SCTP events,status,debug, diagnostic information etc., through this dedicated management connection (DMC).This draft talks about the Dedicated Management Connection which can act as an interface between a Management application (a.k.a ULME) and the SCTP stack.This interface provides a means for an Upper Layer Management application to carry out OAM&P activities. In the absence of this DMC, it is the responsibility of each upper Layer entity to report the SCTP events to a management entity. This means each SCTP event from SCTP stack, corresponding to an Upper Layer entity, will have two hops before reaching the management entity.Whereas in case of DMC an SCTP event is transferred directly to the management entity. Moreover the applications need to implement some kind of interprocess communicatio n and some sort of protocol,which will complicate the architecture. In addition to this, DMC provides an interface for the Upper Layer management entity to tune certain SCTP Stack specific parameters for e.g., number of Associations, IP Address List etc. DMC can also be used for Dynamic IP address addition and deletion[2]. The Dedicated Management Connection can * Support management of all SCTP transport associations. * Support asynchronous reporting of status changes to management. * Support subscription and un-subscription to any or all SCTP events. * Support Status Query for any or all associations * Support for a tearing down a particular or all associations. Selva & Prasanna [Page 4] Internet Draft SCTP Dedicated Management Connection December 2000 * Support trace of communication over any SCTP association. * Support diagnostic information transfer. * Support of tuning SCTP stack specific parameters. * Support of dynamic IP address addition and deletion[2]. 1.2 Terminology Some of the Key Terminologies used in SCTP[1] and/or in this document have been provided here. SCTP End Point (SEP): The logical sender/receiver of SCTP packets.On a multi-homed host, an SCTP endpoint is represented to its peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an SCTP endpoint must not be used by another SCTP endpoint. In other words, a transport address is unique to an SCTP endpoint[1]. SCTP user application (SCTP user): The logical higher-layer application entity which uses the services of SCTP, also called the Upper-layer Protocol (ULP)[1]. Transport address: A Transport Address is traditionally defined by Network Layer address, Transport Layer protocol and Transport Layer port number. In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and an SCTP port number(where SCTP is the Transport protocol)[1]. Association : An association refers to a SCTP association [1]. The association provides the transport for ULP[1]. Upper Layer Management Entity(ULME): The logical higher-layer application entity that manages all SCTP associations on the host Network Element or node. Stream: A stream refers to a SCTP stream [1]. SCTP packet (or packet): The unit of data delivery across the interface between SCTP and the connectionless packet network Selva & Prasanna [Page 5] Internet Draft SCTP Dedicated Management Connection December 2000 (e.g., IP). An SCTP packet includes the common SCTP header, possible SCTP control chunks, and user data encapsulated within SCTP DATA chunks [1]. Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content[1]. 1.3 Abbreviations API - Application Programming Interface DMC - Dedicated Management Connection LMT - Local Maintenance Terminal. An interface to the operator to perform some maintenance activities on the system. OAM&P - Operation Admission Maintenance and Performance. Refer ETSI TMN specification for more details. SCTP - Stream Control Transmission Protocol ULP - Upper Layer Protocol ULME - Upper Layer Management Entity 1.4 Architectural View of DMC _______ ______ |SCTP || | |User ||ULME | |(ULP) || | |______||_____| ^ ^ SCTP | | SCTP Association | | DMC v V |-------------| | SCTP | | Transport | | Service | |-------------| | |One or more | IP Network |IP address | Service |appearances |_____________| SCTP Node Figure 1: SCTP DMC Selva & Prasanna [Page 6] Internet Draft SCTP Dedicated Management Connection December 2000 Fig(1) gives a schematic representation of Dedicated Management Connection(DMC) to SCTP. SCTP Transport indicates SCTP protocol instance. SCTP User represents an Upper Layer application. ULME is another upper layer application that monitors all SCTP associations of a specific SCTP User or all SCTP Users. ULME can be a part of each SCTP user or there can be a centralized ULME for all SCTP users on that network element/node. This is implementation dependent. Section 2 of this document details the services and functions supported by the DMC and Section 3 of this document sketches an API that should exist for a DMC between ULME and SCTP. NOTE: DMC exist between SCTP stack and ULME on the local node and DMC is NOT visible to peer nodes. 2. Dedicated Management Connection The type of interface between the SCTP stack and the ULME is dependent upon the implementation. There could be zero or more such interface. The interface could be implemented in such a way that only privileged user applications can open such an interface. For e.g. in Unix systems, only applications which run as root(i.e. with UID / EUID equal to 0) could open such an interface. The advantage of this is to restrict unauthorized application from changing the stack parameters. The SCTP could reserve a port for the DMC. In that case this port could not be used for communication with the peer nodes. The implementation could choose a different method also to differentiate between a normal connection and a Dedicated Management Connection. For e.g. in TLI/XTI kind of interface, two different device files (/dev/sctp & /dev/sctp_dmc) could be used to differentiate a normal connection and a DMC. 2.1 Management of SCTP Associations The management of SCTP associations includes monitoring the list of active associations, tearing down a particular or all associations,status query for all or for a particular association. Monitoring an association requires subscribing for asynchronous events like COMMUNICATION UP , COMMUNICATION LOST , COMMUNICATION ERROR , RESTART [1] notifications from the SCTP stack for selected or for all the associations. 2.1.1 Registration/Deregistration of SCTP Events The ULME shall send a REGISTER_ASSOCIATION_EVENTS (Refer Section 3.1 for details) command to the SCTP stack to Register/Deregister for the asynchronous SCTP events. The REGISTER_ASSOCIATION_EVENTS Selva & Prasanna [Page 7] Internet Draft SCTP Dedicated Management Connection December 2000 Command can optionally carry the association id if the subscription/unsubscription is needed for a particular association. If no association id is sent then the events for all the associations will be subscribed/unsubscribed. Also the REGISTER_ASSOCIATION_EVENTS command can optionally carry the list of events(e.g. COMMUNICATION UP) to be subscribed/unsubscribed. If no events are specified then all asynchronous events will be subscribed/unsubscribed. The stack shall send REGISTER_ASSOCIATION_EVEENTS_ACK / ERROR based on the success or failure of the subscription/unsubscription. 2.1.2 Tearing down associations The ULME can tear down a particular association or all the associ- ations. The ULME shall either send a SHUTDOWN[1] or SHUTDOWN_ALL (Refer to Section 3.1) to the SCTP stack to do a graceful termination of a particular or all associations respectively. Similarly ULME shall either send a ABORT[1] or ABORT_ALL (Refer section 3.1) to SCTP Stack to do an ungraceful termination of a particular or all associations respectively. The ULME can use this command if it wants to perform some maintenance on the network element. 2.1.3 Status Query The ULME can perform a status query to get the details about existing SCTP associations. The ULME shall either send a STATUS[1] or STATUS_ALL(Refer Section 3.1) command to SCTP to get this information for a particular association or all associations respectively. The ULME can present this information to the operator or can perform some actions based on the values received. 2.2 Trace The ULME could perform a trace of the packets transmitted or received. The trace information can contain the actual packet transmitted/received, transport address of the local and that of the peer used for transmission/reception etc.The trace information could be collected by the stack and sent over periodic intervals. The ULME shall send a CHANGE_TRACE command (Refer to Section 3.1) to the SCTP stack to enable or disable the trace option. This command can optionally carry the association id if the trace is requested for a particular association. If association id is not present the trace information shall be enabled or disabled for all the associations. Selva & Prasanna [Page 8] Internet Draft SCTP Dedicated Management Connection December 2000 2.3 Diagnostics The ULME could register or deregister for the diagnostic information such as total number of chunks transmitted/received, timeouts,checksum error etc. These diagnostic information could be collected by the stack and updated at periodic intervals. The ULME shall send a REGISTER_DIAGNOSTICS command(Refer to section 3.1) to the stack to register or deregister for the diagnostic information. The command could optionally carry the association id if the diagnostic information is requested for a particular association. If the association id is not present then the diagnostic information for all the associations will be considered. 2.4 SCTP Stack Parameters tuning The ULME could change the value of certain parameters used by the SCTP. Some of these parameters include SCTP timer values, maximum number of associations, maximum number of inbound/outbound streams, buffer sizes, etc. The SCTP shall send a TUNE_PARAMETER (Refer Section 3.1) command to the stack to change the value of a particular parameter. The command shall carry the parameter that is to be changed and the new value. Note : These are parameters that are common to all associations i.e. these are stack specific parameters. 2.5 Changing the Debug level The ULME could turn on and change the debug levels at runtime. The SCTP stack could implement different debug levels (for e.g. level0 - no debug, level1 - all SCTP messages exchanged between the peers, level 2 - messages exchanged between ULP and SCTP and the corresponding functions called and attributes passed, level3 - internal buffers sizes, etc) for different kinds of debug information. The ULME would send a CHANGE_DEBUG_LEVEL command(Refer to Section 3.1) with the debug level and the option to turn ON or turn OFF the debug to the SCTP stack. The stack would respond back with a success or a failure. 2.6 Dynamic IP address Addition/deletion The ULME could perform the dynamic IP address addition/deletion [2] through the DMC. The ULME would send ADD_IP_ADDRESS or DELETE_IP_ADDRESS command (Refer to Section 3.1) to the SCTP stack. The command would carry the IPV4 or IPV6 address that has to be added or deleted. The SCTP stack shall send a success or failure message to the ULME upon completion of the addition / deletion. Selva & Prasanna [Page 9] Internet Draft SCTP Dedicated Management Connection December 2000 3. DMC Interface The Upper Layer Management Entity(ULME) shall register for services by passing Registration primitives over DMC to SCTP. ULME shall receive asynchronous and synchronous notifications from SCTP. Synchronous notifications are sent in response to requests and queries made by ULME. 3.1 ULME-to-SCTP This section defines ULME to SCTP interface for various applications. The primitives described below help in inter-process communication between DLME and SCTP. In addition to the primitives described in this section, ULME uses many of the primitives described by [1]. A) Status of All Associations Format: STATUS_ALL(local SCTP instance name) -> Associations Data This primitive allows ULME to request SCTP to provide him with details of all existing associations for the specified SCTP instance. This can be the first primitive ULME sends to SCTP after ULME is initialized or ULME can use this any time to get the latest information on all existing SCTP association for this SCTP instance to update its database. For e.g., there can be mismatch between ULME and SCTP databases for various reasons. This primitive should return blocks of data containing the following information for each SCTP association in this SCTP instance: association id association connection state, destination transport address list, destination transport address reachability states, current receiver window size, current congestion window sizes, number of unacknowledged DATA chunks, number of DATA chunks pending receipt, primary path, most recent SRTT on primary path, RTO on primary path, SRTT and RTO on other destination addresses, etc. Selva & Prasanna [Page 10] Internet Draft SCTP Dedicated Management Connection December 2000 Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. Optional Attributes: None. B) Register for Association Events Format: REGISTER_ASSOCIATION_EVENTS (local SCTP instance, [association id],[event names], new value) -> result This primitive allows ULME to register with SCTP stack for a specific SCTP event or all SCTP events for a specific association or all associations of an SCTP instance. SCTP shall respond with a result code which may indicate a Successful or unsuccessful registration. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. This indicates that SCTP shall provide DLME with asynchronous events specified by [event names] for the association of this SCTP instance specified by [association id]. * new value - This attribute indicates SCTP to either REGISTER or DE-REGISTER for events with SCTP. Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. * event names - one or more of the asynchronous events defined by the SCTP-to-ULME primitives . This attribute not present implies all asynchronous events for an SCTP association. Asynchronous events include Selva & Prasanna [Page 11] Internet Draft SCTP Dedicated Management Connection December 2000 NETWORK STATUS CHANGE notification[1], COMMUNICATION UP notification[1], COMMUNICATION LOST notification [1], COMMUNICATION ERROR notification[1], RESTART notification[1], SHUTDOWN COMPLETE notification[1] C) SHUTDOWN All SCTP Associations Format: SHUTDOWN_ALL (local SCTP instance) -> result This is similar to SHUTDOWN primitive described in [1] except that SHUTDOWN_ALL does graceful termination of ALL SCTP association Connected with this SCTP instance. Mandatory attributes: * local SCTP instance name- Obtained from INITIALISE operation[1]. D) ABORT All SCTP Associations Format: ABORT_ALL (local SCTP instance [,cause code]) -> result This is similar to ABORT primitive described in [1] except that ABORT_ALL does ungraceful termination of ALL SCTP association connected with this SCTP instance. Mandatory attributes: * local SCTP instance name- Obtained from INITIALISE operation[1]. Optional attributes: * cause code - reason of the abort to be passed to the peer. E) Register Diagnostics Format: REGISTER_DIAGNOSTICS (local SCTP instance, [association id], new value) -> result This primitive allows ULME to register with SCTP for periodic diagnostic information update for a specific association or all associations of a SCTP instance. Selva & Prasanna [Page 12] Internet Draft SCTP Dedicated Management Connection December 2000 SCTP shall respond with a result code which may indicate a successful or unsuccessful registration. DIAGNOSTIC information may include: total number of Chunks transmitted and received, total number of Control Chunks transmitted and received, total number of DATA Chunks transmitted and received, total number of Chunks in error etc., NOTE: It is left to the SCTP and ULME implementation to define the Method for communicating these DIAGNOSTIC information from SCTP to ULME. It can either be through a primitive from SCTP-to-ULME or logged into a storage file. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. This indicates that SCTP shall provide DLME with diagnostic information specified for the association of this SCTP instance specified by [association id]. * new value - This attribute indicates SCTP to either ENABLE or DISABLE generation of DIAGNOSTIC information. Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. F) Change Trace Format:CHANGE_TRACE(local SCTP instance,[association id],new value) -> result This primitive allows ULME to instruct SCTP for to enable or disable TRACE for the association specified by [association id]. SCTP shall respond with a result code which may indicate a Successful or unsuccessful operation. SCTP shall generate TRACE information for each packet transmitted or received. The TRACE information may include the actual packet Selva & Prasanna [Page 13] Internet Draft SCTP Dedicated Management Connection December 2000 transmitted or received and actual destination transport address used etc,. Implementation may include any other required information. NOTE: It is left to the SCTP and ULME implementation to define the method for communicating these TRACE information from SCTP to ULME. It can either be through a primitive from SCTP-to-ULME or logged into a storage file. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. This indicates that SCTP shall provide DLME with TRACE information for the SCTP association specified by [association id] of this SCTP instance . * new value - new state of TRACE for this SCTP instance or association which will either ENABLE or DISABLE generation of TRACE information. Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. G) Tune Protocol Parameters Format: TUNE_PARAMETERS(local SCTP instance, protocol parameter,new value) -> result This primitive allows the local SCTP to customize the stack specific protocol parameters. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. * protocol parameter list - The specific names of the protocol parameters (e.g., Max number of Outbound Streams, Max number of Associations) that ULME wants to change. * new value - new value of the protocol parameter to be changed. Selva & Prasanna [Page 14] Internet Draft SCTP Dedicated Management Connection December 2000 Optional attributes: None. H) Change Debug Level Format: CHANGE_DEBUG_LEVEL (local SCTP instance,[association id], debug option, debug level) -> result This primitive allows ULME to instruct SCTP for to change the debug level for the association specified by [association id]. SCTP shall respond with a result code which may indicate a Successful or unsuccessful operation. SCTP shall generate DEBUG information based on the DEBUG LEVEL set by ULME. NOTE: It is left to the SCTP and ULME implementation to define the method for communicating these DEBUG information from SCTP to ULME. It can either be through a primitive from SCTP-to-ULME or logged into a storage file. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. This indicates that SCTP shall provide DLME with DEBUG information for the SCTP association specified by [association id] of this SCTP instance. * debug option - Turn ON or Turn OFF the debug option. * debug level - new debug level for this whole SCTP instance or an SCTP association. E.g. level0, level1 etc. Note: If the debug level is set to 0 then the value in debug option will be ignored. Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. Selva & Prasanna [Page 15] Internet Draft SCTP Dedicated Management Connection December 2000 I) Add IP Address [2] Format: ADD_IP_ADDRESS (local SCTP instance [,association id], IP address) -> result This primitive allows ULME to instruct SCTP to add one more IP address to the list of IP addresses for the association specified by [association id]. SCTP shall respond with a result code which may indicate a successful or unsuccessful operation. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. * IP address - This contains actual IP address and its type information(IPv4 or IPv6 , Type value etc) Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. J) Delete IP Address [2] Format: DELETE_IP_ADDRESS (local SCTP instance [,association id],IP address) -> result This primitive allows ULME to instruct SCTP to delete an IP address from the list of IP addresses for the association specified By [association id]. SCTP shall respond with a result code which may indicate a successful or unsuccessful operation. Mandatory attributes: * local SCTP instance name - Obtained from INITIALISE operation[1]. * IP address - This contains actual IP address and its type Information (IPv4 or IPv6 , Type value etc) Selva & Prasanna [Page 16] Internet Draft SCTP Dedicated Management Connection December 2000 Optional attributes: The following types of attributes may be passed along with the primitive: * association id - local handle to a specific SCTP association [1]. This attribute not present implies all associations of an SCTP instance. ULME can use one or more of the following ULP-to-SCTP primitives described in [1] for providing services explained in Section 2 of this document: Change Heartbeat [1] Request HeartBeat [1] Set Protocol Parameters [1], Set Failure Threshold [1], Status [1], Shutdown [1], Abort[1], Destroy SCTP instance [1] 3.2 SCTP-to-ULME SCTP-to-ULME communication requires support from application environment or Operating System to provide methods to interface with ULME for sending SCTP events. ULME uses one or more of the following SCTP-to-ULP primitives described in [1] for providing services explained in Section 2 of this document: NETWORK STATUS CHANGE notification[1], COMMUNICATION UP notification[1], COMMUNICATION LOST notification [1], COMMUNICATION ERROR notification[1], RESTART notification[1], SHUTDOWN COMPLETE notification[1] In addition to this, SCTP-to-ULME communication includes passing complete SCTP Association information as requested by STATUS_ALL and STATUS primitives mentioned in Section 3.1. It also involves passing TRACE, DIAGNOSTIC and DEBUG information as requested by REGISTER_DIAGNOSTICS, CHANGE_TRACE and Selva & Prasanna [Page 17] Internet Draft SCTP Dedicated Management Connection December 2000 CHANGE_DEBUG_LEVEL primitives. But TRACE,DIAGNOSTICS and DEBUG information can be passed either as primitives or by logging into a file, which is implementation dependent. 4. References [1] [RFC2960] "Stream Control Transmission Protocol" [2] "SCTP Dynamic Addition of IP addresses" 5. Author's Addresses Venkatesh Selvaraj Tel: +91-80-527 1373 Motorola India Electronics Ltd Email: venkatg@migv.mot.com Golf View Center, Wind Tunnel Road Murugesha Palya Bangalore - 560 017 INDIA Prasanna Kumar M V Tel: +91-80-527 1373 Motorola India Electronics Ltd Email: mvprasan@migv.mot.com Golf View Center, Wind Tunnel Road Murugesha Palya Bangalore - 560 017 INDIA This Internet Draft expires June 2001. Selva & Prasanna [Page 18]