Subject: I-D ACTION:draft-ietf-sigtran-sctp-mib-05.txt

From: [email-masked]
Date: Wed, 14 Nov 2001 07:03:17 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Signaling Transport Working Group of the IETF.

	Title		: Stream Control Transmission Protocol Management 
                          Information Base using SMIv2
	Author(s)	: J. Pastor, M. Belinchon
	Filename	: draft-ietf-sigtran-sctp-mib-05.txt
	Pages		: 45
	Date		: 13-Nov-01
	
The Stream Control Transmission Protocol (SCTP) is a reliable
transport protocol operating on top of a connectionless packet
network such as IP, designed to transport PSTN signaling messages
over the connectionless packet network, but is capable of broader
applications.
This memo defines the Management Information Base (MIB) module which
describes the minimum amount of objects needed to manage the
implementation of the SCTP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sigtran-sctp-mib-05.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sigtran-sctp-mib-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sigtran-sctp-mib-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
---
You are currently subscribed to sigtran as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: John Linton <[email-masked]>
Date: Wed, 28 Nov 2001 16:01:27 -0500

Comments on draft 5 as follows.

John Linton

Counter64 -> Counter32
---------------------------------------------------------------------

It seems reasonable to convert these counters because 
these should not wrap in short period of time.
sctpActiveEstabs 
sctpPassiveEstabs
sctpAborteds
sctpShutdowns 
sctpStatOutOfBlues
sctpStatChecksumErrors

However, these values are across all association can 
could wrap in less than hour when using a high speed 
connections.  This should be Counter64.
sctpStatSentCtrlChunks
sctpStatSentOrderChunks 
sctpStatSentUnorderChunks
sctpStatRecCtrlChunks
sctpStatRecOrderChunks
sctpStatRecUnorderChunks 

These might not wrap but could if application is sending
sizes just over MTU size.

sctpStatFragmentedUsrMessages
sctpStatReassembledUsrMessages

These will wrap in less than a hour.
sctpStatSentSCTPPacks
sctpStatRecSCTPPacks 

sctpMaxAssoc 
---------------------------------------------------------------------
change syntax to a signed Integer

sctpAssocId
---------------------------------------------------------------------
Is it appropriate for an implementation to reuse an association
identifier in short period of time. For example, association 
number 5 dies can a new association reuse this identifier.
If not the sctpAssocId needs to explain the limitations.

Since, sctpAssocId is an index and a value of zero should be 
prohibited in all cases to simplify getnext requests.

sctpAssocState 
---------------------------------------------------------------------
Line:1297

Couple of questions related to Association State.

1) Lets say that the association has failed and is not carrying
   traffic. Was should be reported for the state of the association?
   
2) If the association is used to carry traffic like SS7 it is necessary
   to be able to retrieve the unsent packets so that they can be 
   routed on different link or linkset.  Do we need some additional
   states to indicate data available for retrieval and data 
   has been retrieved?
   
3) The deleteTCB state is provided to prevent the information on each
   association from disappearing before the NMS can read the data.
   The idea of setting this state to free the association resources
   could cause problems in a multiple NMS environment. In other words
   one NMS may set value prior to another reading the data.
   
4) This also creates a possible problem in that resources could
   remain committed to information on dead assocations and thereby
   in danger the operation of the device.  In order to implement this
   on our device I had to provide additional objects that limit the
   maximum number of dead assocations and limit how long these 
   dead association will be retained.
   
   cSctpCtrlPurgeTimeout       OBJECT-TYPE
    SYNTAX                     Unsigned32(3600..3000000) 
    UNITS                      "seconds"
    MAX-ACCESS                 read-write
    STATUS                     current
    DESCRIPTION
         "The amount of time the SCTP protocol software will wait
          before purging an associations TCB. An association TCB 
          will exist until a management station sets the cSctpAssocState
          to deleteTCB or is purge by the protocol implementation. The
          protocol implementation will purge an association TCB
          using a combination of cSctpCtrlPurgeTimeout and 
          cSctpCtrlMaxHeld. The cSctpCtrlPurgeTimeout ranges from
          the minimum of one hour to roughly one month. The default
          value is roughly one day."
    DEFVAL { 86400 } 
          
    ::= { cSctpScalarsExt 4 }

  cSctpCtrlMaxHeld             OBJECT-TYPE
    SYNTAX                     Unsigned32(30..10000)
    UNITS                      "association TCBs"
    MAX-ACCESS                 read-write
    STATUS                     current
    DESCRIPTION
         "The maximum number of association TCBS that will be held
          after they have been marked closed and are no longer
          providing service. This limit is used to prevent 
          excessive waste of resources." 
    DEFVAL { 100 } 
          
    ::= { cSctpScalarsExt 5 }

Effective addresses
---------------------------------------------------------------------
The SCTP MIB provides the following object that provide the 
preffered remote IP address and a list of all remote IP addresses.

sctpAssocRemPrimaryAddressType
sctpAssocRemPrimaryAddress    
sctpAssocLocalAddressIPType
sctpAssocLocalAddressIP    
sctpAssocRemAddressIPType
sctpAssocRemAddressIP    

How can an application determine which remote IP address is 
currently being used to send data?  Same question for the 
local IP address?

Fast retransmission
---------------------------------------------------------------------
The SCTP protocol provides for a mechanism to retransmit data without
as specified in section 7.2.4 (Fast Retransmit on Gap Reports).
Should the MIB include counters on the number of chunks retransmitted
using this mechanism?

[email-masked] wrote:
>   ------------------------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>
> 
>   ------------------------------------------------------------------------------------------
> ---
> You are currently subscribed to sigtran as: [email-masked]

-- 
-----------------------------------------
E Pluribus Unum(Out of Many, One)
-----------------------------------------
Software Engineer: John Ferguson Linton
Email:             [email-masked]
Division:          MWG - Apps/VAS Eng  
Voice:             (919) 392-6917
Fax:               (919) 392-2690
Building - Floor:  RTP MEADOW-4
Cube Number:      M4C1508
Company:          Cisco Systems, Inc.  
Address:          7025 Kit Creek Road 
                  Research Triangle Park, 
                  NC 27709-4967

---