RFC 2297
Ipsilon's General Switch Management Protocol Specification Version 2.0
9.6 QoS Connection Management Message The QoS Connection Management message is used by the controller to establish and modify virtual channel connections and virtual path connections across the switch which require QoS parameters to be specified. The functionality of the QoS Connection Management message is identical to that of the Add Branch connection management message with the additional specification of QoS parameters. No specific QoS connection release messages are defined. QoS connections may be released with the Delete Tree, Delete All, and Delete Branches messages defined in Section 4, "Connection Management Messages." When a QoS connection is released, all associated QoS resources are released. There are three styles of connection with specified QoS parameters: QoS Connection: This connection style specifies its own individual QoS parameters and is routed independently to the waiting room and output port specified in the QoS Connection Management message. It is not a member of a QoS class. Each output branch of a point-to-multipoint QoS connection may specify its own QoS parameters which may be different from all other output branches of that point-to- multipoint QoS connection, if the switch supports this capability. However, all output branches must specify identical connection policer parameters. A QoS Connection Management message requesting this style of connection is identified by a QoS Class Identifier with the value 0xFFFFFFFF.
QoS Class Connection:
This connection style does not specify its own individual QoS
parameters. It is a member of a QoS class, and the QoS parameters
are specified by the QoS class. It is, however, routed
independently to the waiting room and output port specified in the
QoS Connection Management message. Each output branch of a
point-to-multipoint QoS Class Connection must use the same QoS
parameters. A QoS Connection Management message requesting this
style of connection will have a valid QoS Class Identifier and a
valid Scheduler Identifier.
QoS Class Member:
This connection style does not specify its own individual QoS
parameters. It is a member of a QoS class, and the QoS parameters
are specified by the QoS class. The QoS class also specifies the
waiting room and output port to which all members of the class are
routed. This style of connection does not support point-to-
multipoint connections. A QoS Connection Management message
requesting this style of connection will have a valid QoS Class
Identifier and a Scheduler Identifier with the value 0xFFFF.
To request a virtual channel connection with specified QoS
parameters, the Virtual Channel Connection (VCC) QoS Connection
Management message is:
Message Type = 100.
To request a virtual path connection with specified QoS parameters,
the Virtual Path Connection (VPC) QoS Connection Management message
is:
Message Type = 101.
The QoS Connection Management message has the following format for
both request and response messages:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Result | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port Session Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Input Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|Q|B|C| Input VPI | Input VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Output Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x x x x| Output VPI | Output VCI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Branches | Scheduler Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS Class Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator | Excess Action | Connection Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|x x x x x x| Reserved | Excess Scheduler Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ UPC Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Regulator Parameters ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Port Session Number
Input Port
Input VPI
Input VCI
Output Port
Output VPI
Output VCI
Number of Branches
The definition of these fields is exactly the same as
defined for the Add Branch message in Section 4.1,
"Connection Management Messages."
M B C Flags
The definition of the M, B, and C flags is exactly the same
as defined in Section 4, "Connection Management Messages."
They apply to the QoS Connection Management message exactly
as defined for the Add Branch message.
Q: QoS Profile Flag The QoS Profile flag is not used in the QoS
Connection Management message.
Scheduler Identifier
For QoS Connection and QoS Class Connection styles, the
Scheduler Identifier points to the waiting room, on the
output port specified by the Output Port field, to which
all conforming traffic on the connection should be routed.
The values 0 -- 255 specify the default settings for the
scheduler. Each of the default values maps directly to one
of the scheduler priority levels. A Scheduler Identifier in
the range 0 -- 255 may be used without first being
established by a Scheduler Establishment message. All
Scheduler Identifiers in the range 0x0100 to 0xFFFE must
first be established by a Scheduler Establishment message.
A Scheduler Identifier with a value of 0xFFFF indicates
that a QoS Class Member connection style is being
requested. In this connection style, the waiting room and
output port are specified by reference to the QoS class
specified by the QoS Class Identifier field. In this case
the QoS Class Identifier field must contain a valid QoS
Class Identifier.
QoS Class Identifier
For QoS Class Connection and QoS Class Member connection
styles, the QoS Class Identifier specifies the QoS Class to
which the connection belongs. It must first be established
by a QoS Class Establishment message and must have a value
greater than 0 and less than 0xFFFFFFFF.
A QoS Class Identifier with a value of 0xFFFFFFFF indicates
that a connection of style "QoS Connection" is being
requested. In this connection style, the connection does
not belong to a QoS class. All QoS parameters are specified
by the QoS Connection Management message and apply only to
the specified connection.
Regulator
Excess Action
The Regulator and Excess Action parameters are only used in
connection requests of style "QoS Connection." The
definition of these fields in the QoS Connection Management
message is exactly the same as defined for the QoS Class
Establishment message with the exception that they apply to
an individual connection rather than to an entire QoS
class.
Connection Weight
This field is only used in connections of style "QoS
Connection" and "QoS Class Connection." For QoS Class
Member style connections, the QoS Class Weight parameter of
the QoS Class Establishment message should be used to
assign a weight to the QoS Class.
If bit 0 of the Scheduler Flags field of the QoS
Configuration message indicates that weighted service may
be applied to a connection, the Connection Weight parameter
specifies the share of the bandwidth available to the
waiting room that should be given to this connection.
The Connection Weight is an unsigned 16-bit field
specifying a binary fraction. I.e. the bandwidth share, as
a fraction of the bandwidth available to the waiting room,
is given by:
Bandwidth share = Connection Weight * 2**(-16)
A Connection Weight of zero indicates equal sharing between
all connections in this waiting room that request a
Connection Weight of zero. While a 16-bit field is used to
specify the Connection Weight it is understood that the
accuracy of the bandwidth sharing is hardware dependent and
is not specified.
For connections of style "QoS Class Connection," if the
Regulator function of the QoS Class is specified as None,
or Policer, the Connection Weight should be applied to the
waiting room pointed to by the Scheduler Identifier field
in the QoS Connection Management message. If the Regulator
function of the QoS Class is specified as Shaper, the
Connection Weight should be applied to the waiting room
pointed to by the Excess Scheduler Id field in the QoS
Connection Management message.
For connections of style "QoS Connection," if the Regulator
field of the QoS Connection Management message specifies
None, or Policer, the Connection Weight should be applied
to the waiting room pointed to by the Scheduler Identifier
field. If the Regulator field of the QoS Connection
Management message specifies Shaper, the Connection Weight
should be applied to the waiting room pointed to by the
Excess Scheduler Id field.
If the specified waiting room is unable to offer weighted
sharing for a connection, a failure response message should
be returned with the failure code indicating: "this waiting
room is unable to offer weighted sharing for a connection."
QoS Flags
S: Selective Discard
If the Selective Discard flag is set, only cells with the
Cell Loss Priority (CLP) bit set will be subject to the
discard mechanism when the number of cells in the waiting
room exceeds the Discard Threshold. If the Selective
Discard flag is zero, all cells (CLP=0 and CLP=1) will be
subject to the discard mechanism when the number of cells
in the waiting room exceeds the Discard Threshold.
Selective discard can be combined with packet discard. In
this case only packets in which at least one cell has the
CLP bit set will be subject to the discard mechanism.
A: All Branches
For a QoS Connection Management message that specifies a
point-to-multipoint connection, if the All Branches flag is
set, all branches of the point-to-multipoint connection
must be set to the QoS parameters specified in the message.
If the All Branches flag is zero, only the single output
branch specified in the message should be set to the QoS
parameters specified in the message. For a QoS Connection
Management message that specifies a point-to-point
connection, the All Branches flag is not used.
x: Unused
Excess Scheduler Id
For connections of style "QoS Connection" and "QoS Class
Connection," the Excess Scheduler Id points to the waiting
room, on the output port specified by the Output Port
field, to which all excess traffic should be routed. The
values 0 -- 255 specify the default settings for the
scheduler. Each of the default values maps directly to one
of the scheduler priority levels. An Excess Scheduler Id in
the range 0 -- 255 may be used without first being
established by a Scheduler Establishment message. All
values of Excess Scheduler Id in the range 0x0100 to 0xFFFE
must first be established by a Scheduler Establishment
message.
If this field is not used it should be set to 0xFFFF. The
Excess Scheduler Id must not point to the same waiting room
on the same output port as the Scheduler Identifier.
UPC Parameters
All connection styles may be subject to a Usage Parameter
Control (UPC) function, also known as a connection policer.
The policing function is applied to each individual
connection before it is combined with other connections
into a QoS class by the classifier function. A policing
function applied to an entire QoS class is defined in the
QoS Class Establishment message.
The connection policer is defined by reference to the
Generic Cell Rate Algorithm (GCRA) defined by the ATM Forum
[af-tm-0056], although any equivalent policing algorithm
may be used. The GCRA takes two parameters, the increment
(I) and the limit (L). The reciprocal of the increment
(1/I) specifies the rate being policed. The limit specifies
the burst tolerance. (For comparison with the token bucket
policer discussed in [Partridge], the size of the token
bucket is given by L/I.)
Two policers in series may be specified to permit the
policing of both peak rate and average rate (also called
sustainable rate). The parameters for the first policer are
Increment-1 and Limit-1. For comparison with the ATM Forum
specification these would be used to police the Peak Cell
Rate (PCR) and Cell Delay Variation Tolerance (CDVT)
respectively. The parameters for the second policer are
Increment-2 and Limit-2. For comparison with the ATM Forum
specification these would be used to police the Sustainable
Cell Rate (SCR), and Burst Tolerance. (The Burst Tolerance
may be computed from the Maximum Burst Size [af-tm-0056].)
There are two configurations in which the two policers may
be connected in series. In the All Cells configuration,
all cells (cells with the Cell Loss Priority (CLP) bit set
to zero and cells with the CLP bit set to one) are subject
to the policing action of both policers in series. In the
CLP Selective configuration, all cells, both CLP=0 and
CLP=1, are policed by the first policer; but only cells
with CLP=0 are subject to policing by the second policer.
Either tagging or discard may be specified for each of the
policer configurations.
The values of the parameters Increment and Limit in the UPC
Parameters fields are given in terms of a time unit
specified by the switch in the QoS Configuration Parameters
message. The time unit is specified by the switch as a
rate, the Scaling Factor, which gives the rate in cells per
second that would result from an Increment parameter value
of one. Thus to determine the value of the Increment
parameter from the desired policed rate given in cells per
second:
Increment parameter = (Scaling_Factor)/(policed_rate)
To determine the value of the Limit parameter from the
desired Cell Delay Variation Tolerance (CDVT) given in
seconds:
Limit parameter = CDVT * Scaling_Factor
To determine the value of the Limit parameter from the
desired Burst Tolerance (BT) given in seconds:
Limit parameter = BT * Scaling_Factor
The Increment and Limit parameters are specified as 32-bit
unsigned integers; so the choice of the Scaling Factor
allows the switch to select the range and granularity of
the policer parameters with respect to the line rate of the
switch port. For example, a SONET STS-3c (155.52 Mbps)
switch port has a line rate of approximately 353 kcells/s.
With a Scaling Factor value of 353,000,000 we can specify a
policed rate slightly less than the line rate with a
granularity of 0.1%. For a policed rate of 1 kbps we can
still support a bucket size of 31 cells.
The UPC Parameters have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Increment-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |C|A|x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Increment-1
The increment parameter for the first policer, specified as
a 32-bit unsigned integer. A value of zero for the
Increment-1 parameter is used to disable the first policer.
In this case all cells will be considered to conform to the
traffic parameters of the first policer.
Limit-1
The limit parameter for the first policer, specified as a
32-bit unsigned integer.
Increment-2
The increment parameter for the second policer, specified
as a 32-bit unsigned integer. A value of zero for the
Increment-2 parameter is used to disable the second
policer. In this case all cells will be considered to
conform to the traffic parameters of the second policer.
Limit-2
The limit parameter for the second policer, specified as a
32-bit unsigned integer.
Flags
C: Configuration
If the Configuration flag is set, the policer should be set
to the All Cells configuration. If the Configuration flag
is zero, the policer should be set to the CLP Selective
configuration.
In the All Cells configuration, all cells (both CLP=0 and
CLP=1) are subject to the policing action of both policers
in series. In the CLP Selective configuration, all cells,
both CLP=0 and CLP=1, are policed by the first policer; but
only cells with CLP=0 are subject to policing by the second
policer. Either tagging or discard may be specified for
each of the policer configurations.
A: Action
If the Action flag is zero, discard is required as the
policing action. If the Action flag is set, tagging is
required as the policing action.
If tagging is selected in the All Cells configuration, any
cell with CLP=0 in either policer, that the policer
determines to be in excess of the specified policer
parameters, will be changed to CLP=1. If discard is
selected in the All Cells configuration, any cell (CLP=0 or
CLP=1) in either policer, that the policer determines to be
in excess of the specified policer parameters, will be
discarded.
In the CLP Selective configuration, the first policer is
always set to discard any cell (CLP=0 or CLP=1) that it
determines to be in excess of its specified policer
parameters. If tagging is selected in the CLP Selective
configuration, the second policer will change the CLP bit
to CLP=1 of any cell that it determines to be in excess of
its specified parameters. If discard is selected in the CLP
Selective configuration, the second policer will discard
any cell that it determines to be in excess of its
specified parameters.
To configure the policer for the conformance definitions
specified by the ATM Forum [af-tm-0056] the following
configurations are suggested:
CBR.1: One policer, All Cells, Discard
VBR.1: Two policers, All Cells, Discard
VBR.2: Two policers, CLP Selective, Discard
VBR.3: Two policers, CLP Selective, Tagging
UBR.1: One policer, All Cells, Discard
UBR.2: One policer, All Cells, Tagging.
x: Unused
Regulator Parameters
Only connections of style "QoS Connection" require the
Regulator Parameters to be specified in the QoS Connection
Management message. For connections of style "QoS Class
Connection" and "QoS Class Member" the Regulator Parameters
are specified in the QoS Class Establishment message.
The Regulator Parameters are specified in a similar manner
to the UPC parameters. If the regulator function is
specified as Policing, a single GCRA policer is applied to
all cells (both CLP=0 and CLP=1) on the connection. The
policer takes two parameters: an increment, the Regulator
Increment, and a limit, the Regulator Limit. The reciprocal
of the increment (1/I) specifies the rate being policed.
The limit (L) specifies the burst tolerance. (For
comparison with the token bucket policer discussed in
[Partridge], the size of the token bucket is given by L/I.)
The Regulator Increment and Regulator Limit parameters are
32-bit unsigned integers. Their values are determined in
terms of the Scaling Factor specified by the switch in the
QoS Configuration Parameters message. To determine the
value of the Regulator Increment parameter from the desired
policed rate given in cells per second:
Regulator Increment = (Scaling_Factor)/(policed_rate)
For a policed rate (r) the GCRA policer guarantees that
over any time period T the amount of traffic determined by
the policer to be conforming to the traffic parameters does
not exceed:
rT + L/I
The value of the Regulator Limit may be determined from
this relation.
If the regulator function is specified as Shaping, only the
Regulator Increment parameter is used. The Regulator Limit
parameter is not used. The value of the Regulator Increment
parameter is determined in terms of the Scaling Factor
specified by the switch in the QoS Configuration Parameters
message. To determine the value of the Regulator Increment
parameter from the desired shaper rate, given in cells per
second, on output from the shaper:
Regulator Increment = (Scaling_Factor)/(shaper_rate)
An Increment value of zero is used to disable the policer.
In this case all cells on that connection will be
considered to conform to the policer traffic parameters. A
shaper given a Regulator Increment parameter of zero will
perform no shaping function on that connection.
The Regulator Parameters have the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Increment |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Regulator Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.7 QoS Failure Response Codes
A failure response message is formed by returning the request message
that caused the failure with the Result field in the header
indicating failure (Result = 4) and the Code field giving the failure
code. The failure code specifies the reason for the switch being
unable to satisfy the request message. The following additional
failure codes are defined for use in response to QoS messages.
General failure codes are specified in Section 3.2, Failure Response
Messages.
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
10. Adjacency Protocol
The adjacency protocol is used to synchronize state across the link,
to agree on which version of the protocol to use, to discover the
identity of the entity at the other end of a link, and to detect when
it changes. GSMP is a hard state protocol. It is therefore important
to detect loss of contact between switch and controller, and to
detect any change of identity of switch or controller. No GSMP
messages other than those of the adjacency protocol may be sent
across the link until the adjacency protocol has achieved
synchronization.
10.1 Packet Format All GSMP messages belonging to the adjacency protocol have the following structure: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Timer |M| Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Name | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Receiver Name | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sender Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receiver Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version In the adjacency protocol the Version field is used for version negotiation. In a SYN message the Version field always contains the highest version understood by the sender. A receiver receiving a SYN message with a version higher than understood will ignore that message. A receiver receiving a SYN message with a version lower than its own highest version, but a version that it understands, will reply with a SYNACK with the version from the received SYN in its GSMP Version field. This defines the version of the GSMP protocol to be used while the adjacency protocol remains synchronized. All other messages will use the agreed version in the Version field. The version number for the version of the GSMP protocol defined by this specification is Version = 2. Message Type The adjacency protocol is: Message Type = 10
Timer
The Timer field is used to inform the receiver of the timer
value used in the adjacency protocol of the sender. The
timer specifies the nominal time between periodic adjacency
protocol messages. It is a constant for the duration of a
GSMP session. The timer field is specified in units of
100ms.
M-Flag
The M-Flag is used in the SYN message to indicate whether
the sender is a master or a slave. If the M-Flag is set in
the SYN message, the sender is a master. If zero, the
sender is a slave. The GSMP protocol is asymmetric, the
controller being the master and the switch being the slave.
The M-Flag prevents a master from synchronizing with
another master, or a slave with another slave. If a slave
receives a SYN message with a zero M-Flag, it must ignore
that SYN message. If a master receives a SYN message with
the M-Flag set, it must ignore that SYN message. In all
other messages the M-Flag is not used.
Code
Field specifies the function of the message. Four Codes are
defined for the adjacency protocol:
SYN: Code = 1
SYNACK: Code = 2
ACK: Code = 3
RSTACK: Code = 4.
Sender Name
For the SYN, SYNACK, and ACK messages, is the name of the
entity sending the message. The Sender Name is a 48-bit
quantity that is unique within the operational context of
the device. A 48-bit IEEE 802 MAC address, if available,
may be used for the Sender Name. If the Ethernet
encapsulation is used the Sender Name must be the Source
Address from the MAC header. For the RSTACK message, the
Sender Name field is set to the value of the Receiver Name
field from the incoming message that caused the RSTACK
message to be generated.
Receiver Name
For the SYN, SYNACK, and ACK messages, is the name of the
entity that the sender of the message believes is at the
far end of the link. If the sender of the message does not
know the name of the entity at the far end of the link,
this field should be set to zero. For the RSTACK message,
the Receiver Name field is set to the value of the Sender
Name field from the incoming message that caused the RSTACK
message to be generated.
Sender Port
For the SYN, SYNACK, and ACK messages, is the local port
number of the link across which the message is being sent.
For the RSTACK message, the Sender Port field is set to the
value of the Receiver Port field from the incoming message
that caused the RSTACK message to be generated.
Receiver Port
For the SYN, SYNACK, and ACK messages, is what the sender
believes is the local port number for the link, allocated
by the entity at the far end of the link. If the sender of
the message does not know the port number at the far end of
the link, this field should be set to zero. For the RSTACK
message, the Receiver Port field is set to the value of the
Sender Port field from the incoming message that caused the
RSTACK message to be generated.
Sender Instance
For the SYN, SYNACK, and ACK messages, is the sender's
instance number for the link. It is used to detect when the
link comes back up after going down or when the identity of
the entity at the other end of the link changes. The
instance number is a 32-bit number that is guaranteed to be
unique within the recent past and to change when the link
or node comes back up after going down. Zero is not a valid
instance number. For the RSTACK message, the Sender
Instance field is set to the value of the Receiver Instance
field from the incoming message that caused the RSTACK
message to be generated.
Receiver Instance
For the SYN, SYNACK, and ACK messages, is what the sender
believes is the current instance number for the link,
allocated by the entity at the far end of the link. If the
sender of the message does not know the current instance
number at the far end of the link, this field should be set
to zero. For the RSTACK message, the Receiver Instance
field is set to the value of the Sender Instance field from
the incoming message that caused the RSTACK message to be
generated.
10.2 Procedure The adjacency protocol is described by the following rules and state tables. The rules and state tables use the following operations: o The "Update Peer Verifier" operation is defined as storing the values of the Sender Instance, Sender Port, and Sender Name fields from a SYN or SYNACK message received from the entity at the far end of the link. o The procedure "Reset the link" is defined as: 1. Generate a new instance number for the link 2. Delete the peer verifier (set to zero the values of Sender Instance, Sender Port, and Sender Name previously stored by the Update Peer Verifier operation) 3. Send a SYN message 4. Enter the SYNSENT state. o The state tables use the following Boolean terms and operators: A The Sender Instance in the incoming message matches the value stored from a previous message by the "Update Peer Verifier" operation. B The Sender Instance, Sender Port, and Sender Name fields in the incoming message match the values stored from a previous message by the "Update Peer Verifier" operation. C The Receiver Instance, Receiver Port, and Receiver Name fields in the incoming message match the values of the Sender Instance, Sender Port, and Sender Name currently sent in outgoing SYN, SYNACK, and ACK messages. "&&" Represents the logical AND operation "||" Represents the logical OR operation "!" Represents the logical negation (NOT) operation. o A timer is required for the periodic generation of SYN, SYNACK, and ACK messages. The value of the timer is announced in the Timer field. The period of the timer is unspecified but a value of one second is suggested.
There are two independent events: the timer expires, and a packet
arrives. The processing rules for these events are:
Timer Expires: Reset Timer
If state = SYNSENT Send SYN
If state = SYNRCVD Send SYNACK
If state = ESTAB Send ACK
Packet Arrives:
If incoming message is an RSTACK:
If (A && C && !SYNSENT) Reset the link
Else Discard the message.
If incoming message is a SYN, SYNACK, or ACK:
Response defined by the following State Tables.
If incoming message is any other GSMP message and state !=
ESTAB:
Discard incoming message.
If state = SYNSENT Send SYN (Note 1)
If state = SYNRCVD Send SYNACK (Note 1)
Note 1: No more than two SYN or SYNACK messages should be
sent within any time period of length defined by the
timer.
o State synchronization across a link is considered to be achieved
when the protocol reaches the ESTAB state. All GSMP messages,
other than adjacency protocol messages, that are received before
synchronization is achieved will be discarded.
State Tables
State: SYNSENT
+======================================================================+
| Condition | Action | New State |
+====================+=====================================+===========+
| SYNACK && C | Update Peer Verifier; Send ACK | ESTAB |
+--------------------+-------------------------------------+-----------+
| SYNACK && !C | Send RSTACK | SYNSENT |
+--------------------+-------------------------------------+-----------+
| SYN | Update Peer Verifier; Send SYNACK | SYNRCVD |
+--------------------+-------------------------------------+-----------+
| ACK | Send RSTACK | SYNSENT |
+======================================================================+
State: SYNRCVD +======================================================================+ | Condition | Action | New State | +====================+=====================================+===========+ | SYNACK && C | Update Peer Verifier; Send ACK | ESTAB | +--------------------+-------------------------------------+-----------+ | SYNACK && !C | Send RSTACK | SYNRCVD | +--------------------+-------------------------------------+-----------+ | SYN | Update Peer Verifier; Send SYNACK | SYNRCVD | +--------------------+-------------------------------------+-----------+ | ACK && B && C | Send ACK | ESTAB | +--------------------+-------------------------------------+-----------+ | ACK && !(B && C) | Send RSTACK | SYNRCVD | +======================================================================+ State: ESTAB +======================================================================+ | Condition | Action | New State | +====================+=====================================+===========+ | SYN || SYNACK | Send ACK (note 2) | ESTAB | +--------------------+-------------------------------------+-----------+ | ACK && B && C | Send ACK (note 3) | ESTAB | +--------------------+-------------------------------------+-----------+ | ACK && !(B && C) | Send RSTACK | ESTAB | +======================================================================+ Note 2: No more than two ACKs should be sent within any time period of length defined by the timer. Thus, one ACK must be sent every time the timer expires. In addition, one further ACK may be sent between timer expirations if the incoming message is a SYN or SYNACK. This additional ACK allows the adjacency protocol to reach synchronization more quickly. Note 3: No more than one ACK should be sent within any time period of length defined by the timer. 10.3 Loss of Synchronization If after synchronization is achieved, no valid GSMP messages are received in any period of time in excess of three times the value of the Timer field announced in the incoming adjacency protocol messages, loss of synchronization may be declared. The preferred procedure for a switch to use when it looses synchronization with its active controller is to attempt to establish
synchronization with (one of) its backup controller(s). However, in this preferred approach, it must not reset its state until it achieves synchronization with a backup controller. This means that if, before achieving synchronization with a backup controller, it regains synchronization with its original controller, it may continue the original session (and cease attempting to establish synchronization with a backup controller). If synchronization with the original session is regained it is the responsibility of the controller to ensure consistent state between the switch and controller. While the above is the preferred procedure, it is also the case that the simplest procedure when declaring loss of synchronization with the active controller is to reset the switch state, and start searching for a controller. This simple procedure is legitimate. 11. Summary of Failure Response Codes The following list gives a summary of the failure codes defined for failure response messages: 1: Unspecified reason not covered by other failure codes. 2: Invalid request message. 3: The specified request is not implemented on this switch. 4: Invalid Port Session Number. 5: One or more of the specified ports does not exist. 6: One or more of the specified ports is down. 7: Unused. (This failure code has been replaced by failure codes 18--21.) 8: The specified connection does not exist. 9: The specified branch does not exist. 10: A branch belonging to the specified point-to-multipoint connection is already established on the specified output port and the switch cannot support more than a single branch of any point-to-multipoint connection on the same output port. 11: The limit on the maximum number of point-to-multipoint connections that the switch can support has been reached. 12: The limit on the maximum number of branches that the specified point-to-multipoint connection can support has been reached. 13: Unable to assign the requested VPI/VCI value to the requested branch on the specified point-to-multipoint connection. 14: General problem related to the manner in which point-to- multipoint is supported by the switch. 15: Out of resources (e.g. memory exhausted, etc.). 16: Failure specific to the particular message type. (The meaning of this failure code depends upon the Message Type. It is
defined within the description of any message that uses
it.)
17: Cannot label each output branch of a point-to-multipoint tree
with a different label.
18: One or more of the specified input VPIs is invalid.
19: One or more of the specified input VCIs is invalid.
20: One or more of the specified output VPIs is invalid.
21: One or more of the specified output VCIs is invalid.
22: Invalid Class of Service field in a Connection Management
message.
23: Insufficient resources for QoS Profile.
24: Virtual path switching is not supported on this input port.
25: Point-to-multipoint virtual path connections are not
supported on either the requested input port or the
requested output port.
26: Attempt to add a virtual path connection branch to an
existing virtual channel connection.
27: Attempt to add a virtual channel connection branch to an
existing virtual path connection.
28: Only point-to-point bidirectional connections may be
established.
29: Cannot support requested VPI range.
30: Cannot support requested VCI range on all requested VPIs.
31: The transmit cell rate of this output port cannot be changed.
32: Requested transmit cell rate out of range for this output
port.
128: Weighted scheduling within this waiting room is unavailable.
129: This waiting room is unable to offer weighted sharing for a
QoS class.
130: This waiting room is unable to offer weighted sharing for a
connection.
131: Scheduler Identifier still in use.
132: QoS Class Identifier still in use.
133: Invalid QoS parameter.
134: Insufficient QoS resources.
135: Any point-to-multipoint connection arriving on this input
port must use the same QoS parameters for all output
branches.
12. Summary of Message Set
The following table gives a summary of the messages defined in this
version of the specification. It also indicates which messages must
be supported in a minimal implementation of the protocol. Those
messages marked as "Required" must be supported by the switch for an
implementation to be considered to conform to this specification.
(While the controller should also implement those messages marked
"Required," conformance cannot be tested for the controller due to
the Master-Slave nature of the protocol.)
Message Name Message Type Status
Connection Management Messages
Add Branch VCC....................16 Required
VPC....................26
Delete Tree.......................18
Delete All........................20
Delete Branches...................17 Required
Move Branch VCC...................22
VPC...................27
Port Management Messages
Port Management...................32 Required
Label Range.......................33
State and Statistics Messages
Connection Activity...............48
Port Statistics...................49 Required
Connection Statistics.............50
QoS Class Statistics..............51
Report Connection State...........52
Configuration Messages
Switch Configuration..............64 Required
Port Configuration................65 Required
All Ports Configuration...........66 Required
Event Messages
Port Up...........................80
Port Down.........................81
Invalid VPI/VCI...................82
New Port..........................83
Dead Port.........................84
Quality of Service Messages
QoS Configuration.................96
Scheduler Establishment...........97
QoS Class Establishment...........98
QoS Release.......................99
QoS Connection Management VCC....100
VPC....101
Adjacency Protocol....................10 Required
REFERENCES [af-tm-0056] ATM Forum Traffic Management Specification 4.0, af-tm- 0056.000, April 1996. [I.361] "B-ISDN ATM Layer Specification," International Telecommunication Union, ITU-T Recommendation I.361, Mar. 1993. [I.363] "B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993. [IpsilonMIB] Ipsilon IP Switch MIB, http://www.ipsilon.com/products/ips.mib [Partridge] C. Partridge, "Gigabit Networking," Addison-Wesley, 1994. [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers," STD 2, RFC 1700, October 1994. [RFC1987] Newman, P, Edwards, W., hinden, R., Hoffman, E. Ching Liaw, F., Lyon, T. and G. Minshall, "Ipsilon's General Switch Management Protocol Specification," Version 1.1, RFC 1987, August 1996. SECURITY CONSIDERATIONS Physical security on the control link connecting the controller to the switch is assumed. Security issues are not discussed in this document. AUTHORS' ADDRESSES Peter Newman Phone: +1 (408) 990 2003 Nokia EMail: pn@ipsilon.com W. L. Edwards, Chief Scientist Phone: +1 (913) 534 5334 Sprint EMail: texas@sprintcorp.com Robert M. Hinden Phone: +1 (408) 990 2004 Nokia EMail: hinden@ipsilon.com Eric Hoffman Phone: +1 (408) 990 2010 Nokia EMail: hoffman@ipsilon.com
Fong Ching Liaw Phone: +1 (408) 873 2688 Coppercom EMail: fong@coppercom.com Tom Lyon Phone: +1 (408) 990 2001 Nokia EMail: pugs@ipsilon.com Greg Minshall Phone: +1 (650) 237 3164 Fiberlane Communications EMail: minshall@fiberlane.com Nokia (Sunnyvale) is located at: 232 Java Drive Sunnyvale, CA 94089 USA Sprint is located at: Sprint Sprint Technology Services - Long Distance Division 9300 Metcalf Avenue Mailstop KSOPKB0802 Overland Park, KS 66212-6333 USA Fiberlane Communications is located at: 1399 Charleston Road Mountain View, CA 94043 USA
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.